Tuesday, 2012-04-24

*** vladimir3p has quit IRC00:14
*** tong has quit IRC00:33
*** uvirtbot has joined #openstack-meeting00:36
*** Mandell has quit IRC00:36
*** uvirtbot` has quit IRC00:37
*** Yak-n-Yeti has joined #openstack-meeting00:38
*** dendro-afk is now known as dendrobates00:39
*** dtroyer_zzz is now known as dtroyer00:43
*** bhall has quit IRC00:48
*** ryanpetrello has joined #openstack-meeting00:53
*** bengrue has joined #openstack-meeting00:54
*** ryanpetr_ has quit IRC00:57
*** AlanClark has quit IRC01:02
*** dendrobates is now known as dendro-afk01:16
*** jdurgin has quit IRC01:33
*** huntern has joined #openstack-meeting01:34
*** danwent_ has joined #openstack-meeting01:39
*** kindaopsdevy has joined #openstack-meeting01:41
*** danwent has quit IRC01:43
*** danwent_ is now known as danwent01:43
*** mestery has quit IRC01:44
*** danwent has quit IRC01:48
*** danwent has joined #openstack-meeting01:48
*** dwcramer has joined #openstack-meeting01:49
*** danwent_ has joined #openstack-meeting01:51
*** gyee has quit IRC01:54
*** danwent has quit IRC01:55
*** danwent_ is now known as danwent01:55
*** danwent_ has joined #openstack-meeting01:59
*** danwent has quit IRC02:02
*** danwent_ is now known as danwent02:02
*** sandywalsh has quit IRC02:03
*** ryanpetrello has quit IRC02:03
*** novas0x2a|laptop has quit IRC02:12
*** mnewby has quit IRC02:13
*** mnewby has joined #openstack-meeting02:13
*** kindaopsdevy_ has joined #openstack-meeting02:15
*** ywu has quit IRC02:17
*** kindaopsdevy has quit IRC02:18
*** kindaopsdevy_ is now known as kindaopsdevy02:18
*** kindaopsdevy has left #openstack-meeting02:22
*** sandywalsh has joined #openstack-meeting02:43
*** danwent has quit IRC02:54
*** dolphm has joined #openstack-meeting02:55
*** fattarsi has quit IRC02:57
*** fattarsi has joined #openstack-meeting02:57
*** dwcramer has quit IRC03:03
*** ravi has joined #openstack-meeting03:07
*** dolphm_ has joined #openstack-meeting03:14
*** mnewby has quit IRC03:16
*** dolphm has quit IRC03:17
*** ravi has quit IRC03:29
*** joearnold has joined #openstack-meeting03:35
*** dolphm has joined #openstack-meeting03:37
*** dolphm_ has quit IRC03:40
*** bengrue has quit IRC03:47
*** garyk has quit IRC03:55
*** danwent has joined #openstack-meeting03:56
*** littleidea has quit IRC04:18
*** huntern_ has joined #openstack-meeting04:19
*** dtroyer is now known as dtroyer_zzz04:20
*** huntern has quit IRC04:22
*** huntern_ is now known as huntern04:22
*** ravi has joined #openstack-meeting04:32
*** huntern has quit IRC04:33
*** huntern has joined #openstack-meeting04:41
*** ravi has left #openstack-meeting04:43
*** Mandell has joined #openstack-meeting04:43
*** dolphm has quit IRC04:46
*** garyk has joined #openstack-meeting04:48
*** nikhil_ has quit IRC04:56
*** ravi has joined #openstack-meeting05:01
*** Yak-n-Yeti has quit IRC05:14
*** 50UAAW7Z0 is now known as sleepsonzzz05:29
*** joearnold has quit IRC05:50
*** GheRivero has joined #openstack-meeting06:05
*** ravi has quit IRC06:21
*** Mandell has quit IRC06:41
*** ttrifonov_zZzz is now known as ttrifonov07:21
*** darraghb has joined #openstack-meeting08:01
*** derekh has joined #openstack-meeting08:11
*** jgriffith has quit IRC08:18
*** jgriffith has joined #openstack-meeting08:18
*** martines has quit IRC08:22
*** martines has joined #openstack-meeting08:29
*** jgriffith has quit IRC08:31
*** jgriffith has joined #openstack-meeting08:32
*** garyk has quit IRC09:54
*** garyk has joined #openstack-meeting10:00
*** xsad has joined #openstack-meeting11:07
*** sandywalsh has quit IRC11:21
*** dolphm has joined #openstack-meeting11:23
*** dendro-afk is now known as dendrobates11:28
*** dwcramer has joined #openstack-meeting11:30
*** joesavak has joined #openstack-meeting11:32
*** sandywalsh has joined #openstack-meeting11:35
*** dolphm has quit IRC11:38
*** xsad has quit IRC11:39
*** dolphm has joined #openstack-meeting11:39
*** jsavak has joined #openstack-meeting11:41
*** dolphm has quit IRC11:43
*** joesavak has quit IRC11:44
*** markvoelker has joined #openstack-meeting11:59
*** davlaps has joined #openstack-meeting12:09
*** davlaps has quit IRC12:10
*** dendrobates is now known as dendro-afk12:12
*** ayoung has quit IRC12:16
*** dolphm has joined #openstack-meeting12:23
*** GheRivero is now known as GheAway12:50
*** littleidea has joined #openstack-meeting12:51
*** dprince has joined #openstack-meeting13:01
*** dwcramer has quit IRC13:04
*** dhellmann_ has joined #openstack-meeting13:10
*** dhellmann_ has quit IRC13:10
*** dhellmann has quit IRC13:13
*** sandywalsh has quit IRC13:20
*** ayoung has joined #openstack-meeting13:24
*** littleidea has quit IRC13:25
*** sandywalsh_ has joined #openstack-meeting13:27
*** dendro-afk is now known as dendrobates13:37
*** dwcramer has joined #openstack-meeting13:38
*** Mandell has joined #openstack-meeting13:44
*** GheRivero has joined #openstack-meeting13:57
*** AlanClark has joined #openstack-meeting13:58
*** edygarcia has joined #openstack-meeting13:58
*** davidkranz_ has joined #openstack-meeting13:59
*** dwcramer has quit IRC14:00
*** blamar has joined #openstack-meeting14:01
*** mestery has joined #openstack-meeting14:02
*** davidkranz has quit IRC14:02
*** mattray has joined #openstack-meeting14:07
*** xsad has joined #openstack-meeting14:24
*** xsad has quit IRC14:26
*** xsad has joined #openstack-meeting14:27
*** xsad has quit IRC14:28
*** xsad has joined #openstack-meeting14:28
*** edygarcia_ has joined #openstack-meeting14:31
*** Gordonz has joined #openstack-meeting14:32
*** edygarcia has quit IRC14:34
*** edygarcia_ is now known as edygarcia14:34
*** Yak-n-Yeti has joined #openstack-meeting14:40
*** littleidea has joined #openstack-meeting14:42
*** Yak-n-Yeti has quit IRC14:43
*** littleidea has quit IRC14:44
*** dwcramer has joined #openstack-meeting14:52
*** dwcramer has quit IRC14:52
*** Mandell has quit IRC14:54
*** danwent has quit IRC14:59
*** joearnold has joined #openstack-meeting15:01
*** hggdh has quit IRC15:02
*** davidkranz_ has quit IRC15:09
*** davidkranz_ has joined #openstack-meeting15:09
*** hggdh has joined #openstack-meeting15:09
*** joearnold has quit IRC15:10
*** davidkranz_ is now known as davidkranz15:11
*** vladimir3p has joined #openstack-meeting15:14
*** dtroyer_zzz is now known as dtroyer15:15
*** jgriffith has quit IRC15:17
*** dwcramer has joined #openstack-meeting15:21
*** Yak-n-Yeti has joined #openstack-meeting15:25
*** dtroyer is now known as dtroyer_zzz15:25
*** ravi has joined #openstack-meeting15:26
*** Yak-n-Yeti has quit IRC15:28
*** heckj has joined #openstack-meeting15:29
*** edygarcia_ has joined #openstack-meeting15:30
*** xsad has quit IRC15:32
*** rnirmal has joined #openstack-meeting15:33
*** edygarcia has quit IRC15:33
*** edygarcia_ is now known as edygarcia15:33
*** Amw3000 has joined #openstack-meeting15:33
*** jgriffith has joined #openstack-meeting15:34
*** nikhil__ has joined #openstack-meeting15:35
*** dtroyer_zzz is now known as dtroyer15:38
*** Yak-n-Yeti has joined #openstack-meeting15:45
*** danwent has joined #openstack-meeting15:46
*** huntern has quit IRC15:46
*** Gordonz has quit IRC15:46
*** garyk has quit IRC15:46
*** Gordonz has joined #openstack-meeting15:52
*** ravi_ has joined #openstack-meeting16:01
*** ravi has quit IRC16:01
*** ravi_ is now known as ravi16:01
*** ravi has quit IRC16:02
*** ravi_ has joined #openstack-meeting16:02
*** Mandell has joined #openstack-meeting16:02
*** ryanpetrello has joined #openstack-meeting16:04
*** dwcramer has quit IRC16:04
*** dhellmann has joined #openstack-meeting16:09
*** rnirmal has quit IRC16:09
*** martines has quit IRC16:09
*** ravi has joined #openstack-meeting16:10
*** ravi_ has quit IRC16:10
*** ravi_ has joined #openstack-meeting16:11
*** ravi has quit IRC16:11
*** ravi_ is now known as ravi16:11
*** _jgriffith has joined #openstack-meeting16:14
*** garyk has joined #openstack-meeting16:17
*** dwcramer has joined #openstack-meeting16:19
*** rnirmal has joined #openstack-meeting16:20
*** zul has quit IRC16:22
*** zul has joined #openstack-meeting16:23
*** dhellmann has quit IRC16:25
*** dhellmann has joined #openstack-meeting16:29
*** Yak-n-Yeti1 has joined #openstack-meeting16:31
*** ravi has quit IRC16:31
*** Yak-n-Yeti has quit IRC16:32
*** martines has joined #openstack-meeting16:34
*** dwcramer has quit IRC16:36
*** ravi has joined #openstack-meeting16:38
*** dhellmann has quit IRC16:39
*** dhellmann has joined #openstack-meeting16:39
*** mnewby has joined #openstack-meeting16:44
*** jgriffith has quit IRC16:45
*** _jgriffith is now known as jgriffith16:46
*** joearnold has joined #openstack-meeting16:48
*** ravi has quit IRC16:48
*** dwcramer has joined #openstack-meeting16:53
*** mnewby has quit IRC16:53
*** mnewby has joined #openstack-meeting16:54
*** mnewby has quit IRC16:54
*** ravi has joined #openstack-meeting16:55
*** mnewby has joined #openstack-meeting16:55
*** jog0 has joined #openstack-meeting17:01
*** kindaopsdevy has joined #openstack-meeting17:02
*** derekh has quit IRC17:02
*** Yak-n-Yeti1 has quit IRC17:02
*** gyee has joined #openstack-meeting17:03
*** Yak-n-Yeti has joined #openstack-meeting17:03
*** hggdh has quit IRC17:04
*** joearnold has quit IRC17:07
*** hggdh has joined #openstack-meeting17:07
*** jgriffith has quit IRC17:14
*** dendrobates is now known as dendro-afk17:14
*** rafaduran has joined #openstack-meeting17:18
*** kindaopsdevy has left #openstack-meeting17:18
*** dhellmann has quit IRC17:20
*** darraghb has quit IRC17:28
*** GheRivero has quit IRC17:28
*** kindaopsdevy_ has joined #openstack-meeting17:37
*** jdurgin has joined #openstack-meeting17:37
*** jgriffith has joined #openstack-meeting17:47
*** joearnold has joined #openstack-meeting17:50
*** ravi has quit IRC17:51
*** dhellmann has joined #openstack-meeting17:52
*** tong has joined #openstack-meeting17:53
*** ravi has joined #openstack-meeting17:57
*** dolphm_ has joined #openstack-meeting18:00
*** joearnold has quit IRC18:01
*** Dug has joined #openstack-meeting18:01
heckjola18:03
heckjAnyone around for a keystone meeting?18:03
rafaduranme18:03
rafaduranhi, all18:03
jsavak\o - here, but on 2 calls as well (not here). ;)18:04
*** joearnold has joined #openstack-meeting18:04
adam_go/18:04
* cloudfly fly on the wall18:05
*** dolphm_ has quit IRC18:05
heckjjoesavak: heh - doing about the same 3 things at one18:05
heckj#startmeeting18:05
openstackMeeting started Tue Apr 24 18:05:14 2012 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.18:05
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.18:05
*** dolphm_ has joined #openstack-meeting18:05
heckjwelcome back from the summit!18:05
jsavak:)18:05
heckj#topic - future work18:05
*** openstack changes topic to "- future work"18:05
heckjWe had some great conversations at the summit, and most (but not all) are reflected in blueprints18:06
heckjWith Folsom, I'm aiming to move any "need to do this" into blueprints (away from "bugs). So if you have elements you'd like to do, please add them in as blueprints over the next few days18:06
*** littleidea has joined #openstack-meeting18:07
*** dolphm__ has joined #openstack-meeting18:07
jsavakwhat's the approval process for the bp?18:07
*** joearnold has quit IRC18:07
*** joearnol_ has joined #openstack-meeting18:07
dolphm__Bug heckj?18:08
heckjjsavak: right now, create it as "new" and assign it to yourself. When we're agreed on method implementation, someone on the core team (me, termie, etc) will change the BP to approved18:08
jsavakokie.18:08
heckjYou *do not* need to wait for a BP to be approved to start work18:08
heckjsubmitting a code review is a perfectly acceptable (and actually quite effective) way to get an implementation conversation started.18:09
heckjThe blueprint should ideally outline "success" criteria more than anything else.18:09
*** dolphm_ has quit IRC18:09
*** ravi has quit IRC18:09
jsavakok, cool, thx18:11
gyeeheckj, I am changing the role apis to add the service_id back in there18:11
heckj#topic: next api18:12
*** openstack changes topic to ": next api"18:12
*** johnpostlethwait has joined #openstack-meeting18:12
gyeerole apis18:12
heckjrelated to gyee - with the feedback we gathered, I'll be working with termie to consolidate the API into a next revision and get that up as a document proposal over the next few weeks.18:12
gyeeI've add the service_id back in there18:12
gyeeadded18:12
heckjwill be looking forward to feedback from y'all on that document when we get it live18:13
heckjIn the meantime, there's an open discussion on modeling the endpoints on the mailing list - please contribute to the conversation there.18:13
dolphmheckj: etherpad or anything for api stuff?18:14
gyeeheckj, you are proposing that we move service_type and region to attributes?18:14
heckjdoplhm: I was going to follow Jay's pattern and make a google doc for feedback - easier to track (for me) on feedback than etherpad18:14
heckjgyee: I'm promising to get an API up for feedback - I'm looking for more conversation related to relevant attributes and how to think about them on the mailing list.18:15
heckjgyee: I'm not sure what "region" means to folks - so it's hard to assert anything concrete there18:15
*** liemmn has joined #openstack-meeting18:15
dolphmheckj: +118:16
heckjgyee: and I'm not sure entirely which field you're referring to re: service_type18:16
*** ravi has joined #openstack-meeting18:16
*** dhellmann has quit IRC18:17
heckjgyee: did that answer your question?18:18
*** edygarcia has quit IRC18:18
gyeethere's a service_type field in the endpoint templates right?18:18
dolphm<service name="My Nova" type="compute" region="north" /><endpoint ... /><endpoint ... /></service>18:18
heckjthe one that contains "image", "compute" - yeah18:18
gyeeso we are moving that one to attributes? I wasn't clear on that18:19
heckjgyee: I'm more asking what people think about representing the resources over trying to assert a specific proposal at this point.18:19
*** dolphm__ has quit IRC18:19
heckjgyee: I'm not 100% certain what we're modelling and what it's inteded to represent, so I'm asking for people (you, dolph, etc - anyone who cares) to assert  opinions there18:20
*** dolphm_ has joined #openstack-meeting18:21
gyeesure, I'll spend some time catching up on on the emails18:21
heckjgyee: cool, thank you18:21
heckj(the keystone stuff has been light - mostly it's been hyperactive discussions on metrics and billing data)18:21
heckj#topics issue and open questions18:21
*** dhellmann has joined #openstack-meeting18:21
heckjGeneral discussion time - I didn't have anything else formal18:21
rafaduranI have some patchs that need review18:22
rafaduranhttps://review.openstack.org/#/c/6447/ https://review.openstack.org/#/c/6448/ https://review.openstack.org/#/c/6425/18:22
rafaduranI don't what's the better way to get attention to them18:23
rafaduranI don't know18:23
heckjyou just did :-)18:23
*** dolphm has quit IRC18:24
heckjrafaduran: you can also request specific reviewers (heckj, termie, dolphm, bcwaldon, etc) when you go to the review page. It's a good way to "poke" someone to review your code18:24
dolphm_rafaduran: as i said in the reviews, this functionality is already covered by the core api spec, and your implementation doesn't match that18:24
rafaduranheckj: thx, I will do that way next time18:24
dolphm_rafaduran: those features were present pre-redux, and i'd be happy to see them return18:25
dolphm_rafaduran: but not under a whole new api18:25
rafadurandolphm_:I've sent new patches18:25
dolphm_rafaduran: unless we're changing the *whole* api :)18:25
cloudflyi was going to post a question about preventing mitm attacks on keystone to the list  =/18:25
cloudflyi hope it does not get large18:25
heckjcloudfly: give it a shot - hard to tell :-)18:25
dolphm_rafaduran: ah, i'll take another look then - totally didn't notice18:26
rafadurandolphm_: ok, thx for your attention18:26
*** Yak-n-Yeti has quit IRC18:30
heckjdolphm: My thought is to aiming for a fairly heavy revision, consolidating token more than really changing it, and bringing many of the extensions into core18:30
heckjand adding the CRUD elements with the expectation that backends may return "not implemented" as a valid response18:31
dolphm_heckj: i'm all for that, generally speaking18:31
heckjOther questions or issues? ideas? etc?18:31
dolphm_heckj: and i'm all for simplifying the service catalog18:31
*** joearnol_ has quit IRC18:32
gyeeby simplifying you also mean maintaining backward compatibility as well right?18:35
jsavakor at least have it under v3.018:36
gyeeopen season for v3.0 :)18:36
dolphm_or we could skip to 4.018:36
*** joearnold has joined #openstack-meeting18:37
dolphm_or more appropriately, v418:37
*** tong has quit IRC18:37
*** Yak-n-Yeti has joined #openstack-meeting18:37
heckjgyee: maintaining backward compatibility will be keeping the same versioned API - my proposal will be to make a new versioned API for this next round18:40
heckjAnd being able to run both of them together18:40
gyeenice18:40
heckjOkay - I think that's it for today's meeting18:42
heckj#endmeeting18:42
*** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)"18:42
openstackMeeting ended Tue Apr 24 18:42:25 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:42
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-04-24-18.05.html18:42
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-04-24-18.05.txt18:42
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-04-24-18.05.log.html18:42
heckjhttp://wiki.openstack.org/Meetings/KeystoneMeeting updated - I'll be back around next week! (and on IRC lurking)18:43
*** anderstj has joined #openstack-meeting18:47
*** ravi has quit IRC18:49
*** littleidea_ has joined #openstack-meeting18:51
*** littleidea has quit IRC18:51
*** littleidea_ is now known as littleidea18:51
*** littleidea has quit IRC18:56
*** tong has joined #openstack-meeting18:58
*** clarkb has joined #openstack-meeting19:02
sorenmtaylor: CI meeting?19:02
LinuxJedisoren: you took the words right out of my fingers :)19:02
* LinuxJedi notes to kick mtaylor earlier next week :)19:03
ttx.0o.19:03
jeblair...19:04
LinuxJediwant me to start it?19:04
jeblairlets do it19:04
LinuxJedi#startmeeting19:04
openstackMeeting started Tue Apr 24 19:04:24 2012 UTC.  The chair is LinuxJedi. Information about MeetBot at http://wiki.debian.org/MeetBot.19:04
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.19:04
LinuxJedi#topic CI meeting19:04
*** openstack changes topic to "CI meeting"19:04
jeblairI'll start talking...19:04
LinuxJediHi guys, welcome to this week's CI meeting, really 2 weeks since we were all at the summit19:04
* LinuxJedi hands over to jeblair19:04
jeblairmtaylor has a list of work items for us collected from the summit19:05
jeblairreal soon now, he's going to make bugs from them, de-dup, etc.19:05
*** dwcramer has quit IRC19:06
jeblairi'm expecting to work on improving the gerrit trigger plugin19:06
jeblairstarting soon.19:06
jeblairto add better support for matrix and triggered jobs.19:06
LinuxJedi\o/19:06
sorenCool beans.19:07
jeblairthat will help with some of the automatic job creation LinuxJedi is doing, as well as make things nicer for other CI systems that plug into us19:07
ttxjeblair: I'd like us to brainstorm the "separate baking" while at UDS19:07
jeblair(that's a couple steps away, but a better job structure would let us do things like run some tests immediately on uploads, so others can trigger their jobs on that)19:08
ttxso it would be good if you could spend some time thinking about that in the next week19:08
jeblairttx: yes, that's at least one, maybe 2 or 3 of the items on the list.19:08
sorenSeparate baking?19:08
ttxsoren: experimental branches to keep crap out of release branch19:09
sorenTopic branches?19:09
* LinuxJedi assumes we can't bake the cookies and cakes at the same time19:09
ttxnot formally topic branches19:09
sorenRight. That. Cool.19:09
ttxsince the term is overloaded a bit19:09
ttxand bleeds into implementation detail19:09
*** Shrews has joined #openstack-meeting19:09
jeblairi'm going to take next week off, so maybe we can regroup on that during UDS week?19:10
sorenWho will be at UDS?19:10
soreno/19:10
jeblairo/19:10
* LinuxJedi can't make it unfortunately19:10
ttxjeblair: sure thing19:10
LinuxJediplus they may hate the fact I run Fedora ;)19:10
sorenLinuxJedi: People have been thrown in the pool for less.19:11
jeblairmtaylor hopefully will be.  everybody poke him and tell him it's important.19:11
sorenjk :)19:11
LinuxJedilol :)19:11
clarkbremind me when he gets back19:11
jeblairoh.  clarkb just started!19:11
LinuxJedioh so, everyone, say hi to clarkb.  A new member to the CI team19:11
sorenhi to clarkb19:12
clarkboh hi19:12
Shrewshiya clarkb19:12
LinuxJediShrews is also getting up to speed and we have some evil... I mean great things for him to cut his teeth into soon19:12
Shrewsyay! … i mean, booo19:13
LinuxJedijeblair: any other cool stuff on your side?19:13
jeblairthat's all i can think of right now19:14
LinuxJediok, on my side:19:14
LinuxJediwe have a big improvement to the puppetized automatic Jenkins job creator thing coming very soon.  This will help both Openstack and Stackforge19:15
LinuxJediwe have parameters for more stuff19:15
*** joearnol_ has joined #openstack-meeting19:16
LinuxJedijeblair and I (mostly jeblair) have been tweaking a few things in gerrit's source to make some subtle improvements to the look of it (hiding silly 'X's and background colour on outdated branches)19:16
LinuxJediI have everything ready to put meetbot into puppet.  So hopefully that will happen in the next week and will be much easier for us to manage19:16
jeblairactually darraghb wrote the code to fix "X"19:17
LinuxJediwe also have some improvements to meetbot lined up19:17
*** joearnold has quit IRC19:17
LinuxJediah, awesome.  Ok, thanks to darraghb then ;)19:17
jeblairI've just been writing the puppet commands to cause the servers to upgrade.  :)19:17
LinuxJediso many branches went through CI today I lost track of who owned what ;)19:17
jeblairwhich is great, cause that's exactly the system we wanted.  it's now easier for us to take code contributions to gerrit and implement them in production.  :)19:18
LinuxJediin the next week I think I will be concentrating on improving Stackforge since there has been quite a lot of interest and it isn't quite as all automated to add projects as I would like yet19:18
*** dwcramer has joined #openstack-meeting19:18
* LinuxJedi also has lots of new CI docs to write after everything we have been doing over the last couple of weeks19:19
jeblairyes, sdake from the "Heat" project just popped into #openstack-infra and it sounds like they might be a good fit for stackforge19:19
jeblairhe's going to run it by the rest of the heat developers19:20
LinuxJedierm... I think that is all I have right now.  There was lots of things in the CI talk summit but those will appear as bugs later on19:20
*** pcrews has joined #openstack-meeting19:20
* LinuxJedi has a template for a stackforge website mostly baked but no content at the moment. Something else to do this week19:20
*** jk0 has joined #openstack-meeting19:21
* LinuxJedi is sure mtaylor has lots to add to this meeting for those who weren't at the CI talk in the summit last week, but that may have to wait19:22
jeblairhttp://openstack-ci.github.com/publications/ci-roadmap-folsom/index.html19:22
ttxCould be good to track the biggest efforts (think I18N) as a blueprint rather than a bug ?19:22
jeblair#link http://openstack-ci.github.com/publications/ci-roadmap-folsom/index.html19:23
jeblairis the presentation with (nearly all of) the items we had identified during the summit19:23
LinuxJedijeblair: excellent point, I keep forgetting about the publications stuff19:23
jeblair(as well as things we did during essex)19:23
LinuxJedittx: yep, that one in particular will probably be one or more blueprints19:23
LinuxJedijeblair: it almost looks like we did work in the last 6 months19:24
ttxwhenever I'm back to 100% I'll check that nothing was forgotten there19:24
LinuxJedittx: awesome, thanks :)19:24
ttxjeblair: were you the one suggesting that we should outsource our mailman support ?19:24
jeblairttx: a little more nuanced than that...19:25
LinuxJedittx: did I suggest it?  (I was thinking it at the time)19:25
jeblairmore like "it's great that launchpad runs our mailing lists right now so we don't have to"19:25
jeblairand "it's a good deal of work to run mailing lists properly (spam, delivery problems, etc)"19:25
LinuxJedi++19:25
ttxwe actually have a mailman instance running19:25
ttx(lists.openstack.org)19:26
LinuxJedittx: who manages it?19:26
jeblairyeah, and pretty much no one manages it.  which works fine until you start having bigger, more important lists that people care about19:26
sorenLinuxJedi: You do. Didn't you get the memo?19:26
ttxsome troll in a closet, afaik19:26
* soren kids19:26
LinuxJedisoren: lol, that wouldn't surprise me actually, I somehow owned a lot recently by accident ;)19:26
jeblairso basically, i don't feel like it's something monty, andrew, and i can do in the margins, as it were... but...19:27
ttxjeblair: would you have suggestions of where we could set it up instead ?19:27
LinuxJediif any company wants to invest time in it too maybe we could do something?19:27
jeblairif there are more resources/people that want to contribute to it, we are _very_ happy to help do it within the server management infrastructure we've set up.19:27
jeblairor, perhaps it's easier to subscribe to a service that will do it for us.  :)19:28
ttxmmmmkay19:28
* LinuxJedi suspects something that Rackspace may have resources for?19:29
LinuxJediat least for mail filtering/spam19:29
ttxLinuxJedi: Rackspace runs the current one.19:29
LinuxJediah!19:29
ttxwe just don't know how serious they actually are about it :)19:29
LinuxJediso, maybe something for us to investigate further19:30
ttxI will probably have to look into it19:30
ttxjeblair: is your "pretty much no one" the result of an analysis, or a gut feeling ?19:31
LinuxJedittx: well, I'm sure someone in our team can look into the best solution19:31
jeblairttx: a talk with stef19:31
mtaylormorning19:31
LinuxJedimtaylor: welcome!19:31
mtaylorsorry I'm late - had trouble finding working internet - now solved19:31
ttxmtaylor: you flew out of the US ?19:32
ttx(to solve that issue ?)19:32
mtaylorttx: it's the usual solution19:32
*** joearnol_ has quit IRC19:33
LinuxJedimtaylor: I hand this meeting over to you (me and jeblair covered all our stuff)19:33
mtaylorI'm mostly not even here today - so you guys feel free to keep up the good work19:34
LinuxJedioh, ok :)19:34
LinuxJedianyone have anything else to add today?19:34
*** dolphm_ has quit IRC19:34
LinuxJedi#action research a mailing list solution19:34
jeblairnope19:35
LinuxJediadding that as an action item ^19:35
ttxLinuxJedi: will talk to you about features we might want in19:35
LinuxJedito find out more about the current mailman and a new one19:35
* Shrews is working on tox changes to inject dependencies from jenkins runs without modifying tox.ini19:35
jeblairShrews: woot!19:36
Shrewsbut having an issue with the tox test suite, so can't push upstream just yet.19:36
jeblairhehe19:36
LinuxJediso, basically we want something that CI team can manage as far as infrastructure is concerned but not manage at the message/spam level19:36
LinuxJedimultiple lists and maybe some review system like gerrit to add new lists19:37
LinuxJediwhich would be cool if CI puppet owned that part19:37
LinuxJedior just Launchpad but from the sound of it others aren't happy with that?19:38
*** joearnold has joined #openstack-meeting19:38
jeblairoh, so there was a requirement collected at the summit for lists that can have sub-topics19:39
jeblairwhich is a mailman feature launchpad does not expose19:39
jeblair(i wasn't at that session, i'm relaying second-hand)19:39
jeblairttx: is there an etherpad from that session?19:39
LinuxJedijeblair: none of us were unfortunately19:39
ttxjeblair: there was, but it didn't capture 100% of the spirit19:39
jeblairand also, mailing lists that aren't slower than molasses is an oft-requested feature.  :)19:40
ttxdue to Wifi Fail19:40
LinuxJedi#link http://etherpad.openstack.org/FolsomCommunication19:40
LinuxJedittx: requirement for the next summit: a wifi that can handle more than a couple of hundred users ;)19:40
ttxjeblair: where is sub-topics documented ?19:40
ttxjeblair: I searched and could not find such a feature19:41
jeblairttx: you mean in standard mailman?19:42
jeblairttx: http://web.mit.edu/lists/mailman/topics.html19:43
jeblairthere's also the umbrella list concept19:43
ttxjeblair: looked at umbrealla and siblings, but they do not really do what we want them to19:43
jeblairwhere you have multiple lists (like nova-volume) and nova is subscribed to it.19:44
jeblairyeah.  similar, but different details.19:44
jeblairhonestly though19:44
ttxwhat we want is enforce use of prefixes19:44
ttxif that allows topic-specific subscription, why not19:44
jeblairwe should consider very carefully whether we want to use mailman topics.  they are _complicated_19:45
ttxfrankly, I think enforcing house rules on a single ML will do19:45
ttx(single -dev ML, I mean)19:45
jeblairit's worth a try, i think.19:45
ttxnot sure we should go through the hassle of a complex setup just to kinda enforec the setting of a prefix19:46
ttxwill look into topics.19:46
ttxbut they seem to be the other way around (allow topic-specific subscription, do not enforce a topic being set)19:47
jeblairyou might be able to enforce prefixes with sender filters (i doubt launchpad exposes that either)19:47
* LinuxJedi personally doesn't like the fact that mailman signups and Launchpad signups will probably be disconnected19:49
ttxjeblair: I think there is general consensus that we'll need more than Launchpad ML. If only to have fast discussions19:49
* LinuxJedi agrees there19:49
ttxLinuxJedi: so you need to find an ML provider that takes OpenID :)19:50
LinuxJedi++ :)19:50
LinuxJedibound to be one if we look around19:50
ttxlists.openid.net being a mailman instance, they would know :)19:50
LinuxJedihehe, something we will look into :)19:51
LinuxJediI'd rather not own a mailman patch but that is also an option19:51
LinuxJediok, so any more things before we sign-off?19:52
*** ryanpetrello has quit IRC19:53
LinuxJediwith that I shall end the meeting, see you all next week :)19:53
LinuxJedi#endmeeting19:53
*** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)"19:53
openstackMeeting ended Tue Apr 24 19:53:56 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:53
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-04-24-19.04.html19:53
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-04-24-19.04.txt19:54
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-04-24-19.04.log.html19:54
*** ryanpetrello has joined #openstack-meeting19:54
*** pcrews has left #openstack-meeting19:54
*** liemmn has quit IRC19:56
*** Shrews has left #openstack-meeting19:58
ttxo/20:00
ttxAnyone around for PPB meeting ?20:00
Duglurking20:00
danwenti'm here20:01
sorenThere's a PPB meeting today? I must have missed the announcement.20:01
danwenti didn't get an email, I don't think20:01
*** johnpur has joined #openstack-meeting20:01
ttxThere might be an informal PPB meeting today20:01
sorenSeems /very/ informal so far :)20:02
ttxdanwent: did you receive the emails where Vish asked for the meeting ?20:02
johnpurhey folks20:02
*** dhellmann has quit IRC20:02
danwentttx: don't think so.  I can check my spam filters20:02
ttxdanwent: you need to subscribe to the list. You did not do that20:02
vishyhi20:02
ttxdanwent: https://launchpad.net/~openstack-poc <-- click "subscribe"20:03
danwentttx: I believe I did that last time we had this conversation, but i'll check again :)20:03
vishyI was off yesterday so my request was outside the 24 hour window20:03
vishy:)20:03
johnpurhi Vish!20:03
ttxdanwent: you don't appear on https://launchpad.net/~openstack-poc/+mailing-list-subscribers so I bet you didn't :)20:03
ttxvishy missed the 24-hour window so this can't be an official meeting, but NOBODY WILL PREVENT US from talking.20:04
danwentttx: huh, yeah.  openstack-poc was listed on my set of mailing lists, but my delivery preference was set to "don't subscribe".  my fault :)20:04
vishyare you sure!20:04
vishy?20:04
*** edygarcia has joined #openstack-meeting20:04
* ttx talks to vishy.20:05
vishybasically I want to find out if there needs to be ppb level involvement for 3rd party apis20:05
vishyor if we are just managing it in project20:05
vishythere was some push towards openstack being about the api not the implementation20:05
ttxvishy: what do you call "3rd party api" exactly ?20:05
vishydoes that mean if a project wants to include occi or cimi for example20:05
vishy(or conversely doesn't want to include it)20:05
vishythat either is ok?20:05
notmynameI'm here20:06
notmynameincluding aws APIs20:06
*** dwcramer has quit IRC20:07
vishynotmyname: yes I'm including everything outside of openstack api20:07
notmynamejust wanted to be explicit :-)20:07
johnpurvishy: if we have the canonical OS API as "native", I don't see why we would object to other API's being introduced that either proxy or are added as "extensions"20:08
danwentone tricky issue is that third-party APIs are likely to cut across projects (e.g., Amazon API includes networking, volumes), so making decisions per-project might be tough.20:08
DugIMO this might go to a bigger issue since consistency across the API is important too and might not be left as an exercise for each project.20:08
vishydanwent: true20:08
vishyDug: we've decided in the past that ppb can set policy for best practices for apis, but that individual apis are managed in-project20:08
ttxvishy: my first thought would be... as long as the project doesn't have to pick one (think a default), and that API is well-supported... I don't see why the PPB (or future TC) would interfere.20:08
notmynamejohnpur: some of the biggest concerns is protecting the core devs and keeping the codebase simpler20:09
johnpurconsistency would be achieved by the implemtors, if they have to orchestrate across multiple OS API's20:09
*** mjfork has joined #openstack-meeting20:09
ttxvishy: the PPB could technically complain that a half-supported API taints the quality feel of the project20:10
vishyso the easiest solution I think is to just say other apis are not our problem20:10
ttxvishy: but as long as it's well done...20:10
danwentI tend to view such third-party APIs more as just clients on the main OS API(s).20:10
vishyimplementers are welcome to create an affiliated project and try to get the distros to support them20:10
johnpurnotmyname: if we separate the concerns (OS API vs higher level/proxied API) the core devs don't even need to know someone is providing the alternative API (they are consumers of the project's API)20:10
heckjo/20:11
vishyjohnpur: That is ideal for us, it is a terrible story for the implementers of those apis though20:11
johnpurwhy so?20:11
notmynameI agree. but meanwhile we have people proposing APIsinto the core codebase (and existing support there)20:11
vishyjohnpur: they would like to be able to say openstack supports their api20:11
*** dolphm has joined #openstack-meeting20:11
vishyjohnpur: so they are all pushing to get into core20:12
notmynamedefaults matter, so they want to be in the core codebase (vishy +1)20:12
notmynameand then things get political20:12
Dug@vishy - agreed.  A really selling for OS (over aws) will be to claim its standards based - as an example.  And if there's no guarantee that OS (by default) ships with a standard API then I don't think OS can make that claim.20:12
johnpurvishy: different question then. if we accept that folks *can* provide alternate API's, the issue you are raising is "blessing" by OS...20:12
Dug(not I said "ships" not "is turned on")20:13
Dugs/not/note/20:13
vishyjohnpur: I think inclusion in core is perceived as de-facto blessing20:13
tong@johnpur, it may be the other way around. The standard bless OS.20:13
heckjvishy: I think it is too20:13
johnpurIMO, we have only 1 API in core, the OS API (and I know this means some work for Nova)20:14
notmynamevishy: agreed. and the cost is high for core devs maintaining it and reviewing it20:14
ttxvishy: so your question is about including a piece of code that is technically correct... but that might not fit into the definition of "what is OpenStack", which kinda belongs to the PPB right now ?20:14
vishyttx: I think we need a consistent story about what to do with this type of thing20:14
vishyis it a model where we just accept everything and remove it if it breaks20:15
vishyor a model where we accept nothing and everything goes into separate projects/repos20:15
vishyor is it completely up to the project?20:15
vishyI'm asking because all the ptls will be dealing with this, especially in the case of CIMI/CDMI20:15
ttxso far it was up to the project, and Nova opted for "accept everything" afaict20:15
johnpuragree we need to be consistent...20:16
Dugconsistency is good and I think consumers will expect it20:16
vishyand it is going to be awkward if it is different20:16
ttxjohnpur: I agree with you... the question is, where do we draw the line20:16
johnpurttx: nova accepts everything? what has been accepted beyond OS and EC2?20:16
ttxjohnpur: it's not just about APIs. Nova accepted many hypervisors for example20:17
johnpuraha20:17
notmynamehypervisor support is different IMO20:17
johnpurfor good reason :)20:17
ttxWhere do we draw the line ? Only external APIs ?20:17
Dugif people agree that consistency is important than this can't be decided on a per-project basis.20:17
notmynameya, I think this is consistency for external APIs20:18
johnpurdug: agree20:18
ttxif you ask the PPB to decide if a given feature fits in the OpenStack product, that means it vets all proposed features in core projects20:18
johnpurnotmyname +120:18
ttxok, external APIs only.20:18
*** bcwaldon has joined #openstack-meeting20:18
vishykeeping in mind that none of this is saying whether or not a 3rd party API could be created or even shipped with a distro20:18
vishy(or even be proposed as an incubated project)20:19
Dugright - at least for things that impact the external facing side of things - might be annoying, but I think consistency is that important for consumers.20:19
tong@ttx, probably make it that anything is middleware can be accepted which has small impact in terms of deployment.20:19
johnpuractually, if we talk about mechanics or logistics... do the 3rd party API's get into the functional test suites? gerrit gates? etc.20:19
heckjjohnpur: I think they should20:20
*** markvoelker has quit IRC20:20
heckjjohnpur: interop is the greatest thing that we're offering behind our "product" of OpenStack20:20
vishynotmyname: I think offering 3rd party test integration is underway regardless20:20
ttxvishy: this discussion tends to prove that the PPB should definitely be involved more formally. Worst case scenario it could vote "projects decide"20:20
Dugthey should have the same bar as the OS APIs - if they can meet it then they should not be accepted20:20
*** kindaopsdevy_ has left #openstack-meeting20:20
johnpurdug: lol, cannot?20:21
notmynameDug: accepted is an interesting wrod thee20:21
DugLOL oops20:21
Dugyes "cannot"  - sorry  :-)20:21
notmynameDug: if CI is provided for third party projects, there is nothing to "accept" or "reject".20:21
*** littleidea has joined #openstack-meeting20:22
ttxvishy: and now that I understand the question, I could definitely use a bit more time to think about it before deciding.20:22
*** dprince has quit IRC20:22
notmynamettx: you have a week :-)20:22
*** dwcramer has joined #openstack-meeting20:22
johnpuri think the point is that if the CI fails it shouldn't be merged (not "accepted")20:22
vishyttx: cool, should we start an ml thread?20:22
ttxvishy: do we already have a complete list of candidate 3rd-party APIs ?20:22
vishyttx: OCCI and CIMI/CDMI are the only ones I know of20:22
Dugyes "merged" - still learning the proper terms20:23
ttxvishy: sounds like a good idea.20:23
notmynamejohnpur: but that's the case now. to me the bigger question is are we going to include them in the codebase or not20:23
johnpurvishy: coming out of SF do you have a defined gameplan for the EC2 API?20:23
* ttx needs to RTFM on those a bit20:23
vishyjohnpur: defined plan was to bugfix it in place and see how AWSOME comes along, with potential to move it over20:23
Dug@ttx bring coffee20:23
vishyI'm just discussing in dev prototyping a split into a separate repo20:23
Dug:-)20:23
johnpurOK... do you know if anyone is also looking at the CloudBridge effort?20:24
notmynamejohnpur: swift would prefer to prune swift3 and CDMI APIs20:24
notmynameFWIW, I've seen rumors that AWESOME is not license-compatible with openstack20:24
vishymight be nice to see how hard it is to manage stuff separately. If it works, we could use it as a model for other apis that come down the pipe20:24
vishynotmyname: it isn't currently20:24
ttxnotmyname: they are supposed to relicense under Apache2 if we want it20:25
vishynotmyname: it was discussed that they would be open to changing if that presents a problem20:25
notmynameah. interesting20:25
ttxnotmyname: that said, stacking APis migt not be the best way, as evidenced by the discussion on the ML20:25
vishyttx: we are going down the path of versioning the rpc api anyway20:26
ttxsounds like proper API plugins on top of a clean internal API could be easier... and turn that 3rd party API discussion into a core plug-in vs. official vs. ecosystem plugin discussion20:26
vishyttx: so 3rd party api plugins could write to the rpc layer if necessary for performance20:26
vishyttx: the db is a little trickier20:26
ttxthe db is always a little trickier20:27
notmynameI think options are to 1) include all comers into the codebase, all equally blessed 2) bless a subset of 3rd party APIs 3) don't bless any 3rd party, but don't discourage them either20:27
vishyttx: honestly i don't see an advantage to plugins sharing the db.20:27
danwentnova versioning an rpc doesn't solve the entire problem if the API needs to manage network, volumes, etc.20:27
Dugwould that put os, ec2, occi, cimi all at the same level in the repo?  and then each distro would decide which to grab?20:27
vishyttx: so we may just have to enforce that plugins do db management separately.20:27
ttxDug: we would certainly bless os as a "core" plugin or something20:28
*** bhall has joined #openstack-meeting20:28
vishydanwent: true, it would probably have to take a different approach with each project20:28
johnpuri don't think allowing a distro to *not* provide the OS API is a good thing20:28
vishydanwent: but you could have a ec2 project that could talk to nova and volume via rpc and quantum via rest20:29
ttxjohnpur: we already do.20:29
danwentvishy: sure, just wanted to make sure people where aware that this would be the case.20:29
johnpurttx: really?20:29
heckjttx: which one isn't?20:29
*** jsavak has quit IRC20:29
ttxjohnpur: nothing forces the distributions to ship OSAPI.20:29
ttxjohnpur: so we "allow" it.20:30
vishyDug: I was thinking of OS living in the core repo as an example of an api implementation20:30
vishyDug: but it would talk through the same versioned interface that the other apis could talk through20:30
*** xsad has joined #openstack-meeting20:30
ttxheckj: not saying a distro does not... johnpur was talking about "not allowing distros to not ship OSAPI"20:30
johnpurnow we might have an interesting ppb discussion... w/o the OS API no wordmarks, trademarks, or other identifying term to indicate "OpenStack" should be allowed20:31
*** edygarcia has quit IRC20:31
ttxjohnpur: indeed.20:31
heckjvishy: and then (in an ideal world?) other projects live in separate repos to provide the other APIs?20:31
notmynameheckj: +120:31
heckjjohnpur: ++20:31
ttxheckj: +120:32
vishyheckj: yes, and it is the responsiblity of those projects to generate their own mindshare20:32
Dugseparate repo would not encourage the proper examination I think these other APIs might need20:32
notmynamejohnpur: we can't prevent a project from completely wrapping an openstack project and not exposing the openstack API. a current example is what gluster has done with swift20:32
vishyheckj: if people like them and use them, then distros will start offering them20:32
notmynamesortof20:32
ttxheckj: and then we are back to the next interesting discussion... categories of plugins. Core Official Supported Ecosystem Satellite ...20:32
notmynamewe could not try to manage 3rd party plugins (we have plenty to manage as it is) and let the community come up with ways to manage openstack plugins/extentions/etc20:34
ttxI think we'll have "Core plugins" for the things that can be plugged out but are the default options... "Official" or "Supported" plugins for stuff that goes through our dev infra and community20:34
notmynamesee greesemonkey and userscripts as an example20:34
ttxand "Ecosystem" or "Satellite" for external stuff20:34
johnpurnotmyname: it is a policy decision about whether we allow that to self-identify as OpenStack20:34
notmynamejohnpur: "* for openstack" is fine20:34
notmynamethat's covered under existing trademark policy20:35
johnpurhmmm... i need to go back and re-read. could be wrong, i thought we had hashed this out, and the API was required.20:36
ttxwe should decide everything before the foundation starts stealing our toys :)20:37
vishysigh, computer froze, checking logs20:40
johnpur4 minutes of silence :)20:40
ttxvishy: nothing happened :)20:41
vishy:o20:41
heckjheh20:41
ttxvishy: in fact YOUR COMPUTER DIDN'T FREEZE20:41
ttxthe world around it did.20:42
*** blamar_ has joined #openstack-meeting20:42
*** blamar has quit IRC20:44
*** blamar_ is now known as blamar20:44
*** sandywalsh_ has quit IRC20:44
notmynameheckj: vishy: someone suggested that we manage community stuff in the project's README20:45
heckjnotmyname: how so?20:46
notmynameinstead of managing a contrib/satellite list of projects at an official website, keep a list of links in the README20:47
heckjnotmyname: minimally functional, but I think we'd be better served with a website. I suspect that if we (as a project) don't do it, someone else will - and maybe several someones20:48
notmynameheckj: ya, I'm leaning that way too for the long term20:49
heckjnotmyname: I thought Monty was moving ahead with a basic "here's something related to OpenStack" web site as it was - just now official stamps of approval or such20:49
heckj(now --> no)20:49
notmynameok20:49
tongif that is the case, then people will have to deploy with extra steps. normally that will work well for customers.20:50
heckjtong: presumably there would be a base openstack instance/installation, and then whatever plugins could be added in after that.20:51
heckjkeystone, like quantum (I think) wants to support back-end drivers that aren't nessecarily open, but have a functional & completely open default that gets installed as a baseline20:52
tongright, I got that part, but it won't be a nice story to tell to customers.20:53
heckjtong: sorry, I'm missing your point of view there, why not?20:54
notmynametong: right. 2 installs instead of one20:54
tongthese extra steps to download and configure won't be really nice for a guy to install these plugins.20:54
notmynamewhile I agree it's not as simple if there are multiple install steps, I don't think that's a heavy burden to put on deployers20:55
*** belliott has joined #openstack-meeting20:55
heckjtong: so you'd prefer to have all options available as a single installation and then use - er, configuration - to decide what's enabled and what isn't?20:55
notmynametong: and, for example, you could provide a bundled version20:55
heckjnotmyname: ++20:56
notmynamefor your users20:56
*** russellb has joined #openstack-meeting20:56
*** somik has joined #openstack-meeting20:56
tongI do suggest to have a plugin directory and put accepted plugins in these directory and these plugins will be available for anyone to use.20:56
notmynametong: in the core repo?20:57
tongyes.20:57
xsad@tong ++20:57
*** lloydde has joined #openstack-meeting20:57
tongif not the core repo, anyone can setup repo and do their own stuff.20:57
heckjtong: I believe the key argument is that such a mechanism is putting a large (overwhelming in some cases) burden on the core developers to review all plugins that could be potentially used.20:57
notmynamemy concern is protecting the core reviewers from having an ever-expanding scope of code to review20:58
jgriffithIf you do that it's not really a \"plugin\" any more is it?20:58
notmynameare we continuing this on the ML or next week's meeting time?20:58
xsadbut when we said plugins , they are supposed to be used selectively , not responsibility of the core repo20:59
notmyname(1 minutes until the next meeting in here)20:59
tongif things go into plugins (or contri), then it should be considered as such.20:59
heckjnotmyname: I'm fine either way20:59
*** sandywalsh_ has joined #openstack-meeting20:59
heckjI need to do more reading on the CIMI/CDMI apis as it is20:59
tongthese things should no impact the core unless it is enabled.20:59
xsadbut have we decided what all stuff can be run from plugins?20:59
tongshould not,20:59
vishynotmyname: both21:00
notmynamecool21:00
ttxok, time for next meeting21:00
vishynotmyname: email thread and hopefully have some actual votes next week21:00
*** gabrielhurley has joined #openstack-meeting21:00
ttxbcwaldon, devcamcar, danwent: around ?21:01
bcwaldonttx: yep yep21:01
danwentyup21:01
ttxis anyone replacing devcamcar ? gabrielhurley ?21:03
ohnoimdeadi can21:03
ttxohnoimdead: cool21:03
heckjttx: ^^21:03
ttx#startmeeting21:03
openstackMeeting started Tue Apr 24 21:03:41 2012 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.21:03
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.21:03
ttxToday's agenda: http://wiki.openstack.org/Meetings/ProjectMeeting21:03
ttxWe are still recovering from the Design Summit, I'd like to get some feedback from it while it's fresh21:03
ttxBut first, let's discuss the Folsom release schedule for a bit21:04
ttx#topic Proposed release schedule options21:04
*** openstack changes topic to "Proposed release schedule options"21:04
ttxFor the projects wanting to follow a common schedule, please see the options at:21:04
ttx#link http://ubuntuone.com/4J6FGOsWNdTCpUWUf9S87X21:04
ttxthere are 4 options outlined in there21:05
ttxlet me know if you can't read it21:05
med_reads fine.21:05
ttxFirst I'd like to confirm whether you want to have 4 milestones + final release (option A, milestone every 4-5 weeks)21:05
ttxor 3 milestones + final release (options B to D, milestone every 5-7 weeks)21:05
*** GheRivero has joined #openstack-meeting21:05
ttxFor Essex we did 4 milestones + Final release (every 5-6 weeks)21:05
ttxAt the design summit the PTLs present said 3 milestones + final release was preferable21:05
ttxespecially if we want to keep the option of using milestones as "releases" toward the end of the cycle if ready21:06
ttxI don't think Dan, Devin and Joe were there though.21:06
heckjttx: I'm in agreement with that21:06
ohnoimdeaddevin agrees (i hope)21:06
ttxheh21:06
danwentI'm ok with that.21:06
ttxAnother question: Do you prefer to have one week between release and design summit (options B, D)... or two weeks (option C) ?21:06
annegentlein docland we did talk about it, but not sure resources are there to track docs with milestones (regardless of 3 or 4)21:07
ttxso far we did one week... and it puts some stress on our collective shoulders21:07
danwentthings were pretty rushed with essex release and folsom summit21:07
heckjdanwent: ++21:07
danwentand I noticed people pulling back from testing to begin prepping for the summit, which was bad21:07
ttxI don't want to "lose" too much time between the two, but I could use a week to breathe21:07
heckjttx: I'd prefer 2 weeks given the option.21:08
*** edgarmagana has joined #openstack-meeting21:08
*** Yak-n-Yeti has quit IRC21:08
vishyttx: I like C with the extra time21:08
ttxC is pretty regular21:08
johnpostlethwait2 weeks is probably better/safer: Option C21:08
russellbI like C too fwiw :)21:08
ttxdon't book travel just yet :)21:08
xsadC ++ :D21:08
annegentlehee21:09
ttxI'll pursue C as the proposed option.21:09
ttxohnoimdead: if C causes problems to Horizon, let me know soon21:09
ttx#topic Keystone status21:10
xsadso first agenda is done ?21:10
*** openstack changes topic to "Keystone status"21:10
ttxxsad: yes21:10
ttxheckj: Could you sum up the main outcome of the Keystone sessions for us ? (if any)21:10
*** rkukura has joined #openstack-meeting21:10
*** ttrifonov is now known as ttrifonov_zZzz21:10
ttxAnything affecting the other projects that they should be aware of ?21:10
heckjttx: at the moment, not - but some will be21:10
ohnoimdeadttx: i think c is good21:10
*** Yak-n-Yeti has joined #openstack-meeting21:10
heckjttx: looking at taking a number of what were previously extensions and bringing them into core with a new rev API.21:11
heckjproposal for the new API to be up as a google doc (ala Jay Pipes setup) in a few weeks, ideally implemented by F221:11
ttxheckj: ok21:11
ttxheckj: When do you think you'll be able to have the folsom plans filed as blueprints ?21:12
heckjaim is to keep any broad changes mostly done by F2 to propogate and implement with other projects over that last milestone21:12
ttxheckj: I like that21:12
heckjttx: initial blueprints are up there, pending some additional that weren't in the keystone track to get created.21:12
ttxheckj: ok, we could do a Folsom review next week then21:12
*** johnpur has quit IRC21:13
ttxheckj: anything else ?21:13
heckjblueprint for the "v.Next API" pending documenting a proposal21:13
heckjnope21:13
ttxQuestions about Keystone ?21:13
ttx#topic Swift status21:13
*** openstack changes topic to "Swift status"21:13
ttxnotmyname: o/21:13
notmynameo/21:13
ttxnotmyname: A quick summary of the Swift sessions outcome ?21:14
*** dolphm has quit IRC21:14
ttxAnything significant or affecting others ?21:14
notmynameswift sessions went very well, I thought. we've got some good changes coming up (statsd integration and splitting the client library)21:14
*** danwent has quit IRC21:14
ttxAbout splitting the client library. Would that be for the next release ? or some after that ?21:15
notmynameand we've got some other proposals (like CDMI support) that are also dependent on ongoing discussions in the PPB, etc21:15
* ttx needs to align the release machinery for a separate release deliverable21:15
notmynameI'm not sure when we'll split the client lib. probably not in the next swift release, but perhaps for the one after that. either way, I expect it to be int he folsom cycle21:16
*** dhellmann has joined #openstack-meeting21:16
ttxok. I'll try to follow the work on that21:16
ttxnotmyname: Anything else ?21:16
notmynamethinking21:16
notmynamenot I don't think so. lots of exciting stuff at the summit. mostly around a growing installed base21:17
ttxI saw that with my own eyes ;)21:17
ttxQuestions on Swift ?21:17
ttx#topic Glance status21:18
*** openstack changes topic to "Glance status"21:18
*** danwent has joined #openstack-meeting21:18
ttxbcwaldon: How did the Glance sessions go ?21:18
bcwaldonttx: excellent!21:18
bcwaldonWe discussed quite a bit at the summit. It looks like we'll be investigating trusted glance deployments, image replication, image property detection, and the v2 API. I'm working on getting everything set up in blueprints now.21:18
ttxDo you expect to separate the Glance client out of Glance itself ?21:18
bcwaldonttx: yes, already working on that21:18
*** jgriffith has quit IRC21:18
ttxAny timeframe on that ?21:18
bcwaldonttx: python-glanceclient is being integrated into devstack right now21:18
ttxF1 or F2 ?21:19
bcwaldonttx: F1 hopefully21:19
ttxok21:19
ttxWill you have all blueprints filed by next week ?21:19
bcwaldonttx: that would be a good goal to have, yes21:19
ttxcool.21:19
ttxbcwaldon: Anything else you wanted to mention ?21:19
*** markmcclain1 has joined #openstack-meeting21:19
bcwaldonno sir21:20
ttxQuestions on Glance ?21:20
gabrielhurleyjust that https://bugs.launchpad.net/glance/+bug/987654 is a blocker for integrating glanceclient right now21:20
uvirtbotLaunchpad bug 987654 in openstack-ci "glanceclient bin scripts overwrite glance" [Undecided,New]21:20
bcwaldongabrielhurley: yep, I saw that21:20
ttxsounds annoying.21:20
bcwaldongabrielhurley: not sure how to move forward on it :/21:20
gabrielhurleyI wouldn't care except it kills the integration test gate21:20
bcwaldongabrielhurley: it would only break things if the commands were expecting old glance client21:21
*** rnirmal has quit IRC21:21
gabrielhurleynope, check out the log I linked to in the bug report21:21
gabrielhurleyit actually kills the setup of the env21:21
bcwaldonok, we can follow up on this later21:21
gabrielhurleyk21:21
ttxmtaylor and jeblair can certainly help21:21
bcwaldongabrielhurley: but I'll start looking into that now, thanks for bringing it up21:22
ttx#topic Quantum status21:22
*** openstack changes topic to "Quantum status"21:22
johnpostlethwaityeah21:22
ttxdanwent: hey21:22
*** salv-orlando has joined #openstack-meeting21:22
danwenthey21:22
johnpostlethwaitWrong window, sorry.21:22
ttxdanwent: Could you do a quick summary of Quantum track, especially where the decisions affect the other projects ?21:22
danwentyup.21:22
*** dhellmann has quit IRC21:22
*** markmcclain1 has quit IRC21:22
danwentprobably biggest topic was merging in Melange IPAM functionality, which will be part of Quantum in Folsom21:23
*** markmcclain has joined #openstack-meeting21:23
*** dhellmann has joined #openstack-meeting21:23
danwentwe'll also have a heavy focus on making sure functionality like L3 Forwarding + NAT, Security Groups, etc. are implemented in Quantum to give Quantum full Nova parity21:23
ttxdefinitely. I need to know if I should still consider Melange in incubation for milestone release purposes21:23
*** novas0x2a|laptop has joined #openstack-meeting21:23
danwentI believe you should not21:23
danwentbut an email to troytoman wouldn't hurt :)21:24
ttxWould Melange be merged by F1 ?21:24
ttx(in which case it's a non-issue)21:24
*** dolphm has joined #openstack-meeting21:24
danwentWe're shooting for it, but I can't say for sure right now.  When is F1 with new schedule?21:24
danwenteither way, I don't think it makes sense to have melange releases for F21:24
ttxMay 2421:25
danwenti'll talk to troy about it and get back to you21:25
ttxok, thx21:25
ttx#action danwent to see what to do with Melange for F121:25
danwentOther questions were around what it means for Quantum to be core in Folsom, and whether that means it would be "default".  Based on past discussions with Vish, we definitely won't remove old networking managers from nova in Folsom21:25
danwentbut we need to see if Quantum is up to par to be the default in Folsom.21:25
danwentMy goal was to make that call based on the F2 release21:26
ttxI think we can make that decision by F221:26
danwentyup.21:26
ttxgreat minds alike :)21:26
danwent:)21:26
*** User327 has joined #openstack-meeting21:26
ttxbut I'd be "hell yeah"21:26
danwentother touch points are with Horizon, we'll work with them directly to help support their quantum integration work.  that depends on the new api with melange folded in.21:26
ttxdanwent: when do you think you'll be able to finialize digesting the sessions into meaningful blueprints ?21:26
ttxnext week might be a bit short ?21:27
danwentWe're also working with CI team to get gating on quantum (still some issues to sort out here)21:27
danwentttx: spent a good chunk of time on it already.  I think we can have rough bps next week.21:27
danwentI want people to be able to get to work :)21:27
ttxack21:27
ttxdanwent: Anything else ?21:27
danwenti think that's good for now21:27
ttxQuestions on Quantum ?21:27
danwentoh, one more thing21:27
ttxgo for it21:28
danwentwe're going to be in a holding pattern with respect to using the netstack list until the OS community decides on its overall email list strategy21:28
danwenthopefully that will be wrapped up soon.21:28
ttxright. I'm on it. Unfortunately piled up lots of work in the last weeks21:28
danwentunderstood :)21:28
ttx#topic Nova status21:29
*** openstack changes topic to "Nova status"21:29
ttxvishy: hey21:29
vishyheyo!21:29
ttxvishy: Won't ask you for a complete summary, anything particular you wanted to mention ?21:29
vishyso there were an epic amount of discussions21:29
vishyttx: I don't think we have a complete plan regarding upgrades esp. regarding db migrations21:29
vishyrpc versioning and ability to shutdown workers21:29
vishyis part of it that we are well underway21:30
vishyI understand there was a discussion about db migrations at the summit that I missed, but I think we don't have a good plan there yet.21:30
ttxyes, in openstack-common21:30
ttxled by adam_g21:30
vishyok we may need to take that one to the ml21:31
vishyother stuff seems underway, I need to spend the next week or two dealing with blueprints etc.21:31
ttxWhat's the general plan for nova-volumes -> Cinder ? Anything that needs to be implemenetd on Nova side to make room ?21:31
med_are the nova "spinoffs" going to be projects in here?21:31
vishybut the plans all seem pretty clear.21:31
ttxmed_: what spinoffs ?21:31
med_jinx, Cinder for one21:32
vishyttx: there are a couple of things. I'm taking the lead on that21:32
ttxmed_: Cinder is not core, will certainly be incubated in Folsom21:32
vishyI will be shepherding cinder for the first month or two21:32
*** Gordonz has quit IRC21:32
*** dwcramer has quit IRC21:32
vishyttx: there are a couple of changes that need to go into nova that are already proposed21:33
gabrielhurleyif Cinder isn't core, what's the state of volume support for Folsom?21:33
vishythere will be a couple more once python-cinderclient exists21:33
*** tong has quit IRC21:33
ttxgabrielhurley: use of Cinder is supposed to be optional in folsom.21:33
ttxa bit like Quantum was in Essex21:34
gabrielhurleyttx: interesting. nova volume was sort of implicitly core in essex since it was in nova, which is core... right?21:34
ohnoimdeadi thought cinder was nova-volume+?21:34
ttxgabrielhurley: my understanding is that code would survive in Nova in Folsom21:34
med_so will there still be a nova-volume throughout F? and then cutover in G timeframe (similar to nova-network)?21:34
ttxvishy: ?21:34
ttxgabrielhurley: it's not a one-time split, it's a parallel thing.21:35
gabrielhurleyttx: gotcha. interesting.21:35
ttxgabrielhurley: that's my understanding, mind you I wasn't even in the room :)21:35
ttxthat's a second-hand report21:35
vishyexisting code will stay in21:36
ohnoimdeadshould horizon support both?21:36
ttxvishy should be able to confirm when his MacBook unfreezes21:36
vishyuntil we are sure that we should move back21:36
vishy* move over21:36
ttxvishy: Anything else ?21:36
vishyttx: I didn't commit to a specific time frame, but I don't see any reason to remove it prior to the folsom release21:36
*** jgriffith has joined #openstack-meeting21:37
vishybut it will be literally just specifying a different endpoint in settings21:37
vishyto switch back and forth21:37
ttxvishy: it would cause interesting "core nomination" problems.21:37
vishyttx: I was considering that cinder would become the default for folsom21:37
ttxvishy: unless we do fast releases befor ethe end of Folsom, which is a bit unlikely now21:37
vishyttx: but old code would stay in for compatibility21:37
ohnoimdeadone question on nova-client: will we ever get an update in pypi?21:38
vishyttx: I think we need a month to see if we can get everything lined up though21:38
ttxvishy: for Cinder to be default it needs to be core... and you can't be incubated and core in the same cycle so far21:38
vishyttx: does it need to go through incubated?21:38
vishyglance was immediately core when we split it from nova21:38
russellbit was incubated inside of nova :)21:39
ttxvishy: it's not really the problem. I kinda prefer that a core project goes through the whole cycle21:39
gabrielhurleyohnoimdead: mtaylor has committed to doing that. he's just slacking (by his own admission) ;-)21:39
ttxvishy: but we could relax that21:39
ohnoimdeadgabrielhurley: that's why i'm bringing it up. ;)21:39
ttxsince we are getting used to the f21:39
ttxdance*21:39
vishyttx: i expect cinder to be ready to release a milestone along with the other projects21:39
ttx(and Cinder was discussed at the design summit)21:39
vishymilestone 1 probably won't add any new code, just be nova-volumes transplanted into new project21:40
ttx#action ttx to look into relaxing the Core rules for project splits21:40
ttxQuestions on Nova ?21:41
annegentlewho is the team working on Cinder?21:42
ttx(the rule was there to protect the release against late additions that would not suffer under release management the whole cycle, we can certainly relax it for project splits if the first milestones are followed)21:42
* annegentle hunts for docs pros21:42
jgriffithjgriffith, Renuka, Nirmal and Vladimir to start21:42
annegentlejgriffith: ok, thanks.21:42
ttx#topic Horizon status21:43
*** openstack changes topic to "Horizon status"21:43
ttxohnoimdead: How did the Horizon track go ? Anything that the other projects should know about ?21:43
ohnoimdeadtrack went well. main focuses for folsom: workflows, scaffolding for dashboards/panels, making volume/cinder optional, quantum support, new swift ui, more extenisibility, more ux improvements21:44
ohnoimdeadmost of those have blueprints and i'll be adding a couple more over the next couple of days21:44
ttxohnoimdead: do you think you'll have F1 plans as blueprints ready for review next week ?21:45
ohnoimdeadyes21:45
* ttx will create the milestones with dates btw21:45
ttx#action ttx to create F milestones where missing when schedule is ready21:45
*** zaitcev has joined #openstack-meeting21:45
ttxohnoimdead: Anything else ?21:45
ttxQuestions for Horizon ?21:46
ohnoimdeadlet's do this!!21:46
ttx#topic Other Team reports21:46
*** openstack changes topic to "Other Team reports"21:46
ttxannegentle: want to summarize doc track outcome ?21:46
annegentlettx: I want to log maybe 2 blueprints -21:47
*** dhellmann has quit IRC21:47
*** markmcclain has quit IRC21:47
annegentlesummary was lots of people wanting to contribute more operations and daily use content21:48
*** markmcclain has joined #openstack-meeting21:48
*** dhellmann has joined #openstack-meeting21:48
annegentleand publish early publish often21:48
ttxannegentle: got new doc team members signed up ?21:48
ttxjaypipes: around ?21:48
annegentlettx: seems like it - for sysadmins and daily operators especially. It's tough when the processes are very very dev-centered though, need better onboarding.21:49
*** bhall has quit IRC21:49
ttxannegentle: we should discuss together how we can improve that21:49
ttxAny other team lead with a status report ?21:50
annegentlettx: sure, and would love input on easier "just find and fix doc bugs" workflow21:50
ttxFWIW I piled up some work on fixing our communication & bug handling, will post to ML soon21:50
annegentlettx: nice21:51
*** bhall has joined #openstack-meeting21:51
ttx"soon" becoming farther away as we speak21:51
annegentleanother doc note - I plan to "close out" the docs for Essex by May 1 or so21:51
ttxok, good to know21:51
ttx#topic General design summit feedback21:51
*** openstack changes topic to "General design summit feedback"21:51
ttxIt is my understanding that a survey should soon be out, but I welcome your direct feedback here...21:52
gabrielhurleyttx: where are actions following up on the internationalistion meeting?21:52
ttxgabrielhurley: we need someone to take the lead on that. Counting on me is a recipe for failure21:52
gabrielhurleyso the action is find a team lead and make a team? ;-)21:52
ttxthat's what I said in that meeting. We need a I18N advocacy group to pressure the other stakeholders21:53
ttxand the group won't rise without someone committing time to it21:53
gabrielhurleycool. just wanted to follow up.21:53
ttxI'll send something to the ML if that doesn't naturally happen, though21:53
ttxSo, design summit. While it's hot. Anything we should change next time ? Do we need more time ?21:54
danwentwifi was good :021:55
ttxSome people told me the schedule was too busy so they were double-booked all the time... and some others told me they would not survive 4 or 5 days of this21:55
russellbit was my first summit.  i loved it and it left me even more pumped up about OpenStack in general.  My main issue was too many good sessions I wanted to be in.  :-)  <321:55
med_we do need to clone ourselves. but I don't think you want to spread it out to account for double booking.21:55
ttxmy way of cloning is to accept to defer to others to make the right decisions21:56
med_+121:56
ttxI can't really sign up for more work than I can attend sessions anyway :)21:56
med_is it possible to stagger/stairstep the wrapups (maybe that happened to some extent)21:56
annegentleI thought the tracks were well separated by interest - loved that there was a devops track too.21:56
ttxmed_: stairstep ?21:56
annegentleSo you could follow your interest. If you have multiple interest/investments then yes delegation is about the only option :)21:56
* ttx looks up a dictionary21:57
annegentleWhat did you think of the Ecosystem track folks?21:57
ttxannegentle: I think it was great, but we had too many non-Ecosystem talks in there21:57
ttxlike things that was actually Nova or CI but could not fit in other track21:58
ttxhence my suggestion of adding one day21:58
danwentttx: how would it work with conference if we added one day?21:58
med_ttx, I meant not putting all of the track wrapups at the same time (ie, the last hour of the third day)21:58
ttxLots of tracks would have loved to have more time in their track21:58
*** belliott has left #openstack-meeting21:58
ttxmed_: oh, I see. Good suggestion21:58
gabrielhurleyecosystem++, but i second not turning it into the dumping ground/overflow track.21:59
ttxdanwent: the conference could run in parallel. Or the next week, for all I care :)21:59
*** Yak-n-Yeti has quit IRC21:59
russellbone thing that was kind of weird was the overlapping hour vs half-hour blocks.  It led to some odd leaving or joining in the middle of some sessions.22:00
*** ttrifonov_zZzz is now known as ttrifonov22:00
ttxrussellb: it's an artifact of track-specific scheduling22:00
russellbI don't know if standardizing on a single length (45 min?) would be better, though.22:00
ttxif we do 4-5 days, we can standardize on a one-hour track22:01
annegentleWe really need discussions about what the Conference should be, how it helps people, and more details around invites and scaling the events for more and more contributors.22:01
med_there were also a few complaints about the remote access/days22:01
*** ttrifonov is now known as ttrifonov_zZzz22:01
med_there were also a few complaints about the remote access22:01
ttxand just close the discussion if you don't have enough material to fit one hour22:01
*** xsad has quit IRC22:01
annegentle25 minutes was right for many brainstorming sessions and two of the 50 minute ones ended early that I was in.22:01
ttxannegentle: we should try to open up the design of the design summit, earlier rather than later22:02
ttxanyway, time is up22:02
ttxmake sure to mention that in the upcoming survey22:02
ttx#endmeeting22:02
*** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)"22:02
openstackMeeting ended Tue Apr 24 22:02:36 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)22:02
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-04-24-21.03.html22:02
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-04-24-21.03.txt22:02
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-04-24-21.03.log.html22:02
ttxthanks, everyone!22:02
danwentok, time for a quick quantum meeting22:03
danwent#startmeeting22:03
openstackMeeting started Tue Apr 24 22:03:14 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.22:03
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.22:03
danwentor maybe I should first check if anyone is here.  I know several key people said they couldn't make it.22:03
salv-orlandowell, I'm here :)22:03
rkukuraI'm here22:04
GheRiverohere22:04
danwentgreat :)22:04
med_I'm not here.  :^)22:04
danwentboo22:04
danwentok, let's get started.22:04
danwentWe're going to target more of a quick scrum, since quantum is now discussed at the main meeting.22:04
danwentI've been mapping out all of the items we discussed at the summit, dependencies, etc.  I will be harassing people to create blueprints this week.22:05
danwentFor the key topics we need to achieve Nova parity, I'd like to make sure we have a bp by next week, with at least an outline.22:06
*** gabrielhurley has left #openstack-meeting22:06
danwentjkoelker: are you here?22:06
*** markmcclain has quit IRC22:06
*** russellb has left #openstack-meeting22:06
*** edgarmagana has quit IRC22:06
danwent#action get jkoelker to put together bp for melange integration22:06
danwentcarlp: around?  bp on dhcp?22:07
danwentOk, sounds like this is a losing strategy :)22:07
salv-orlandomaybe they are writing the bps...22:07
*** dhellmann has quit IRC22:08
danwenthaha :)22:08
cdubah, just no topic change...22:08
danwentOk, anyone who's actually here need to talk about BPs?22:08
danwentotherwise, we can call it a meeting.  Don't want to wait people's time.22:08
*** ayoung has quit IRC22:08
med_#info annegentle is closing Essex docs in a week22:08
danwenti'll do a better job of making sure the right people actually show up next week.22:08
rkukuraAre we going to keep meeting weekly? At the same time?22:08
danwentmed_:  good to know.  med_  and rkukura  are both working to see how we can better document ubuntu + fedora setup in the Quantum admin guide.22:09
mnewbyI have a question regarding agents22:09
danwentrkukura: plan was to use it as a scrum.  but if the right people don't show up, perhaps we shouldn't bother :)22:09
danwentmnewby:  go ahead22:09
mnewbyIn reviewing the agent code I noticed that at least the linuxbridge and ovs plugins need direct access to the quantum db22:10
mnewbyIs this going to remain for folsom?  I can see the potential for major problems with this design.22:10
danwentyes, same model as nova-compute, I believe22:10
mnewbyyikes22:10
mnewbyOk.22:10
rkukuraAre you more concerned with the plugins or their agents?22:11
mnewbyThe agents.22:11
*** markvoelker has joined #openstack-meeting22:11
mnewbyI'm going to research possible alternatives with an eye towards using a more distributed approach.22:11
rkukuraI'm signed up to look at using amqp.22:11
mnewbyI'll discuss on the ml and capture my ideas in a bp.22:11
danwentother model I guess is to pass everything via RPC, I guess that would save on DB conections.22:11
danwentor shifting to a more distributed data store22:12
*** littleidea has quit IRC22:12
mnewbyThe issue with rpc is whether we use persistent queues or acknowledgement.22:12
mnewbyBut we can discuss going foward.22:12
danwentright now I'm much more worried about getting something functional, and for functional, the "centralized db" model works pretty well.22:12
mnewbyI'm not going to get in the way of that, but 'functional' isn't 'scalable'.22:13
danwentthe good news is that the plugin model can handle this pretty well22:13
danwentI'd focus on a plugin that we're targeting to be the "super-stable, nova-parity" option for Folsom.22:13
danwentif we get that locked up quickly, we can easily start working on another plugin that uses more exotic datastores22:14
danwentand will scale better.22:14
cdubmnewby: did you have a specific issue w/ something like amqp?22:14
salv-orlandomnewby: what you're proposing falls in the category of "give some love to the open source plugins".22:14
mnewbyAgreed.  And better plugin->agent communication model is developed won't hinder other efforts.22:14
mnewbycdub: amqp is certainly an option, but nova has had scalability issues with the rabbitmq implementation.22:14
*** patelna has joined #openstack-meeting22:14
mnewbyzeromq may be a better fit.22:15
mnewbyOr just using a better centralized store.22:15
salv-orlandoI'd love that, but agree with Dan that we want to have a basic thing working and super-stable. Is a fork from ovsplugin something that can be considere?22:15
danwentI think we can pretty easily get rid of the polling in existing plugins using an RPC for notifications22:15
cdubyes, i'd expect so22:15
med_I thought that the rabbitmq scalability issue was somewhat debunked at ODS-F (but not really a Quantum issue)22:15
mnewbysalv-orlando: I'm not suggesting replacement from what, at present, works.22:15
mnewbyJust that I'd like to consider alternative.22:16
mnewbys22:16
danwentsalv-orlando: I think if we're good about designing plugin code as libraries, it should be easy to have a stable one, then a more aggressive one that shares much of the same code.22:16
salv-orlandomnewby: agreed22:16
salv-orlandodanwent: agree with you too :)22:16
rkukuraWhy keep the non-scalable one around if we solve the scalability issue without decreasing stability?22:16
mnewbyAnyway, just wanted to raise the issue.22:16
mnewbyrkukura: nice to have options ;)22:16
danwentmnewby: sure.  but what really keeps me up at night is making sure we have a rock solid open source plugin, so I'm nervous about dividing our focus until we achieve that.22:16
danwentmnewby: definitely good to raise.22:17
cdubdanwent: actually database access is part of stabliilty issue w/ current agents ;)22:17
rkukuraWe have stability issues right now regarding DB connection management.22:17
cdubdanwent: so 2 birds w/ one rabbit (or qpid, or..)22:17
mnewbyYes, that's my concern.  Stability won't last with centralized db once scaling is involved.22:17
somikrkukura: I think the no-scalable one is 'as scalable' as nova, so we can do better, but this works and we can make it scale better after we are done with functionality22:17
danwentrkukura: my main comment is a design that is simple to understand, build, debug…. regardless of technology22:17
mnewbyYes, that is definitely the goal.22:18
rkukuraagreed22:18
danwentmy experience with nova is that adding a bunch of RPC calls does not help :)22:18
mnewbySimple/maintainable is usually easier to scale, too.22:18
mnewbydanwent: at least not using rabbitmq22:18
mnewbyTime to do some reading on distributed systems ;-)22:18
mnewbyAnyway, in the same vein, I'm going to file a bug on testing the agents.22:18
danwentOk, so I think we're clear on goals.  I don't particularly care about the technology, so much as making sure we get something stable and working quickly.22:19
danwentmnewby: great.  good testing infrastructure will help in both cases.22:19
danwentok, where were we? :)22:19
mnewbyOne more thing: reviewing22:19
danwentmnewby: that was my next topic :)22:20
mnewbyNice :)22:20
danwentmnewby is doing a kick-ass job fixing bug and improving the code base.22:20
danwentwe at the very least need to support him by reviewing code :)22:20
danwenthttps://review.openstack.org/#/q/status:open+project:openstack/quantum,n,z22:20
*** dolphm has quit IRC22:20
danwenthttps://review.openstack.org/#/q/status:open+project:openstack/python-quantumclient,n,z22:20
danwentprobably most urgent is patch to get rid of quantum.common, is that true mnewby ?22:20
danwentserver-side must go in first, then client side22:21
danwentthen probably good to do the HACKING patches to avoid being in rebase hell.22:21
mnewbyYes22:21
danwentor should HACKING be first?22:21
mnewbyquantum.common first.  Then hacking.22:21
danwentk22:22
mnewbyThey are dependent changes, in any case.22:22
danwentI've already reviewed the quantum.common stuff…. I think we're in good shape there.22:22
danwentalso garyk has some fixes for the OVS plugin… would like to get those merged quickly.22:22
danwentany other urgent reviews?22:22
danwentOk, and any other topics to discuss?22:23
rkukuragary has some DB connection fixes as well22:23
mnewbyI've noticed a drop-off in the number of participating core reviews post-summit.  I'm hoping things will swing back to pre-summit levels sooner.22:23
danwentrkukura: yup, just mentioned those :)22:23
rkukuralinuxbridge and openvswitch22:23
mnewbyIs there manual testing being done of those changes?22:24
mnewbyI reviewed the code and saw at least one bug.22:24
danwentmnewby: we need better agent test coverage on both sides.22:24
cdubmnewby: i believe gary's manually testing, yes22:24
mnewbycdub: I'll ask him about that then.  He clearly wasn't testing the failure case or he would have had a failing linuxbridge agent.22:25
cdubmnewby: ok, yeah, definitely note it in review22:25
danwentthere' s a lot of code from the OVS agent that has been copied to other agents as well… I think we really need to get an agent.common directory going, so we don't have similar patches against all agents when we want to change something.22:25
mnewbyI was wondering that.22:26
rkukuraWhat about config, logging, etc., across agents and the server?22:26
mnewbyHow are the agents deployed at present?22:26
mnewbyIs all of quantum installed with them?22:26
mnewbyAh, logging.22:26
mnewbyI'm displaying my ignorance, but do agents log to the server?22:27
danwentmnewby: no, which is part of the issue.  we don't want all quantum dependences, so really we need to have something like a quantum-agent-common package22:27
mnewbyOr would logs have to be collected?22:27
rkukuraThat's distro-specific, but fedora includes the agents in the plugin packages22:27
mnewbydanwent: understood.22:27
salv-orlandodanwent: I kind of agree with Dan that refactoring is a sort of priority22:27
salv-orlandomnewby: no, if they do, the log is local22:27
danwentmnewby: agents log locally (or not at all...)22:27
mnewbydanwent: It would be really good to extract the common stuff out of at least ovs and linuxbridge.22:27
danwent#action danwent create common agent framework22:28
mnewbydanwent: So the agent has to update the db for quantum to know what's going on?22:28
rkukuraI really think the agents and server should also handle DB connections, config, and logging consistently - so its not just the agents22:28
danwentmnewby: its actually even beyond that… even ryu borrows code from OVS significantly.22:28
mnewbydanwent: Did you want to do that, or are you just going to file a bug?22:28
danwentrkukura: yes… sharing should happen at both the server + agent level.22:29
mnewbyrkukura: agreed.  And that stuff should be shared.22:29
danwentmnewby: I was going to do it, but if you want to, I'm fine with that :P22:29
mnewby(between all plugins).22:29
mnewbydanwent: It's yours if you want it.  :)22:29
danwentmnewby: you're doing lots of stuff already.  I'll take this one22:29
rkukuradanwent: We need to pay attention to openstack-common for a lot of that22:30
mnewbyrkukura: Is there much of anything in common yet?22:30
*** littleidea has joined #openstack-meeting22:30
danwentrkukura: i've been talking with those folks.  Their next priority is wsgi stuff, which will help on the server, but doesn't really apply to plugin code.22:30
danwentmnewby: not much yet… though some of the config stuff may be applicable.22:30
rkukuraThe config stuff is there (almost) I think22:31
*** vladimir3p has quit IRC22:31
danwentok, now is a good time to do a lot fo this clean-up, so let's push forward with it.22:31
danwentok, any other topics to discuss?22:32
danwentok, great.  thanks folks.  don't forget to keep an eye on reviews!22:32
salv-orlandobye!22:32
mnewbybye!22:33
danwenttalk to you next week, at which point we should have a lot of the key bps together.22:33
markvoelker'night!22:33
cdubcya22:33
med_ #endmeeting22:33
danwentlater!22:33
danwentno soup for you med_ !22:33
* med_ can't actually end it22:33
danwent#endmeeting22:33
*** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)"22:33
openstackMeeting ended Tue Apr 24 22:33:24 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)22:33
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-04-24-22.03.html22:33
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-04-24-22.03.txt22:33
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-04-24-22.03.log.html22:33
danwentmed_:  :)22:33
*** AlanClark has quit IRC22:34
*** markvoelker has quit IRC22:34
*** somik has quit IRC22:35
*** zaitcev has left #openstack-meeting22:35
*** mattray has quit IRC22:40
*** s0mik has joined #openstack-meeting22:43
*** littleidea has quit IRC22:45
*** GheRivero has quit IRC22:53
*** Dug has quit IRC22:55
*** dtroyer is now known as dtroyer_zzz22:55
*** User327 has quit IRC22:55
*** Yak-n-Yeti has joined #openstack-meeting22:56
*** blamar has quit IRC22:59
*** mdomsch has joined #openstack-meeting23:00
*** rafaduran has quit IRC23:04
*** heckj has quit IRC23:06
*** blamar has joined #openstack-meeting23:17
*** blamar has quit IRC23:17
*** blamar has joined #openstack-meeting23:17
*** mdomsch has quit IRC23:19
*** ryanpetr_ has joined #openstack-meeting23:25
*** ryanpetrello has quit IRC23:28
*** xsad has joined #openstack-meeting23:36
*** anderstj has quit IRC23:39
*** lloydde has quit IRC23:43
*** gyee has quit IRC23:48
*** patelna has quit IRC23:51
*** dhellmann has joined #openstack-meeting23:52
*** jgriffith has quit IRC23:53
*** salv-orlando has quit IRC23:57

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!