Tuesday, 2011-08-30

*** dendrobates is now known as dendro-afk00:23
*** novas0x2a|laptop has joined #openstack-meeting00:38
*** vladimir3p has quit IRC00:48
*** jakedahn has quit IRC00:51
*** HowardRoark has joined #openstack-meeting01:02
*** HowardRoark has joined #openstack-meeting01:03
*** ohnoimdead has quit IRC01:07
*** novas0x2a|laptop has quit IRC01:08
*** tsuzuki_ has quit IRC01:34
*** tsuzuki_ has joined #openstack-meeting01:34
*** msinhore has quit IRC01:39
*** msinhore has joined #openstack-meeting01:52
*** dendro-afk is now known as dendrobates01:56
*** adjohn has quit IRC02:03
*** tsuzuki_ has quit IRC03:02
*** dendrobates is now known as dendro-afk03:07
*** tsuzuki_ has joined #openstack-meeting03:10
*** martine has joined #openstack-meeting03:31
*** msinhore has quit IRC03:36
*** joearnold has joined #openstack-meeting03:54
*** adjohn has joined #openstack-meeting04:02
*** martine has quit IRC04:40
*** martine_ has quit IRC04:45
*** deshantm is now known as deshantm_away05:06
*** joearnold has quit IRC05:27
*** joearnold has joined #openstack-meeting05:27
*** HowardRo_ has joined #openstack-meeting05:39
*** HowardRo_ has joined #openstack-meeting05:39
*** HowardRoark has quit IRC05:41
*** HowardRoark has joined #openstack-meeting05:57
*** HowardRoark has quit IRC05:59
*** HowardRo_ has quit IRC05:59
*** joearnold has quit IRC06:29
*** adjohn has quit IRC07:54
*** darraghb has joined #openstack-meeting08:48
*** markvoelker has joined #openstack-meeting11:57
*** jaypipes has joined #openstack-meeting12:02
*** jaypipes has quit IRC12:11
*** joesavak has joined #openstack-meeting12:20
*** jaypipes has joined #openstack-meeting12:22
*** jsavak has joined #openstack-meeting12:22
*** joesavak has quit IRC12:26
*** edconzel has joined #openstack-meeting12:27
*** markvoelker has quit IRC12:44
*** med_out is now known as medberry12:53
*** jaypipes has quit IRC12:56
*** martine has joined #openstack-meeting13:00
*** jsavak has quit IRC13:02
*** mattray has joined #openstack-meeting13:09
*** tsuzuki_ has quit IRC13:26
*** martine has quit IRC13:28
*** mdomsch has joined #openstack-meeting13:50
*** msinhore has joined #openstack-meeting14:07
*** joesavak has joined #openstack-meeting14:21
*** vladimir3p has joined #openstack-meeting14:33
*** rnirmal has joined #openstack-meeting14:53
*** dragondm has joined #openstack-meeting14:53
*** jsavak has joined #openstack-meeting14:58
*** vladimir3p has quit IRC15:00
*** joesavak has quit IRC15:00
*** markvoelker has joined #openstack-meeting15:01
*** martine has joined #openstack-meeting15:04
*** joesavak has joined #openstack-meeting15:18
*** martine_ has joined #openstack-meeting15:19
*** martine has quit IRC15:20
*** jsavak has quit IRC15:21
*** edconzel_ has joined #openstack-meeting15:35
*** edconzel has quit IRC15:35
*** edconzel_ is now known as edconzel15:35
*** jsavak has joined #openstack-meeting15:57
*** joesavak has quit IRC15:57
*** adjohn has joined #openstack-meeting15:57
*** edconzel has quit IRC16:01
*** edconzel has joined #openstack-meeting16:01
*** troytoman-away is now known as troytoman16:12
*** HowardRoark has joined #openstack-meeting16:14
*** heckj has joined #openstack-meeting16:37
*** novas0x2a|laptop has joined #openstack-meeting16:49
*** dprince has joined #openstack-meeting16:53
*** tsuzuki_ has joined #openstack-meeting17:07
*** mdomsch has quit IRC17:18
*** dragondm has quit IRC17:19
*** ohnoimdead has joined #openstack-meeting17:24
*** tsuzuki_ has quit IRC17:35
*** darraghb has quit IRC17:47
*** jakedahn has joined #openstack-meeting17:47
*** bengrue has joined #openstack-meeting17:48
*** novas0x2a|laptop has quit IRC17:53
*** novas0x2a|laptop has joined #openstack-meeting17:54
*** jsavak has quit IRC18:01
*** jsavak has joined #openstack-meeting18:02
*** vladimir3p has joined #openstack-meeting18:03
*** joesavak has joined #openstack-meeting18:06
*** jsavak has quit IRC18:08
*** adjohn has quit IRC18:52
*** johnpur has joined #openstack-meeting18:52
*** adjohn has joined #openstack-meeting18:57
*** jsavak has joined #openstack-meeting19:00
*** joesavak has quit IRC19:03
*** _adjohn has joined #openstack-meeting19:04
*** adjohn has quit IRC19:05
*** _adjohn is now known as adjohn19:05
*** creiht has joined #openstack-meeting19:11
*** jbryce has joined #openstack-meeting19:16
*** jorgew has joined #openstack-meeting19:29
*** mdomsch has joined #openstack-meeting19:29
*** dragondm has joined #openstack-meeting19:38
*** primeministerp1 has joined #openstack-meeting19:43
_0x44Wasn't there supposed to be a ci meeting at 12?19:43
heckjlurking, but I guess not...19:46
*** jmckenty has joined #openstack-meeting19:52
*** zns has joined #openstack-meeting19:58
ttx_0x44: monty is off20:00
jbryceroll call?20:00
jbryceis that your cockney accent?20:01
vishypretty sure jesse is out20:02
jbrycehe raised his hand20:03
johnpurhey joshua20:03
jmckentyah, sorry20:03
znsziad here20:03
jbryceyeah jesse is out and i think jay is going to be out as well20:03
vishyand i think ewan is on a plane20:03
jmckentynotmyname: you here?20:03
jmckentyas in, paying attention? :p20:03
openstackMeeting started Tue Aug 30 20:03:32 2011 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.20:03
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.20:03
ttxsoren won't make it20:03
jbrycedoesn't look like we have a quorum for today20:03
jmckentymtaylor is here, too20:03
jmckentyI think we have quorum20:03
vishyhow many do we need for a quorum? 6?20:04
jmckentyjbryce vishy jmckenty mtaylor johnpur notmyname ttx20:04
ttxmtaylor is not ppb20:04
jmckentyah, right20:04
jmckentyand dendro-afk is afk20:04
vishyok discussion and maybe one more will show up?20:05
ttxI don't mind calling this one off :)20:05
jmckentydevcamcar is ppb after diablo, correct?20:05
jmckentyassuming he's still ptl of dashboard20:05
vishydevcamcar and zns both20:05
jbrycecan we do an abbreviated non-binding discussion on the api issue then?20:05
jbrycesay 10 minutes and then we can have the rest of the hour back20:06
vishysounds good20:06
jmckentysounds good - can you summarize the state of debate?20:06
vishyjorge put together a proposal20:06
jbrycesure, lots of debate back and forth on the mailing list over the course of 10 days or so20:06
vishywhich i think outlines things well20:06
jmckentyI've read the thread as it unfolded, and have been impacted by it in various ways20:06
jmckentybut I don't see the connection between the proposal and the debate20:06
vishythe debate isn't going anywhere because there is no ownership20:06
ttxThe proposal is a way to codify the "API belongs to architects" into law.20:07
vishyso it is just a bunch of opinions on the best way to do things20:07
jbrycei think the 2 main concepts of the proposal are 1) push primary ownership of the api's into each project 2) establish some standards across all projects20:07
jmckentyIf I can summarize, the debate has been "Is API design up front slowing down OpenStack and creating problems"20:07
ttxit doesn't settle the discussion.20:07
jorgewttx: No that's not the proposal at all20:07
jbrycettx: i didn't read the proposal that way20:07
jmckentyI did20:07
jmckentyI'm with ttx on this20:07
notmynamee too20:07
vishyttx: I disagree.  The proposal says that the api belongs to the projects, aside that they must follow common guidelines20:07
jmckentyIt proposes creating a new PTL20:07
jmckentyyes, it does20:08
jorgewRight.  The PTL owns the API20:08
vishyttx: and go through an approval by the ppb to ensure that the guidelines are met20:08
ttxvishy: the "PTL" of the guidelines project owns the PAI20:08
jorgewThe PPB owns the guidelines20:08
ttxvishy: you misread, I think20:08
jbrycettx: PTL in proposal refers to each project's individual PTL20:08
jmckentyyeah, the problem has been architects inventing APIs at all20:08
jmckentyjbryce: no it doesnt20:08
notmyname"The PPB will nominate a PTL for the api-guidelines project"20:08
jbryceapi-guidelines being the broad standards20:09
ttxvishy: it creates a new project with a new "appointed PTL" that owns the spec, suject to PPB dismissal20:09
jbrycelike RESTful20:09
znsttx: the proposal helps the debate by stating that the discussion should be about forward-looking API specs. The current point of conlfict is that developers and architects are both working on a current spec.20:09
vishy"The definition of a specific API is controlled by the PTL of its project."20:09
jbrycethe api-guidelines PTL does not own the Compute API or Keystone API20:09
jorgewThe PPB owns guidelines and goals that are inter-projcet requirements20:09
jmckentythe metadebate is whether OpenStack should be involved in forward-looking API specs at all20:09
jmckentysince it was historically an anti-goal20:09
jorgewthe PTL of the projcet ows that API20:09
ttxjorgew: I think you're not after a "PTL" here, but after a delegation of responsability, much like "release manager"20:10
jbrycettx: i agree with that20:10
jorgewsorry for the confusion, but end of the day the PTL of the project owns the API20:10
vishyI don't necessarily think that the api-guidelines needs a ptl per se20:10
ttxPTLs are not chosen by the PPB but by the devs of the project, and I don't want to bastardize the concept of core project20:10
ttx(just discussing how the proposal is presented, not the justification of it)20:11
vishyperhaps simplify it to the PPB can appoint someone to manage the guidelines20:11
jorgewYou know — we can let the PPB outline the api-guidelins project as it sees fit - with or without a PTL.20:11
vishyI agree that calling it a PTL is confusing20:11
jmckentyI'm still not sold on the need for such a project20:11
jorgewThe reason that's there is that we need someone to settle issures on guidelines20:11
johnpurapi working group?20:11
ttxjmckenty: I agree there are two issues: do we want to keep API design separate from development -- and then how you codify that (PTL, delegate...)20:12
jmckentymore reasonable - except to my previous point that we specifically eschewed such an activity before20:12
vishyjmckenty: consistency among openstack apis is a concern20:12
jmckentyIf there are sets of OpenStack members who would like to involve themselves in forward-looking API discussions,20:12
notmynamehow is this not a nova (or other project) specific thing? when you are talking about the "openstack api" you are referring to nova20:12
jorgewBut at the end of the day — that person is only responsable for api related stuff not the specifics of any particular API — that belongs to the PTL of the project.20:13
jmckentythere are a dozen working groups they can go join20:13
vishyso we need projects to own APIs20:13
johnpurthere is a need for some consistency in the API's presented by OpenStack projects20:13
vishyand there to be a set of guidelines for the projects to follow20:13
ttxjorgew: oh, ok20:13
johnpurin areas like extension mechanisms, etc.20:13
vishyguidelines should be as light as possible IMO.20:13
jbrycevishy: +120:13
ttxjorgew: so that would be a delegate, nominated of the PPB to care about API consistency.20:14
vishyttx: +120:14
jorgewttx:  yes20:14
ttxjorgew: "API guidelines master" or something20:14
ttxjorgew: we, delegates of the PPB, like nice and round titles20:14
jorgewRight — sorry shouldn't have called it a PPL20:14
notmynamebut the nova and the swift APIs (for example) are already very different (fundamentally, not in how they refer to things)20:14
johnpurthe "API master" needs to be responsive to the community20:14
jmckentyand the ec2 APIs are as well20:14
jbrycewhich is one of the things that i think people would like to see improved upon20:15
ttxjorgew: I'd like to see it discussed on the list -- it sounds like a nice middle way between the two opposed views20:15
jorgewnotmyname: yes they are different because one is a data API and one is a control API we can have guidlines for bot20:15
jbrycethat was actually one of the points george reese made20:15
jmckentywhich, if we're talking about being responsive to the community, the EC2 APIs remain high on the list20:15
johnpurttx: +120:15
vishynotmyname: i think the guidelines are more like: use REST, if you provide an extension mechanism, use the same method as the other projects instead of inventing a new one. Responses should be json and xml (not somre random junk) http codes should be used according to standard definitions.)20:15
jmckentyvishy: +120:16
jmckentyguidelines are done.20:16
johnpurvishy: agree20:16
jorgewvishy +120:16
notmynamevishy: which sounds good20:16
ttxjorgew: when you say "the PTL has the final say in determining consensus" you mean which PTL ?20:16
jmckentyvishy: if we add a reference to WHICH definition of REST we're using, we're probably all the way done.20:16
vishyjmckenty: :)20:16
*** troytoman is now known as troytoman-away20:16
jbryceso can i try to summarize again the 2 high level goals?20:17
jorgewttx: I mean the API master when on issues related to guidlien or roals20:17
jmckentyso is any of this a discussion of how and when we modify the API spec?20:17
jmckentyor is that up to the PTLs' discretion20:17
znsjmckenty: I think that is important. The way it is being done today is painful, trying to hit a moving target.20:18
jbryce1) create some mechanism to define a standard way of defining APIs 2) push the actual development and definition of any project's API into the project (under that project's PTL)20:18
vishyjmckenty: yes it is decided by the project, and as long as the spec goes through a PPB approval process to make sure it is following guidelines20:18
jorgewjmckentry:  The PTL decides how the spec is modified — the only requirement is that  the spec is published is such a way that it can be reviewed20:18
jmckentydear god20:18
ttxjbryce: I think the proposal needs to be reworded so that the "API guidelines master" is a delegation of the PPB -- and then discussed on the list, then vote next week20:18
jmckentywe're sunk.20:18
vishyjmckenty: why?20:18
johnpuri don't think the ppb is in the business of api review20:18
vishyjohnpur: I assume we would delegate it20:19
ttxjohnpur: that's why we delegate it :)20:19
jmckentyyou realize this was the topic of my keynote at the inaugural openstack design summit?20:19
jorgewjohnpur:  review only in issures of guidelines, inter-project consistency, goals20:19
jmckentywe have reached the pinnacle of what we were trying to avoid20:19
vishysomeone has to own consistency, jmckenty.  Who else will do it?20:19
jmckentyA devilish consistency is the hobgoblin of little minds20:20
jbrycewe're not talking devilish consitency20:20
jmckentyconsistency has never been achieved by specs up front20:20
jmckentyit's been achieved by dialog between interested parties20:20
jbrycewe just don't want ziad to only publish a corba interface to keystone. = )20:20
jmckentyand rapid iteration20:20
znsjbryce: you promised not to tell!20:21
notmynamejbryce: so go talk to him and say "don't do that"20:21
jmckentynotmyname: EXACTLY20:21
notmynameinterested parties talk and then very interested parties code20:21
jmckentyinstead, we're going to have a MECHANISM to DEFINE a STANDARD for DEFINING an API (which is itself a published STANDARD)20:21
*** annegentle has joined #openstack-meeting20:21
jmckentybefore we've even written any code to test whether it's a good IDEA20:21
jbryceyou don't think there's any benefit to documenting the outcome of the dialogs, the iteration, the code from interested parties that have already occurred?20:21
jbryceif we can at least agree on the basic goals, then we can work from there to determine things like if it's an API master, if it requires PPB review, etc20:22
jmckentysure - that's what functional tests are for :)20:22
vishyjmckenty: we don't have to use specs up front20:22
jbrycepersonally i'd rather have the guidelines be light, but i think having them available is helpful20:22
sandywalshso, if we make another API that doesn't belong to Openstack API (tm), does it need to follow those guidelines?20:22
jmckentywhat's wrong with HACKING.txt?20:22
jmckentysandywalsh: it's OpenStack(tm) API(tm)20:23
jorgewvishy is right there is no requirement that new featurs need to be speced up front20:23
johnpuri think having an overall api design schema is a good thing... and that Vish defined it earlier20:23
vishysandywalsh: nope20:23
notmynameif we traded "api guidelines" for "coding guidelines" would this change the argument? the PPB should be involved with either, IMO20:23
jbrycewe have heard from many many people that the current state of the api is suboptimal (for compute especially)20:23
vishynotmyname: who is?20:23
sandywalshvishy, well then, I think the architects can have a field day and the programmers can get something working20:23
jmckentyjbryce: the reason it is suboptimal is because the separation of API spec and developers has made it hard to improve20:24
jmckentyjbryce: IMO20:24
_0x44vishy: -core, IMO20:24
vishynotmyname: i read it that way, but who is responsible20:24
jbrycejmckenty: i'm not disagreeing and a big part of the proposal is to remove that separation20:24
jorgewnotmyname: Coding guidlines and API guidlins are different things — API guidlines affect users20:24
notmynamevishy: the PTL and core devs. responsible adults20:24
vishy_0x44: so we make an openstack-core group?20:24
vishyhow do the 6 projects decide guidelines then?20:25
jmckentyah, we're back to resolving openstack-common20:25
vishy* 5 + 1 inc20:25
_0x44vishy: I don't think that'd work, especially if the internal coding guidelines for each project are different.20:25
* creiht hides20:25
jmckentyis that a stall?20:26
jmckentyor a net-partition20:26
vishynotmyname: do the ptl's just get together and define the api-guidelines between them?20:26
jmckentynotionally that IS what the PPB is for20:26
jmckentyit's PTLs plus a few other reps20:26
vishyjmckenty: yes, that is my thought20:26
johnpurit is very difficult for consumers of openstack to make serious progress with some of the churn in the API's (pointing out projects like Keystone, where there is rapid iterative changes). We should strive to be more developer friendly, if possible.20:27
notmynamevishy: so far it's been a gentleman's agreement to not suck20:27
vishyI know it is hard to think of things this way, but when we delegate something to the ppb, we are delegating it to ourselves20:27
jorgewvishy: The PTLs have almost absoute power when it comes to the API…the guidelines in my opinion belong to the PPB.20:27
jmckentyjohnpur: they're milestone releases, the consumers will survive20:27
sandywalshcreiht +1, api-common20:27
creihtoh noes, what have I done?20:28
notmynamejohnpur: let's focus on getting production-ready stuff20:28
johnpurjmckenty: iff you don't have folks working to integrate20:28
vishynotmyname: it has been for you perhaps20:28
sandywalshjohnpur, is the concern 3rd parties writing against a moving target?20:28
vishynotmyname: for us, so far its been, wait for the api spec to be finalized and then implement it without changes20:28
vishynotmyname: not sucking has not been a concern :p20:29
jbrycehere's a new question20:29
johnpursandywalsh: yes, and folks like service providers or consultants that rae standing up clouds based on openstack currently20:29
notmynamevishy: perhaps I'm confused as to why you (the nova devs) aren't the ones defining the API for the project you are making20:29
vishynotmyname: that is what we are trying to fix with this proposal20:30
sandywalshPerhaps we just need more versions ... and stop dumping the kitchen sink into 1.1?20:30
jbrycedo people generally feel that the compute api for instance should be more directly in synch with the code and more directly managed by the project's development team?20:30
pvosandywalsh: ++20:30
notmynameproposal: nova API == whatever vishy says it is because he's the one respnsible for the code ;-)20:30
pvojbryce: yes, I think that is the sentiment.20:30
sandywalshBig Up Front Design isn't the answer, but freeze faster and iterate20:30
jbrycesandywalsh: this proposal is much less up front design than the current state20:31
jorgewsandywalsh: that's another concept in the proposal eventually you freeze and move to another version if you wish20:31
johnpursandywalsh: +120:31
znsFreeze 1.1 (or whatever version you are on) and start on the next version. If anyone is using the latest version they're accepting a level of change.20:31
vishynotmyname: I think we agree on that part20:31
pvobut won't you 'freeze' on the releases?20:31
pvowhat is in the api, is the api?20:31
sandywalshzns +120:32
*** edconzel_ has joined #openstack-meeting20:32
vishynotmyname: you think general guidelines for consistency are unimportant, though?20:32
_0x44sandywalsh: We shouldn't freeze 1.1 until it's reached mostly feature parity with the AWS API.20:32
sandywalsh_0x44, why?20:32
pvo_0x44: disagree20:32
*** joearnold has joined #openstack-meeting20:32
*** devcamcar_ has joined #openstack-meeting20:32
vishybecause if we don't have consistency guidelines, I might just scrub the current api and use Direct API!20:32
jorgew_0x44: Let's not do that please.20:32
_0x44sandywalsh: See devcamcar_'s email.20:32
johnpurthere should be a target goal (per release) for the API per service... and that the objectives for the service API are discussed and "agreed" to at the previous design summit20:33
pvovishy: I was waiting for that one.20:33
zns_0x44: that's what is causing the problem now. We need to freeze if we want stability.20:33
jmckentypvo: WHY are we freezing APIs separate from releases?20:33
vishypvo: I'm kidding, of course20:33
jmckentyI still don't get this "FREEZE THE API" discussion20:33
jorgewzns: +1, and the PTL should probably decide where that stable point is.20:33
pvojmckenty: I think at release, that is the api.20:33
_0x44vishy: +1, that's what we should have done to begin with.20:33
*** edconzel has quit IRC20:33
*** edconzel_ is now known as edconzel20:33
jmckentypvo: +120:33
pvoit doesn't matter if its 'frozen' or whatnot.20:33
notmynamevishy: it all depends on the implementation, I guess. but mostly I think that each project should define their own api as they develop the project. (but I suppose that gets to older, settled arguments)20:34
vishynotmyname, jmckenty, this is why we need to define guidelines20:34
sandywalshjmckenty, give the integrators/partners something to work against20:34
* _0x44 pipes down since this is a PPB meeting.20:34
sandywalshjmckenty, albeit incomplete20:34
vishynotmyname: +1 to that.20:34
jmckentysandywalsh: the integrators and partners have no business trying to build against an API in between releases20:34
jmckentythe faster we iterate, the faster we'll have an API the partners can live with20:34
sandywalshjmckenty, they do, they just can't bitch when things change20:35
johnpurjmckenty: you guys are working against cactus?20:35
vishyif the PPB owns guidelines, then they can say "Thou shalt freeze in prep for 6 month releases and support that api for a minimum of 12 months after release"20:35
vishyi think that is totally reasonable20:35
jbrycevishy: +120:35
vishythen the core teams can figure out how they will solve that requirement20:35
sandywalshfreeze on sprints, not on releases20:35
devcamcar_the main concern i was bringing up was why the OS api still doesn't support features present in nova such as sec groups, volumes, floating ips, etc a year into the life of openstack20:35
vishydevcamcar_: because we don't own it.20:35
jbrycewhich is again one of the 2 primary things the proposal addresses--push what the API can do under the PTL/project team20:36
sandywalshdevcamcar, because that's not our motivation (speaking for our team at least)20:36
*** dprince has quit IRC20:36
devcamcar_sandywalsh: what is your movitation?20:37
sandywalshdevcamcar, other functionality, not ec2 compatibility20:37
sandywalshdevcamcar, if that's someone's priority, someone should start coding it20:37
devcamcar_sandywalsh: on whose behalf are you speaking?20:37
jmckentySomeone would, if the API supported it :p20:38
sandywalshheh, no one ... just me :)20:38
_0x44sandywalsh: Floating IPs aren't a priority for Ozone?20:38
jbrycesandywalsh: you are pointing out the problem20:38
devcamcar_as far as the community goes, i think it benefits everyone if the features that already exist in the core are exposed in the api20:38
sandywalshI code what I'm told to code20:38
devcamcar_the code is there, why not have the api represent it?20:38
jbrycesandywalsh: there are plenty of people who would love to code new functionality that they would use into the openstack api but are only able to add new features into the ec2 api currently20:38
jmckentySo if I'm clear - if I need a change to the nova API to expose existing functionality, Vishy can approve that?20:38
jbrycejmckenty: correct20:39
vishyjbryce: Seems like we need a vote on ownership of the apis: 1) Owned by project (full stop) 2) Owned by project with oversight by PPB for consistency 3) Owned by PPB20:39
*** jaypipes has joined #openstack-meeting20:39
jmckenty2 +120:39
vishyjbryce: then we can discuss how 2 happens if it is actually voted on.20:39
jmckentybut "oversight" should be direct conversation whenever possible, IMO20:39
jorgewAt anytime, features can be exposed through the API — as core features which require PPL apporval — or as extensions which don't.20:40
jbrycevishy: this is what i've been trying to say the whole meeting. = )20:40
sandywalshdevcamcar, just a matter of prioritization ... it isn't the priority currently. Perhaps it should be?20:40
*** mandell has joined #openstack-meeting20:40
jbrycewe don't have enough ppb members to actually vote on it, but i think we've gotten some discussion out of the way. i think we should update the proposal to make sure it's clear exactly what is being proposed (which is actually vish's #2 option) and then circulate as ttx suggested20:41
vishyjbryce: 2 can end up being jorge's proposal, some modification of it, or some super simple 4 point guide with a quick stamp of approval from the ppb every 6 months20:41
devcamcar_sandywalsh: i agree with the rest of the folks, its really a question of who owns the API.  all of the features i mentioned above are now implemented in the OS API as extensions, but they are things that i don't think should be considered extensions20:41
jmckentyjaypipes is here now20:41
jmckentywe have quorum20:41
jbrycettx left20:41
jmckentyah, right20:41
jorgewMy proposal is 2!20:41
sandywalshdevcamcar, not sure the importance of it being an extension or not?20:41
* jaypipes needs to read through a log.20:42
jorgewThough I should probably be reworded somewhat.20:42
jbrycejorgew: i think we should tweak wording20:42
jmckentysandywalsh: extensions aren't guaranteed to be in any specific distro20:42
sandywalshah, gotcha20:42
*** jsavak has quit IRC20:42
jorgewjbryce: for sure20:42
jmckentythey essentially lead to standards proliferation20:42
notmynameso what is the "openstack API"? there isn't one. there is an API for nova. there is a separate API for swift. I'm not going to argue against the principle of consistency, but I'm still not clear on how this rises above and internal project issue20:42
* notmyname is being dense20:42
sandywalshdevcamcar, I see your point20:42
devcamcar_sandywalsh: its core functionality already within nova, i don't think the question is why shouldn't it be an extensions. the question is why -should- it be an extension20:43
jmckentyHey, as long as we're clear that project PTLs own APIs,20:43
jaypipeswould someone please summarize #1 and #2 for me. apologies for tardiness.20:43
devcamcar_notmyname: it's a fair point20:43
creihtI would also point out that jorgew's proposal is not #2, it is a possible implementation of #220:43
jmckentywe can sort out the API standards with bourbon and beatings20:43
jbrycenotmyname: there are multiple openstack api's notmyname20:43
sandywalshdevcamcar, because that's the sandbox we've been given to play in.20:43
johnpurdevcamcar: agree. we should be able to code a dashboard that runs solely against the OS API(s).20:43
sandywalshwe can't go outside our sandbox20:43
vishynotmyname: there is also keystone and soon quantum20:43
jmckentywe can now20:43
devcamcar_johnpur: we have20:43
jbrycean openstack api = an official api that an openstack project exposes that is not a compatibility layer with some existing api (a la ec2 or s3)20:44
notmynamevishy: indeed20:44
devcamcar_johnpur: new dashboard is OS API only20:44
devcamcar_maybe it makes more sense to call it OpenStack Compute API and OpenStack Storage API?20:44
vishycreiht: +120:44
notmynamedevcamcar_: +120:44
johnpurawesome, we are a bit behind, and need to use some ec2 calls to fill out all the functionality20:44
notmynamedevcamcar_: otherwise who knows what you're talking about :-)20:44
jbrycenotmyname: we are talking about all of them20:45
devcamcar_johnpur: mostly caught up now thanks to some folks implementing some API extensions (i still think those belong in the formal API though), but we are technologically caught up20:45
sandywalshextensions should only be mandatory when extending a frozen version20:45
jmckentyAnd frozen happens at release dates, yes?20:46
jmckentyor at milestones20:46
johnpurdevcamcar: looking forward to syncing to Diablo final and seeing how you use the API and integrate with Keystone20:46
sandywalshor sprint dates20:46
devcamcar_sandywalsh: i agree with that, makes perfect sense.  it's just not clear to me right now who is responsible for promoting extensions to core20:46
vishyjmckenty, sandywalsh, if we get the vote out of the way (next week), then we are free to decide how to do that20:46
jorgewsandywalsh: I can see where that rule can apply — but there be reasons other than this for extensions.20:46
sandywalshjorgew, such as?20:47
znsjmckenty: shouldn't PTL decide freeze dates? or Keystone, for example, we *should* be freezing earlier since it is a dependency for many other projects.20:47
notmynamejbryce: so the issue is that someone other than the devs are saying what the API for a project needs to be and then people are wondering why features are in the project and vice versa?20:47
jmckentysure, extensions are for features that aren't supported in all drivers20:47
jmckentysandywalsh: ==^20:47
devcamcar_jmckenty: +120:47
jmckentye.g., Xen-specific20:47
jbrycenotmyname: that is one of the issues, yes20:47
jorgewsandy: Take Atlas, some features work in Zeus but not Citrix  — those end up as extensions20:47
jmckentyjorgew: Atlas is OT in here, sorry20:48
jmckentyit's not proposed for incubation yet20:48
jorgewSame thing with keystone though20:48
*** Tushar has joined #openstack-meeting20:49
sandywalshjmckenty, my interpretation of extensions was "the API is blessed, all other stuff will be done as extensions"20:49
jmckentykeystone was accepted to core20:49
vishysandywalsh: also extensions for vendor specific deployments that aren't shipped in nova core20:49
sandywalshvishy, makes sense ... but then there's the distro issue, as mentioned above20:49
jbrycejmckenty: jorgew is saying it's the same situation with keystone where different auth backends have different features exposed through extensions20:49
vishysandywalsh: I would like 3rd parties to be able to supply extension/scheduler/driver and have their third party code run20:49
*** mandell has quit IRC20:49
jorgewsady: PTL decides what's an extension or not — end of story…however, should accunt for backend drivers user requirements, maturity etc20:50
vishysandywalsh: they can supply their own packages etc.20:50
jmckentyzns: +1 for PTL defining freeze dates, as long as it's a) published, and b) in sync with other projects whenever possible20:50
notmynameso what problems remain when the API definition is controlled by the PTL/devs?20:50
jmckentynotmyname: I think guidelines are still a good idea20:50
*** nati has joined #openstack-meeting20:50
vishynotmyname: guidelines for consistency20:50
*** mandell has joined #openstack-meeting20:50
sandywalshso, the argument of extensions being bad for distro reasons doesn't sound like such a big deal.20:50
jmckentye.g., so that it's clear what should be an extension20:50
znscorrect. That's why we ended up with more extension code than core. But that's fine. Finding commonality across Identity backends to put into core is a daunting task.20:50
johnpurdevilish consistency20:50
jmckentysandywalsh: the argument is just that essentially (logically) CORE features shouldn't be extensions20:51
notmynamejmckenty: vishy: guidelines are a noble goal. but the details of them are very important20:51
jorgewnotmyname:  And the forward looking draft that users can look at and comment on is important20:51
sandywalshjmckenty, but practically, no biggue20:51
jmckentyjorgew: I think that's a very different idea20:51
notmynamejorgew: no.20:51
jmckentydon't try and conflate that20:51
vishynotmyname: once again, we can make guidelines lightweight.  I am much less concerned with what the guidelines are then I am with defining who is responsible for setting them20:51
jorgewjmckenty:  Explain?20:52
jmckentyvishy: I'm the reverse20:52
sandywalshjorgew, should draft = extension, later to be rolled into core?20:52
jmckentyI'd much rather define them now than assign that responsibility to someone20:52
vishyjmckenty: we can't define them until we've decided who owns them20:52
jmckentysandywalsh and jorgew: no20:52
sandywalshjorgew, vs. document20:52
jmckentyPPB owns them20:52
jbrycethat's what vishy is talking about20:52
vishyjmckenty: good so we need to vote on that so it is documented20:53
annegentleI'd prefer that specs don't live on docs.openstack.org, the precedence set is that spec work is on the wiki.20:53
jaypipesjmckenty: the guidelines, right? not the APIs themselves? sorry if I'm late to the convo...20:53
jorgewsandywalsh:  Certainly there should be a process where you can move extensions to core…but some features I think shuld just make it to core…should be up the the PTL20:53
jmckentyjorgew: collecting info for roadmap of features (+/- user feedback to API style, etc) shouldn't be conflated with the rest of this discussion20:53
annegentlethat's my only feedback after reading jorgew's proposal20:53
jmckentyjaypipes: right, the guidelines only20:53
notmynameI feel like this is a presidential election where we are all choosing the majority political party and then later going to choose the actual president and VP20:53
jaypipesjbryce: is there a voteable item here?20:54
jmckentyCan I propose that everyone in the PPB hack on http://etherpad.openstack.org/HACKING-txt20:54
vishyoptions 1) project owns apis + guidelines 2) project owns apis, ppb owns guidelines 3) ppb owns apis and guidelines20:54
jbrycejaypipes: not today20:54
jmckentyand that we vote on that as guidelines next week?20:54
jmckentyjaypipes: we're short a quorum20:54
jaypipesjbryce: k, thx20:54
annegentleI'm also very concerned about the documentation of extensions and findability of them and design of the mechanism to submit extensions (to all OpenStack APIs not just compute also keystone). I have a merge prop from Keystone with extension docs with no well-designed way to tell API users about them.20:54
sandywalshas someone who's afraid of having to re-code something, I'm going to write everything as an extension and people can package it as they like. Isn't that the safest route?20:54
vishyif 2 wins we can define what the guidelines are20:54
jorgewjmckenty: How are useres supposed to have discussions about the API as a whole?20:54
annegentleJust want to be API user advocate.20:54
jmckentyjorgew: why would users ever have discussions about an API instead of about the system?20:55
jmckentyagain, it's a separate issue20:55
*** salv has joined #openstack-meeting20:55
jmckentyjbryce: how did we do about doing this in 10 minutes?20:56
creihtusers are not likely to have much input on anything until they can actually use it20:56
johnpurjmckenty: s/users/devs20:56
jmckentyright, but the devs will care as much about the feature as they do about the API of the feature, and we already have a process for all of that. It's called blueprints, and design summits.20:56
jbrycecreiht: not sure i agree with that. people like rightscale and enstratus have a lot of input based off pain they've experienced using other systems. that's good feedback to get.20:56
sandywalsh"if I write it as an extension, I can do no harm and I can do so without a review committee"20:56
jmckentysandywalsh: if it's an extension, it's dangerous for people to build anything that depends on it20:57
jorgewjmkckenty:  Sorry by users I mean operators, vendors… the API is important to them because it's a product for them20:57
jmckentysandywalsh: unless they control the deployment20:57
vishysandywalsh: it will still need review to get promoted into core20:57
sandywalshvishy, what if I don't care if it makes it into core? that's someone else's concern20:58
vishysandywalsh: and core means we're obligated to not break it20:58
*** jrouault has joined #openstack-meeting20:58
jmckentyjorgew: I agree we need a better way of gathering feedback from our user community - but I see no reason to conflate that discussion with API specs20:58
notmynamejbryce: so this isn't actually a meeting, right? because we have no quorum20:58
jorgewjmckenty: An extension can gain tracktion if it supports a feature users want.20:58
jbrycenotmyname: it's a non-binding meeting. = )20:58
sandywalshvishy, users can call POST /foo and know it's going to work20:58
jorgewjmckenty:  The API is where users, vendors, devs, etc meet — it's a common interface — it's a great place to engage the community etc20:59
jmckentyjorgew: that's architect's nonsense.20:59
vishysandywalsh: we have no contracts on extensions...20:59
notmynamejorgew: jmckenty: but you still haven't solve the issue of communicating the needs from users to devs.20:59
notmynameit comes down to people talking20:59
notmynameinterested parties20:59
vishysandywalsh: core just means we're committed to supporting it/not breaking it20:59
jbryceour time is up20:59
vishysandywalsh: so if a user doesn't care about that, they can surely build on top of extensions21:00
sandywalshvishy, gotcha ... so it's always best to code as an extension (which may not, actually, be a bad thing)21:00
creihtjust because you don't have a spec, doesn't mean outsiders don't have input... patches are always welcome :)21:00
vishysandywalsh: i think most people will21:00
jorgewjmckenty:  The process is working with other projects where users, vendors, and devs get together to sort out what will be on the API21:00
*** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/"21:00
openstackMeeting ended Tue Aug 30 21:00:30 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-20.03.html21:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-20.03.txt21:00
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-20.03.log.html21:00
sandywalshjbryce, haha21:00
znscreiht: not all users are developers.21:00
*** liemmn has joined #openstack-meeting21:00
vishyand here comes the other meeting21:00
*** danwent has joined #openstack-meeting21:00
openstackMeeting started Tue Aug 30 21:00:48 2011 UTC.  The chair is vishy. Information about MeetBot at http://wiki.debian.org/MeetBot.21:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.21:00
pvokeep going?21:00
*** pem has joined #openstack-meeting21:00
*** troytoman-away is now known as troytoman21:00
* vishy is channeling ttx21:01
pvoI'm not sure we reached any kind of consensus there21:01
vishywelcome to the release meeting21:01
jmckentythere's no consensus21:01
*** pem is now known as Guest2311821:01
carlpooh, exciting21:01
pvowhere then, does this get resolved?21:01
jbrycepvo, jmckenty: there was concensus on a couple of points. we can work on the rest later21:01
vishynotmyname, still here?21:01
*** rohitagarwalla has joined #openstack-meeting21:01
*** Vek has joined #openstack-meeting21:01
vishy#topic swift status21:02
*** openstack changes topic to "swift status"21:02
vishyany updates?21:02
pvojbryce: I'm not sure we want to drag this out longer.21:02
notmynamewe're finishing up our next release21:02
notmynameswift 1.4.3 will be the diablo release21:02
notmynameif you want something in it, make your merge proposal soon21:03
notmynameas in tonight, if possible21:03
notmynameI'll be in SF next week for a meetup. http://www.meetup.com/openstack/events/30605231/21:03
notmynameI think that's about it21:03
*** tsuzuki_ has joined #openstack-meeting21:03
vishyquestions for the swift PTL?21:04
*** hisaharu has joined #openstack-meeting21:04
vishyi'll take that as a no21:04
vishy#topic Glance Status21:04
*** openstack changes topic to "Glance Status"21:04
vishyjaypipes: ping21:04
jaypipesvishy: https://launchpad.net/glance/+milestone/diablo-rbp21:05
jaypipesvishy: we got D4 out the door with most of the targeted BPs and bugs...21:05
jaypipesvishy: currently have a few reviews going on, so if anyone has a few cycles, please go to https://review.openstack.org/#q,status:open+project:openstack/glance,n,z21:05
jaypipesvishy: other than that, working with a number of folks on QA/testing efforts, but no Glance-specific updates.21:06
vishygood deal21:07
vishyquestions for the glance ptl?21:07
*** jmckenty has quit IRC21:07
jaypipesglenc: shoot21:07
glencjaypipes, what is blocking the protected-properties BP?21:07
jaypipesglenc: the functional tests for keystone and client integration:21:08
glencgotcha - once that's done, we (or someone else) can begin work on that?21:08
jaypipesif folks can hop on to those reviews, that would unblock it.21:08
jaypipesglenc: yes sir!21:08
glencthank you21:08
vishyany more questions for jaypipes21:09
vishyok, moving on21:09
jaypipesglenc: also, if you could get me a highball glass, rocks, and scotch, that might help.21:09
vishy#topic Nova Status21:09
*** openstack changes topic to "Nova Status"21:09
* vishy switches hats21:09
glencLaphroaig or Lagavulin?21:09
jaypipesglenc: anything.21:10
vishyWe got a lot of features into D4, but we now have a huge buglist21:10
vishyand a lot of stuff under review21:10
vishyI've started targeting bugs to rbp21:10
*** msinhore has quit IRC21:11
vishyI know that all of the developers have plenty of internal team milestones, but we all need to band together to make diablo a success21:11
vishyThere are two critical bugs that need to be addressed.  I would really like a volunteer for each of these:21:11
uvirtbotLaunchpad bug 833552 in nova "No easy migration from old auth to keystone" [Critical,Triaged]21:11
uvirtbotLaunchpad bug 834189 in nova "XenServer and KVM handle local storage differently" [Critical,Triaged]21:12
pvovishy: re 833, difficulty? We need this too.21:12
vishythe second one will probably require some discussion, but I need someone to be in charge of making sure that it gets fixed in time for Diablo21:12
vishyas far as i'm concerned, we can't ship diablo without these solved21:12
*** tsuzuki_ has quit IRC21:12
pvo"not easy" from the bug, but how long would you guess if you were working it?21:12
vishypvo: I don't think it is hard, i think it is a script using auth manager that talks to keystone-manage21:13
*** ddutta has joined #openstack-meeting21:13
jaypipesvishy: could you elaborate why the inconsistency b/w the disk setup is a critical bug?21:13
vishythe trick is making sure it works and updating it since keystone is changing a lot21:13
jaypipesvishy: I'm just curious, is all...21:13
vishyjaypipes: I think it is a huge defect to have images work completely differently between our to main hypervisors21:14
vishy* two21:14
znsvishy: you'd need both Nova and Keystone installed on the same machine (keystone-manage doesn't use the REST API). Just fyi...21:14
vishyzns: good point, it should probably use the rest api21:14
znsvishy: keystone-manage shouldn't change that much...21:14
znsit's the API that is changing mostly.21:14
vishyzns: or you could just install nova to run the script on the keystone machine21:14
vishyzns: anyway we need something21:15
jaypipesvishy: k. is it a matter of the two hypervisors *expecting* to see disks set up differently, though? i.e. it is customary for the users of each hypervisor to see disks done the way they are? /me clueless on that one...21:15
zns.., but yes. Been getting much heat on changes. Understand the pain and working on improving.21:15
pvovishy: ant and I will take a stab at that.21:15
pvowe're blocked on it21:15
vishyjaypipes: no, it is arbitrary21:15
jaypipesvishy: k, good to know. thx21:15
vishypvo: nice21:15
vishypvo: the other one will need to include your team21:15
vishyI will start a mailing list discussion on the other one21:16
pvovishy: yes, will coordinate on it.21:16
pvovishy: sounds good21:16
znspvo: if you handle the nova side, we can commit to update the script if we change keystone...21:16
vishyand I'll assign the auth one to you21:16
pvozns: its a deal21:16
vishyzns great:21:16
pvovishy: just assigned to myself21:16
vishy#action vishy to email the list about the other critical bug and request help on reviews and bug fixing21:16
zns* wondering if he should have just stayed quiet *21:16
*** somik has joined #openstack-meeting21:16
vishyso all teams please test/install/report bugs/fix bugs/write tests21:17
vishylets not repeat the cactus release where we obsoleted it two weeks after the release21:17
vishyquestions for the nova ptl?21:17
hisaharuother bugs can not be merged in diablo-rdp?21:18
znspvo: cool. Lemme know when you have it (and where) and I'll follow the changes dolphm is doing.21:18
comstudvishy: i've come to agreement with zedas for this rpc stuff that implements kombu fixing 2 bugs, and keeps carrot as a depricated option.  opinion on it making diablo?21:18
vishyhisaharu: any bug can be fixed.21:18
hisaharuvishy: ok21:18
comstudvishy: (merge prop about to go back into 'needs review')21:18
vishycomstud: I like it for the bug fixing, can we merge it with carrot as the primary option, get some people testing kombu and decide whether we can default to kombu at release point?21:18
comstudvishy: sounds good21:19
vishyin other words I have no problem with it going in as a second option, but primary option sounds scary21:19
naticould you add bug 835919 for RBP? we are working21:19
uvirtbotLaunchpad bug 835919 in nova "Single default gateway should be offered to VM on multi-NICs environment." [Undecided,New] https://launchpad.net/bugs/83591921:19
comstudvishy: agree.  i did have to make a couple of minor mods to carrot to support the interfaces zedas needs, but... i think they are safe.21:19
comstudvishy: safer than kombu as primary for now..i agree21:20
vishynati: done21:20
*** mdomsch has quit IRC21:20
vishycomstud: cool get that merge in21:20
comstudvishy: will do21:20
comstudhaving a flags issue right now :-/21:20
vishyin general, I don't mind extensions going in as well as long as they don't tmess with underlying code too much21:20
comstudseems to not be obeying rpc_backend in all cases21:20
comstudand always loading default21:20
vishyany more questions?21:20
vishycomstud: hehe, uh oh :)21:20
comstudmight need to use LazyPluggable like db code21:21
vishycomstud ping me offline if you need another set of eyes.21:21
comstudwe'll see.  anyway.. :)  carry on21:21
comstudwill do21:21
vishy#topic Incubated Project Status21:21
*** openstack changes topic to "Incubated Project Status"21:21
vishyzns: updates?21:21
vishydevcamcar_: are you still here?21:22
znsAccepted to core (no longer incubated?)21:22
danwentquantum:  we dropped D4, are working on bug fixes for diablo-rbp21:22
devcamcar_vishy: yep yep21:22
danwentquantum: main focus moving forward will be stabilization and documentation :)21:22
annegentleyay docs!21:22
znsChanges were bigger than expected.21:22
znsLatest code (not reviewed, not yet passing tests, but there just to share with others): https://review.openstack.org/#change,34221:22
vishyzns: yeah I don't know if you get your own slot until diablo time, but I suppose it doesn't matter either way21:22
znsAPIs are published,m though:21:23
znsFull API: https://github.com/openstack/keystone/blob/d349b349c50e0683432f5ae843bd2dc83599c1b6/keystone/content/admin/identityadminguide.pdf?raw=true21:23
znsService API: https://github.com/openstack/keystone/blob/master/keystone/content/service/identitydevguide.pdf?raw=true21:23
znsThat review *should* be merged in by end of week (although we had said that last week).21:23
znsAny questions?21:23
vishyquestions for Keystone PTL?21:23
vishydevcamcar_: any updates on the project formerly known as dashboard?21:24
annegentleFor Keystone API, I got the Google search sorted so that when you search on docs.openstack.org you find the Keystone Dev Guide.21:24
devcamcar_vishy: we are locking everything down for a diablo release.  rcb folks are transitioning from openstackx to novaclient21:25
znsannegentle: thank you :-)21:25
devcamcar_quantum support has almost landed as well21:25
danwentwoohoo :)21:25
devcamcar_just waiting on a few units tests to get added to the branch and then we can merge it in21:25
markvoelkerdevcamcar_ I think they're in and waiting your review?21:25
vishydevcamcar_: any progress on packaging?21:26
devcamcar_markvoelker: odd, i didn't get notified, i will look again21:26
markvoelkerdevcamcar_: https://github.com/4P/openstack-dashboard/pull/9221:26
devcamcar_vishy: we are able to push to pypi so you can pip install django-openstack portion at least21:26
devcamcar_there is some debate around what it means to "package" a django site though21:26
vishydevcamcar_: I'd love to be able to apt-get bourbon21:27
vishydevcamcar_: have you settled on a code name?  Is it going to stay dashboard?21:27
devcamcar_vishy: the name will change, but we haven't settled yet21:28
devcamcar_going to be opening it up to the list for debate :)21:28
* medberry would recommend "meatloaf" as a name in tribute to dashboard21:28
devcamcar_medberry: nice :)21:29
vishyother questions for Dash ptl?21:29
glenc"sandwich" as in "apt-get sandwich" oops "sudo apt-get sandwich"21:29
vishyglenc: wouldn't me-a-sandwich be better for that?21:29
vishyapt-get me-a-sandwich21:30
vishyok danwent, anything else on quantum?21:30
danwentsorry for jumping in before, didn't realize this was so structured :)21:30
danwentonly other thing to add is that we continue to work on nova integration21:30
vishydanwent: ttx is much better at this than me :)21:30
danwentif any nova core devs are available to review the quantum-manager branch, it would be much appreciated21:31
danwentthat's about it21:31
vishydanwent: is that the last piece needed for diablo?21:31
pvodanwent: we're lining up to look at it today.21:31
pvowe've had a few guys out.21:32
danwentpvo: thanks!21:32
vishylooks like rick just gave you a review21:32
vishyas well :)21:32
pvojk0 and tr3buch3t have been ETO21:32
danwentshould have kept refreshing the page i guess :P21:32
devcamcar_quantum dashboard support just landed ;)21:33
danwentkeep refreshing :)21:33
markvoelkerdevcamcar_: w00t!21:33
vishydanwent: also, some networks are created in fixtures (see nova/tests/__init__.py which might explain why you were seeing that issue with associate_pool21:33
vishyquestions for quantum ptl?21:33
danwentvishy: thanks, yes, i tracked it down to some fixed IPs created with null networks in test_compute… should be working now21:33
vishyok then21:34
vishy#topic General Discussion21:34
*** openstack changes topic to "General Discussion"21:34
vishyanyone have anything?21:34
vishyok then21:35
*** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/"21:35
openstackMeeting ended Tue Aug 30 21:35:19 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:35
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-21.00.html21:35
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-21.00.txt21:35
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-21.00.log.html21:35
glencGreat meeting, vishy21:35
vishythx glenc21:35
*** edgarmagana has joined #openstack-meeting21:36
*** rnirmal has quit IRC21:37
*** hisaharu has left #openstack-meeting21:37
*** Vek has left #openstack-meeting21:38
*** Guest23118 has quit IRC21:41
*** devcamcar_ has left #openstack-meeting21:44
*** devcamcar_ has quit IRC21:44
*** nati has quit IRC21:46
*** nati has joined #openstack-meeting21:46
*** edconzel has quit IRC21:48
*** edconzel has joined #openstack-meeting21:48
*** nati has quit IRC21:51
*** Tushar has quit IRC21:52
*** ryu_ishimoto has joined #openstack-meeting21:53
*** Jamey has joined #openstack-meeting21:59
*** liemmn has quit IRC22:00
danwentok, hello net stackers…. not usual that we have so so much time between the main meeting and this one22:00
danwentmaybe it was because vish runs speedy meetings :)22:00
*** ying has joined #openstack-meeting22:01
salvhello dan22:01
edgarmaganahi everybody!22:01
openstackMeeting started Tue Aug 30 22:01:50 2011 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.22:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.22:01
danwentagenda: http://wiki.openstack.org/Network/Meetings22:01
*** SumitNaiksatam has joined #openstack-meeting22:02
danwent#topic general status22:02
*** openstack changes topic to "general status"22:02
danwentdon't' forget to sign up for openstack essex summit : http://wiki.openstack.org/Summit/Essex22:02
danwentis troy around?22:02
*** Jamey has quit IRC22:03
danwentddutta mentioned that there's not donate update today, but they're hoping for an API spec writeup very soon22:03
danwentok, will skip melange for now.  we can circle back.22:03
danwent#topic quantum22:03
*** openstack changes topic to "quantum"22:03
danwentso we're now past "feature freeze"22:04
*** shwetaap has joined #openstack-meeting22:04
dduttanext week for sure!22:04
danwentwhich means the only things that should be dropping into trunk should be bug fixes and tests.22:04
*** Jamey has joined #openstack-meeting22:04
danwentnow is the time to really be testing all of your use cases and make sure they are working….22:04
danwentSept 10th is "release branch point" release, after which only serious bugs will be committed on the branch.22:05
danwentany questions/thoughts?22:05
danwentcurrently, anyone can assign a bug to diablo-rbp...22:05
salvWe should try not to have unassigned bugs on rbp milestone at this stage22:05
danwenthey troy, can we circle back to melange in a bit, or do you have to run?22:05
troytomani'll be here22:06
danwenttroy: thx22:06
danwentparticularly if they are high priority or above, which means they should be fixed before diablo-rbp22:06
salvI think if we cannot find takers by end of the week, we should probably untarget those bugs22:06
danwentsalv: agreed.22:06
danwentright now I want to focus on getting things stable as quickly as possible.22:07
danwentWe've done a good job of clearing out the merge pipeline… merges now should be simple and targeted.22:07
danwentso if you have a "pet bug" you're looking to fix for diablo-rbp, make sure it is created, targeted at diablo-rbp, and have someone assigned to it.22:08
danwentonly two active reviews, since we got the cisco code merged: https://code.launchpad.net/quantum/+activereviews22:08
salvWhat should we do with the auth branch. Technically it is a feature, so we should delay it to Essex now.22:08
danwentsalv's keystone branch is just waiting on final input from ziad22:08
SumitNaiksatamthanks Dan for the review and merge22:08
danwentsalv: it has an exception, so technically it can go in, but we don't have client code that uses it22:09
salvBut I'd say that it is a feature which can be easily turned off, so we should not worry about integration.22:09
danwentas far as I know, so I'm not sure there is much of a point of pushing it for diablo22:09
salvAnd, as Dan said, it has an exception :)22:09
danwentsalv: yeah, I'm not worried… just wondering if it is useful until we modify the client lib22:09
danwentand I'd rather not mess with the client lib right now.22:09
danwentis anyone working on keystone support in the client lib?22:10
salvI don't think so.22:10
danwent#action #danwent create blueprint for keystone support in client lib… currently unassigned.22:10
danwentsalv:  I'm fine with it going if we can get it in the next few days22:10
salvI'm waiting for a reply from Ziad.22:11
danwentits pretty decoupled from everything else and is definitely a step toward where we want to be.22:11
danwentsalv: k, if we don't hear back from him fairly soon, we can just bump it to essex.  I'm fine either way.22:11
somikI agree, auth is pretty isolated adn can be easily turned off22:11
*** jrouault has quit IRC22:11
danwentcode is already reviewed from a netstack-core perspective too, so its good to go once ziad looks at it.22:12
salvfor client library, do we want a bug or a blueprint? Not a lot of difference, just trying to understand whether we'd like to address this before rbp22:12
salvI was talking about auth token in client library, of course22:12
danwentsalv: I think is probably a bit much to address before rbp, unless we have someone volunteering to get it done ASAP….22:12
danwentI want to minimize changes in areas that affect everyone, and the client lib affects a lot of people.22:12
*** DZ has joined #openstack-meeting22:13
danwentbug is fine, as I don't think there's a lot of design work to be done and written up in a blueprint22:13
salvLet's get it out of rbp then. Negative side effect is that cli won't work on Quantum when keystone integration is enabled.22:13
*** DZ is now known as Guest7593222:13
danwentsalve: sounds good.22:14
*** Guest75932 has quit IRC22:14
danwentok, on quantum manager, it sounds like we're getting good reviews from nova core, so I think we're in good shape there.22:14
salvVery good.22:15
danwentI was also thinking that we will want to consider a CLI utility that can query Ryu's nova vif-id extensions to list the available interfaces for a tenant.22:15
salvWeren't you already planning a change to nova-manage?22:15
danwent#action #danwent, create bug for utility to view vif-ids in nova22:15
danwentsalv: right now we're being pretty conservative with changes to nova manage…. to try not to clutter things up to much.  That's definitely an option though.22:16
salvdanwent: agreed.22:17
danwentOk, sounds like heckj has a fix for the cheetah issue on the build system22:17
heckjdanwent: yep - in and solved, Verified earlier today22:17
danwentand congrats to arvind and team…. the quantum dashboard work just got merged into dashboard!22:17
salvthank a lot heckj22:18
*** zns has quit IRC22:18
danwentheckj: much appreciated22:18
salvcheers to the GUI team22:18
heckjsalv: sorry to leave it wait until today, I lost track from the weekend...22:18
danwenton quantum packaging....22:18
salvheckj: np. That will teach us to think twice before adding a dependency22:18
danwenttyler is not available today, but we're trying to figure out whether it will be feasible to do the code rearranging needed for packaging during diablo22:19
danwenthe will be sending an email out hopefully tomorrow about this.22:19
danwentif so, we will need to try and get all diablo-rbp work in early, so we can swap the branch over the the new directory structure.22:19
danwentof course, we would make sure the new structure is available early for testing22:19
danwentany questions/thoughts on packaging?22:20
danwentLast point is documentation.  I contacted Anne Gentle (lead of OpenStack packaging) about getting the ball rolling there.22:20
*** dizhou has joined #openstack-meeting22:21
danwentwill be filling out BP with some more specific thoughts based on her input.  Docs aren't fun, but they will be very important to helping people understand quantum.22:21
danwentOk, anything else on quantum?22:21
danwent#topic open discussion22:21
*** openstack changes topic to "open discussion"22:21
salvTroy is still waiting...22:21
danwentah, troy, can you talk about melange?22:21
danwentsalv: hehe, same thought22:22
troytomanmost work is focused on addressing comments we got from the nova team.22:22
troytomanexpect most of that work to be done this week.22:22
danwenttroy: if I want to be testing against the latest melange code, I assume the right thing to do is to pull from your teams nova branch that includes melange?22:23
troytomanotherwise we are working on getting it integrated with quantum so we can do some scale testing22:23
troytomandanwent: yes22:23
troytomanwe are pushing updates there22:23
danwentgreat.  I still need to test the QuantumManager with melange again before we really push it into nova...22:23
troytomanthere are some areas where nova still gets IPs from it's DB22:23
danwentI tested it a while back, but there have been some changes.22:23
troytomanwe will need to refactor those calls to go through the network manager.22:24
troytomanhaven't sorted out exactly how/who to do that yet but should figure that out this week as well22:24
troytomanwe have moved several things in the openstack-commons22:24
troytomanwe will probably propose to change quantum to leverage some of those common elements as well22:25
*** ying has quit IRC22:25
troytomanbut, we are getting that code finalized before sorting that out22:25
*** ying has joined #openstack-meeting22:26
danwentgreat.  anything else?22:26
danwent#topic open discussion (for real this time)22:26
*** openstack changes topic to "open discussion (for real this time)"22:26
danwentnot to jinx it, but this could be our shortest meeting ever :)22:26
*** HowardRoark has quit IRC22:27
salvDo you want me to start talking about random things :)22:27
danwentI was worried someone would do that!22:27
danwentok, thanks folks!22:27
*** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/"22:27
openstackMeeting ended Tue Aug 30 22:27:32 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)22:27
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-22.01.html22:27
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-22.01.txt22:27
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-22.01.log.html22:27
salvBye, have a good one!22:27
*** Jamey has quit IRC22:27
*** markvoelker has left #openstack-meeting22:27
SumitNaiksatamthanks, bye!22:27
*** edgarmagana has quit IRC22:27
*** SumitNaiksatam has quit IRC22:28
*** markvoelker has joined #openstack-meeting22:28
*** ddutta has left #openstack-meeting22:29
*** mandell has left #openstack-meeting22:29
*** ryu_ishimoto has quit IRC22:32
*** shwetaap has left #openstack-meeting22:33
*** dizhou has quit IRC22:34
*** nati has joined #openstack-meeting22:40
*** mattray has quit IRC22:42
*** joearnold has quit IRC22:44
*** blamar has quit IRC22:44
*** notmyname has quit IRC22:44
*** termie has quit IRC22:44
*** RichiH has quit IRC22:44
*** comstud has quit IRC22:44
*** Daviey has quit IRC22:44
*** jeremyb has quit IRC22:44
*** antonym has quit IRC22:44
*** carlp has quit IRC22:44
*** cbeck has quit IRC22:44
*** Adri2000 has quit IRC22:44
*** zykes- has quit IRC22:44
*** bhall has quit IRC22:44
*** xtoddx has quit IRC22:44
*** jorgew has left #openstack-meeting22:44
*** danwent has left #openstack-meeting22:46
*** ryu_ishimoto has joined #openstack-meeting22:47
*** rohitagarwalla has quit IRC22:48
*** ryu_ishimoto has quit IRC22:48
*** johnpur has quit IRC22:53
*** joearnold has joined #openstack-meeting22:54
*** carlp has joined #openstack-meeting22:54
*** cbeck has joined #openstack-meeting22:54
*** Adri2000 has joined #openstack-meeting22:54
*** blamar has joined #openstack-meeting22:54
*** comstud has joined #openstack-meeting22:54
*** notmyname has joined #openstack-meeting22:54
*** termie has joined #openstack-meeting22:54
*** RichiH has joined #openstack-meeting22:54
*** zykes- has joined #openstack-meeting22:54
*** Daviey has joined #openstack-meeting22:54
*** bhall has joined #openstack-meeting22:54
*** jeremyb has joined #openstack-meeting22:54
*** xtoddx has joined #openstack-meeting22:54
*** antonym has joined #openstack-meeting22:54
*** edconzel has quit IRC22:56
*** joearnold has quit IRC23:03
*** blamar has quit IRC23:03
*** notmyname has quit IRC23:03
*** termie has quit IRC23:03
*** RichiH has quit IRC23:03
*** comstud has quit IRC23:03
*** Daviey has quit IRC23:03
*** jeremyb has quit IRC23:03
*** antonym has quit IRC23:03
*** carlp has quit IRC23:03
*** cbeck has quit IRC23:03
*** Adri2000 has quit IRC23:03
*** zykes- has quit IRC23:03
*** bhall has quit IRC23:03
*** xtoddx has quit IRC23:03
*** joearnold has joined #openstack-meeting23:05
*** carlp has joined #openstack-meeting23:05
*** cbeck has joined #openstack-meeting23:05
*** Adri2000 has joined #openstack-meeting23:05
*** blamar has joined #openstack-meeting23:05
*** notmyname has joined #openstack-meeting23:05
*** termie has joined #openstack-meeting23:05
*** RichiH has joined #openstack-meeting23:05
*** zykes- has joined #openstack-meeting23:05
*** Daviey has joined #openstack-meeting23:05
*** bhall has joined #openstack-meeting23:05
*** jeremyb has joined #openstack-meeting23:05
*** xtoddx has joined #openstack-meeting23:05
*** antonym has joined #openstack-meeting23:05
*** medberry is now known as med_out23:05
*** nati has quit IRC23:08
*** nati has joined #openstack-meeting23:09
*** novas0x2a|laptop has quit IRC23:13
*** nati has quit IRC23:13
*** HowardRoark has joined #openstack-meeting23:14
*** creiht has left #openstack-meeting23:17
*** novas0x2a|laptop has joined #openstack-meeting23:20
*** markvoelker has quit IRC23:22
*** salv has quit IRC23:26
*** heckj has quit IRC23:35
*** ohnoimdead has quit IRC23:40
*** nati has joined #openstack-meeting23:53

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