| *** dendrobates is now known as dendro-afk | 00:23 | |
| *** novas0x2a|laptop has joined #openstack-meeting | 00:38 | |
| *** vladimir3p has quit IRC | 00:48 | |
| *** jakedahn has quit IRC | 00:51 | |
| *** HowardRoark has joined #openstack-meeting | 01:02 | |
| *** HowardRoark has joined #openstack-meeting | 01:03 | |
| *** ohnoimdead has quit IRC | 01:07 | |
| *** novas0x2a|laptop has quit IRC | 01:08 | |
| *** tsuzuki_ has quit IRC | 01:34 | |
| *** tsuzuki_ has joined #openstack-meeting | 01:34 | |
| *** msinhore has quit IRC | 01:39 | |
| *** msinhore has joined #openstack-meeting | 01:52 | |
| *** dendro-afk is now known as dendrobates | 01:56 | |
| *** adjohn has quit IRC | 02:03 | |
| *** tsuzuki_ has quit IRC | 03:02 | |
| *** dendrobates is now known as dendro-afk | 03:07 | |
| *** tsuzuki_ has joined #openstack-meeting | 03:10 | |
| *** martine has joined #openstack-meeting | 03:31 | |
| *** msinhore has quit IRC | 03:36 | |
| *** joearnold has joined #openstack-meeting | 03:54 | |
| *** adjohn has joined #openstack-meeting | 04:02 | |
| *** martine has quit IRC | 04:40 | |
| *** martine_ has quit IRC | 04:45 | |
| *** deshantm is now known as deshantm_away | 05:06 | |
| *** joearnold has quit IRC | 05:27 | |
| *** joearnold has joined #openstack-meeting | 05:27 | |
| *** HowardRo_ has joined #openstack-meeting | 05:39 | |
| *** HowardRo_ has joined #openstack-meeting | 05:39 | |
| *** HowardRoark has quit IRC | 05:41 | |
| *** HowardRoark has joined #openstack-meeting | 05:57 | |
| *** HowardRoark has quit IRC | 05:59 | |
| *** HowardRo_ has quit IRC | 05:59 | |
| *** joearnold has quit IRC | 06:29 | |
| *** adjohn has quit IRC | 07:54 | |
| *** darraghb has joined #openstack-meeting | 08:48 | |
| *** markvoelker has joined #openstack-meeting | 11:57 | |
| *** jaypipes has joined #openstack-meeting | 12:02 | |
| *** jaypipes has quit IRC | 12:11 | |
| *** joesavak has joined #openstack-meeting | 12:20 | |
| *** jaypipes has joined #openstack-meeting | 12:22 | |
| *** jsavak has joined #openstack-meeting | 12:22 | |
| *** joesavak has quit IRC | 12:26 | |
| *** edconzel has joined #openstack-meeting | 12:27 | |
| *** markvoelker has quit IRC | 12:44 | |
| *** med_out is now known as medberry | 12:53 | |
| *** jaypipes has quit IRC | 12:56 | |
| *** martine has joined #openstack-meeting | 13:00 | |
| *** jsavak has quit IRC | 13:02 | |
| *** mattray has joined #openstack-meeting | 13:09 | |
| *** tsuzuki_ has quit IRC | 13:26 | |
| *** martine has quit IRC | 13:28 | |
| *** mdomsch has joined #openstack-meeting | 13:50 | |
| *** msinhore has joined #openstack-meeting | 14:07 | |
| *** joesavak has joined #openstack-meeting | 14:21 | |
| *** vladimir3p has joined #openstack-meeting | 14:33 | |
| *** rnirmal has joined #openstack-meeting | 14:53 | |
| *** dragondm has joined #openstack-meeting | 14:53 | |
| *** jsavak has joined #openstack-meeting | 14:58 | |
| *** vladimir3p has quit IRC | 15:00 | |
| *** joesavak has quit IRC | 15:00 | |
| *** markvoelker has joined #openstack-meeting | 15:01 | |
| *** martine has joined #openstack-meeting | 15:04 | |
| *** joesavak has joined #openstack-meeting | 15:18 | |
| *** martine_ has joined #openstack-meeting | 15:19 | |
| *** martine has quit IRC | 15:20 | |
| *** jsavak has quit IRC | 15:21 | |
| *** edconzel_ has joined #openstack-meeting | 15:35 | |
| *** edconzel has quit IRC | 15:35 | |
| *** edconzel_ is now known as edconzel | 15:35 | |
| *** jsavak has joined #openstack-meeting | 15:57 | |
| *** joesavak has quit IRC | 15:57 | |
| *** adjohn has joined #openstack-meeting | 15:57 | |
| *** edconzel has quit IRC | 16:01 | |
| *** edconzel has joined #openstack-meeting | 16:01 | |
| *** troytoman-away is now known as troytoman | 16:12 | |
| *** HowardRoark has joined #openstack-meeting | 16:14 | |
| *** heckj has joined #openstack-meeting | 16:37 | |
| *** novas0x2a|laptop has joined #openstack-meeting | 16:49 | |
| *** dprince has joined #openstack-meeting | 16:53 | |
| *** tsuzuki_ has joined #openstack-meeting | 17:07 | |
| *** mdomsch has quit IRC | 17:18 | |
| *** dragondm has quit IRC | 17:19 | |
| *** ohnoimdead has joined #openstack-meeting | 17:24 | |
| *** tsuzuki_ has quit IRC | 17:35 | |
| *** darraghb has quit IRC | 17:47 | |
| *** jakedahn has joined #openstack-meeting | 17:47 | |
| *** bengrue has joined #openstack-meeting | 17:48 | |
| *** novas0x2a|laptop has quit IRC | 17:53 | |
| *** novas0x2a|laptop has joined #openstack-meeting | 17:54 | |
| *** jsavak has quit IRC | 18:01 | |
| *** jsavak has joined #openstack-meeting | 18:02 | |
| *** vladimir3p has joined #openstack-meeting | 18:03 | |
| *** joesavak has joined #openstack-meeting | 18:06 | |
| *** jsavak has quit IRC | 18:08 | |
| *** adjohn has quit IRC | 18:52 | |
| *** johnpur has joined #openstack-meeting | 18:52 | |
| *** adjohn has joined #openstack-meeting | 18:57 | |
| *** jsavak has joined #openstack-meeting | 19:00 | |
| *** joesavak has quit IRC | 19:03 | |
| *** _adjohn has joined #openstack-meeting | 19:04 | |
| *** adjohn has quit IRC | 19:05 | |
| *** _adjohn is now known as adjohn | 19:05 | |
| *** creiht has joined #openstack-meeting | 19:11 | |
| *** jbryce has joined #openstack-meeting | 19:16 | |
| *** jorgew has joined #openstack-meeting | 19:29 | |
| *** mdomsch has joined #openstack-meeting | 19:29 | |
| *** dragondm has joined #openstack-meeting | 19:38 | |
| *** primeministerp1 has joined #openstack-meeting | 19:43 | |
| _0x44 | Wasn't there supposed to be a ci meeting at 12? | 19:43 |
|---|---|---|
| heckj | lurking, but I guess not... | 19:46 |
| *** jmckenty has joined #openstack-meeting | 19:52 | |
| *** zns has joined #openstack-meeting | 19:58 | |
| jmckenty | time? | 20:00 |
| ttx | _0x44: monty is off | 20:00 |
| jbryce | roll call? | 20:00 |
| jmckenty | 'ere | 20:01 |
| jbryce | is that your cockney accent? | 20:01 |
| jmckenty | yup | 20:01 |
| vishy | o/ | 20:01 |
| johnpur | o/ | 20:02 |
| ttx | \o | 20:02 |
| jorgew | hi | 20:02 |
| jmckenty | johnpur? | 20:02 |
| vishy | pretty sure jesse is out | 20:02 |
| jbryce | he raised his hand | 20:03 |
| johnpur | hey joshua | 20:03 |
| jmckenty | ah, sorry | 20:03 |
| zns | ziad here | 20:03 |
| jbryce | yeah jesse is out and i think jay is going to be out as well | 20:03 |
| vishy | and i think ewan is on a plane | 20:03 |
| jmckenty | notmyname: you here? | 20:03 |
| notmyname | ya | 20:03 |
| jmckenty | as in, paying attention? :p | 20:03 |
| jbryce | #startmeeting | 20:03 |
| openstack | Meeting started Tue Aug 30 20:03:32 2011 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot. | 20:03 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic. | 20:03 |
| ttx | soren won't make it | 20:03 |
| jbryce | doesn't look like we have a quorum for today | 20:03 |
| jmckenty | mtaylor is here, too | 20:03 |
| jmckenty | I think we have quorum | 20:03 |
| vishy | how many do we need for a quorum? 6? | 20:04 |
| jbryce | 7 | 20:04 |
| jmckenty | jbryce vishy jmckenty mtaylor johnpur notmyname ttx | 20:04 |
| ttx | mtaylor is not ppb | 20:04 |
| jmckenty | ah, right | 20:04 |
| ttx | yet. | 20:04 |
| jmckenty | and dendro-afk is afk | 20:04 |
| vishy | ok discussion and maybe one more will show up? | 20:05 |
| jbryce | yeah... | 20:05 |
| ttx | I don't mind calling this one off :) | 20:05 |
| jmckenty | devcamcar is ppb after diablo, correct? | 20:05 |
| jmckenty | assuming he's still ptl of dashboard | 20:05 |
| vishy | devcamcar and zns both | 20:05 |
| jmckenty | right | 20:05 |
| ttx | bourbon? | 20:05 |
| jmckenty | right | 20:05 |
| jbryce | can we do an abbreviated non-binding discussion on the api issue then? | 20:05 |
| ttx | sure | 20:05 |
| jbryce | say 10 minutes and then we can have the rest of the hour back | 20:06 |
| vishy | sounds good | 20:06 |
| jmckenty | sounds good - can you summarize the state of debate? | 20:06 |
| vishy | jorge put together a proposal | 20:06 |
| jbryce | sure, lots of debate back and forth on the mailing list over the course of 10 days or so | 20:06 |
| vishy | which i think outlines things well | 20:06 |
| jmckenty | I've read the thread as it unfolded, and have been impacted by it in various ways | 20:06 |
| jbryce | http://wiki.openstack.org/Governance/Proposed/APIManagement | 20:06 |
| jmckenty | but I don't see the connection between the proposal and the debate | 20:06 |
| vishy | the debate isn't going anywhere because there is no ownership | 20:06 |
| ttx | The proposal is a way to codify the "API belongs to architects" into law. | 20:07 |
| vishy | so it is just a bunch of opinions on the best way to do things | 20:07 |
| jbryce | i 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 projects | 20:07 |
| jmckenty | If I can summarize, the debate has been "Is API design up front slowing down OpenStack and creating problems" | 20:07 |
| ttx | it doesn't settle the discussion. | 20:07 |
| jorgew | ttx: No that's not the proposal at all | 20:07 |
| jbryce | ttx: i didn't read the proposal that way | 20:07 |
| jmckenty | I did | 20:07 |
| jmckenty | I'm with ttx on this | 20:07 |
| notmyname | e too | 20:07 |
| vishy | ttx: I disagree. The proposal says that the api belongs to the projects, aside that they must follow common guidelines | 20:07 |
| jmckenty | It proposes creating a new PTL | 20:07 |
| jbryce | no | 20:07 |
| jmckenty | yes, it does | 20:08 |
| jorgew | Right. The PTL owns the API | 20:08 |
| vishy | ttx: and go through an approval by the ppb to ensure that the guidelines are met | 20:08 |
| ttx | vishy: the "PTL" of the guidelines project owns the PAI | 20:08 |
| jorgew | The PPB owns the guidelines | 20:08 |
| ttx | vishy: you misread, I think | 20:08 |
| vishy | hmm | 20:08 |
| jbryce | ttx: PTL in proposal refers to each project's individual PTL | 20:08 |
| jmckenty | yeah, the problem has been architects inventing APIs at all | 20:08 |
| jmckenty | jbryce: no it doesnt | 20:08 |
| notmyname | "The PPB will nominate a PTL for the api-guidelines project" | 20:08 |
| jbryce | right | 20:08 |
| jbryce | api-guidelines being the broad standards | 20:09 |
| ttx | vishy: it creates a new project with a new "appointed PTL" that owns the spec, suject to PPB dismissal | 20:09 |
| jbryce | like RESTful | 20:09 |
| zns | ttx: 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 |
| jbryce | the api-guidelines PTL does not own the Compute API or Keystone API | 20:09 |
| jorgew | The PPB owns guidelines and goals that are inter-projcet requirements | 20:09 |
| jmckenty | the metadebate is whether OpenStack should be involved in forward-looking API specs at all | 20:09 |
| jmckenty | since it was historically an anti-goal | 20:09 |
| jorgew | the PTL of the projcet ows that API | 20:09 |
| ttx | jorgew: I think you're not after a "PTL" here, but after a delegation of responsability, much like "release manager" | 20:10 |
| jbryce | ttx: i agree with that | 20:10 |
| jorgew | sorry for the confusion, but end of the day the PTL of the project owns the API | 20:10 |
| vishy | I don't necessarily think that the api-guidelines needs a ptl per se | 20:10 |
| ttx | PTLs are not chosen by the PPB but by the devs of the project, and I don't want to bastardize the concept of core project | 20:10 |
| ttx | (just discussing how the proposal is presented, not the justification of it) | 20:11 |
| vishy | perhaps simplify it to the PPB can appoint someone to manage the guidelines | 20:11 |
| jorgew | You know — we can let the PPB outline the api-guidelins project as it sees fit - with or without a PTL. | 20:11 |
| vishy | I agree that calling it a PTL is confusing | 20:11 |
| jbryce | yes | 20:11 |
| jmckenty | I'm still not sold on the need for such a project | 20:11 |
| jorgew | The reason that's there is that we need someone to settle issures on guidelines | 20:11 |
| johnpur | api working group? | 20:11 |
| jorgew | Exactly | 20:12 |
| ttx | jmckenty: 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 |
| jmckenty | more reasonable - except to my previous point that we specifically eschewed such an activity before | 20:12 |
| vishy | jmckenty: consistency among openstack apis is a concern | 20:12 |
| jmckenty | If there are sets of OpenStack members who would like to involve themselves in forward-looking API discussions, | 20:12 |
| notmyname | how is this not a nova (or other project) specific thing? when you are talking about the "openstack api" you are referring to nova | 20:12 |
| jorgew | But 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 |
| jmckenty | there are a dozen working groups they can go join | 20:13 |
| vishy | so we need projects to own APIs | 20:13 |
| johnpur | there is a need for some consistency in the API's presented by OpenStack projects | 20:13 |
| vishy | and there to be a set of guidelines for the projects to follow | 20:13 |
| ttx | jorgew: oh, ok | 20:13 |
| johnpur | in areas like extension mechanisms, etc. | 20:13 |
| vishy | guidelines should be as light as possible IMO. | 20:13 |
| jbryce | vishy: +1 | 20:13 |
| ttx | jorgew: so that would be a delegate, nominated of the PPB to care about API consistency. | 20:14 |
| vishy | ttx: +1 | 20:14 |
| jorgew | ttx: yes | 20:14 |
| ttx | jorgew: "API guidelines master" or something | 20:14 |
| ttx | jorgew: we, delegates of the PPB, like nice and round titles | 20:14 |
| jorgew | Right — sorry shouldn't have called it a PPL | 20:14 |
| notmyname | but the nova and the swift APIs (for example) are already very different (fundamentally, not in how they refer to things) | 20:14 |
| johnpur | the "API master" needs to be responsive to the community | 20:14 |
| jmckenty | and the ec2 APIs are as well | 20:14 |
| jbryce | which is one of the things that i think people would like to see improved upon | 20:15 |
| ttx | jorgew: I'd like to see it discussed on the list -- it sounds like a nice middle way between the two opposed views | 20:15 |
| jorgew | notmyname: yes they are different because one is a data API and one is a control API we can have guidlines for bot | 20:15 |
| jbryce | that was actually one of the points george reese made | 20:15 |
| jmckenty | which, if we're talking about being responsive to the community, the EC2 APIs remain high on the list | 20:15 |
| johnpur | ttx: +1 | 20:15 |
| vishy | notmyname: 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 |
| jmckenty | vishy: +1 | 20:16 |
| jmckenty | guidelines are done. | 20:16 |
| johnpur | vishy: agree | 20:16 |
| jorgew | vishy +1 | 20:16 |
| notmyname | vishy: which sounds good | 20:16 |
| ttx | jorgew: when you say "the PTL has the final say in determining consensus" you mean which PTL ? | 20:16 |
| jmckenty | vishy: if we add a reference to WHICH definition of REST we're using, we're probably all the way done. | 20:16 |
| vishy | jmckenty: :) | 20:16 |
| *** troytoman is now known as troytoman-away | 20:16 | |
| jbryce | so can i try to summarize again the 2 high level goals? | 20:17 |
| jorgew | ttx: I mean the API master when on issues related to guidlien or roals | 20:17 |
| jorgew | *goals | 20:17 |
| jmckenty | so is any of this a discussion of how and when we modify the API spec? | 20:17 |
| jmckenty | or is that up to the PTLs' discretion | 20:17 |
| zns | jmckenty: I think that is important. The way it is being done today is painful, trying to hit a moving target. | 20:18 |
| jbryce | 1) 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 |
| vishy | jmckenty: 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 guidelines | 20:18 |
| jorgew | jmckentry: 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 reviewed | 20:18 |
| jmckenty | dear god | 20:18 |
| ttx | jbryce: 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 week | 20:18 |
| jmckenty | we're sunk. | 20:18 |
| vishy | jmckenty: why? | 20:18 |
| johnpur | i don't think the ppb is in the business of api review | 20:18 |
| vishy | johnpur: I assume we would delegate it | 20:19 |
| ttx | johnpur: that's why we delegate it :) | 20:19 |
| jmckenty | you realize this was the topic of my keynote at the inaugural openstack design summit? | 20:19 |
| johnpur | whew! | 20:19 |
| jorgew | johnpur: review only in issures of guidelines, inter-project consistency, goals | 20:19 |
| jmckenty | we have reached the pinnacle of what we were trying to avoid | 20:19 |
| vishy | someone has to own consistency, jmckenty. Who else will do it? | 20:19 |
| jmckenty | A devilish consistency is the hobgoblin of little minds | 20:20 |
| jbryce | we're not talking devilish consitency | 20:20 |
| jmckenty | consistency has never been achieved by specs up front | 20:20 |
| jmckenty | it's been achieved by dialog between interested parties | 20:20 |
| jbryce | we just don't want ziad to only publish a corba interface to keystone. = ) | 20:20 |
| jmckenty | and rapid iteration | 20:20 |
| zns | jbryce: you promised not to tell! | 20:21 |
| notmyname | jbryce: so go talk to him and say "don't do that" | 20:21 |
| jmckenty | notmyname: EXACTLY | 20:21 |
| notmyname | interested parties talk and then very interested parties code | 20:21 |
| jmckenty | instead, 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-meeting | 20:21 | |
| jmckenty | before we've even written any code to test whether it's a good IDEA | 20:21 |
| jbryce | you 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 |
| jbryce | if 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, etc | 20:22 |
| jmckenty | sure - that's what functional tests are for :) | 20:22 |
| vishy | jmckenty: we don't have to use specs up front | 20:22 |
| jbryce | personally i'd rather have the guidelines be light, but i think having them available is helpful | 20:22 |
| sandywalsh | so, if we make another API that doesn't belong to Openstack API (tm), does it need to follow those guidelines? | 20:22 |
| jmckenty | what's wrong with HACKING.txt? | 20:22 |
| jmckenty | sandywalsh: it's OpenStack(tm) API(tm) | 20:23 |
| jorgew | vishy is right there is no requirement that new featurs need to be speced up front | 20:23 |
| johnpur | i think having an overall api design schema is a good thing... and that Vish defined it earlier | 20:23 |
| vishy | sandywalsh: nope | 20:23 |
| notmyname | if we traded "api guidelines" for "coding guidelines" would this change the argument? the PPB should be involved with either, IMO | 20:23 |
| jbryce | we have heard from many many people that the current state of the api is suboptimal (for compute especially) | 20:23 |
| vishy | notmyname: who is? | 20:23 |
| sandywalsh | vishy, well then, I think the architects can have a field day and the programmers can get something working | 20:23 |
| jmckenty | jbryce: the reason it is suboptimal is because the separation of API spec and developers has made it hard to improve | 20:24 |
| notmyname | s/should/shouldn't/ | 20:24 |
| jmckenty | jbryce: IMO | 20:24 |
| _0x44 | vishy: -core, IMO | 20:24 |
| vishy | notmyname: i read it that way, but who is responsible | 20:24 |
| jbryce | jmckenty: i'm not disagreeing and a big part of the proposal is to remove that separation | 20:24 |
| jorgew | notmyname: Coding guidlines and API guidlins are different things — API guidlines affect users | 20:24 |
| notmyname | vishy: the PTL and core devs. responsible adults | 20:24 |
| vishy | _0x44: so we make an openstack-core group? | 20:24 |
| vishy | how do the 6 projects decide guidelines then? | 20:25 |
| jmckenty | ah, we're back to resolving openstack-common | 20:25 |
| vishy | * 5 + 1 inc | 20:25 |
| jmckenty | :) | 20:25 |
| creiht | api-common | 20:25 |
| _0x44 | vishy: I don't think that'd work, especially if the internal coding guidelines for each project are different. | 20:25 |
| * creiht hides | 20:25 | |
| jmckenty | is that a stall? | 20:26 |
| jmckenty | or a net-partition | 20:26 |
| vishy | notmyname: do the ptl's just get together and define the api-guidelines between them? | 20:26 |
| jmckenty | notionally that IS what the PPB is for | 20:26 |
| jmckenty | it's PTLs plus a few other reps | 20:26 |
| vishy | jmckenty: yes, that is my thought | 20:26 |
| johnpur | it 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 |
| notmyname | vishy: so far it's been a gentleman's agreement to not suck | 20:27 |
| jmckenty | http://etherpad.openstack.org/HACKING-txt | 20:27 |
| vishy | I know it is hard to think of things this way, but when we delegate something to the ppb, we are delegating it to ourselves | 20:27 |
| jorgew | vishy: The PTLs have almost absoute power when it comes to the API…the guidelines in my opinion belong to the PPB. | 20:27 |
| jmckenty | johnpur: they're milestone releases, the consumers will survive | 20:27 |
| sandywalsh | creiht +1, api-common | 20:27 |
| creiht | oh noes, what have I done? | 20:28 |
| notmyname | johnpur: let's focus on getting production-ready stuff | 20:28 |
| johnpur | jmckenty: iff you don't have folks working to integrate | 20:28 |
| vishy | notmyname: it has been for you perhaps | 20:28 |
| sandywalsh | johnpur, is the concern 3rd parties writing against a moving target? | 20:28 |
| vishy | notmyname: for us, so far its been, wait for the api spec to be finalized and then implement it without changes | 20:28 |
| vishy | notmyname: not sucking has not been a concern :p | 20:29 |
| jbryce | here's a new question | 20:29 |
| johnpur | sandywalsh: yes, and folks like service providers or consultants that rae standing up clouds based on openstack currently | 20:29 |
| notmyname | vishy: perhaps I'm confused as to why you (the nova devs) aren't the ones defining the API for the project you are making | 20:29 |
| vishy | notmyname: that is what we are trying to fix with this proposal | 20:30 |
| sandywalsh | Perhaps we just need more versions ... and stop dumping the kitchen sink into 1.1? | 20:30 |
| jbryce | do 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 |
| pvo | sandywalsh: ++ | 20:30 |
| notmyname | proposal: nova API == whatever vishy says it is because he's the one respnsible for the code ;-) | 20:30 |
| pvo | jbryce: yes, I think that is the sentiment. | 20:30 |
| sandywalsh | Big Up Front Design isn't the answer, but freeze faster and iterate | 20:30 |
| jbryce | sandywalsh: this proposal is much less up front design than the current state | 20:31 |
| jorgew | sandywalsh: that's another concept in the proposal eventually you freeze and move to another version if you wish | 20:31 |
| johnpur | sandywalsh: +1 | 20:31 |
| zns | Freeze 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 |
| vishy | notmyname: I think we agree on that part | 20:31 |
| pvo | but won't you 'freeze' on the releases? | 20:31 |
| pvo | what is in the api, is the api? | 20:31 |
| sandywalsh | zns +1 | 20:32 |
| *** edconzel_ has joined #openstack-meeting | 20:32 | |
| vishy | notmyname: you think general guidelines for consistency are unimportant, though? | 20:32 |
| _0x44 | sandywalsh: 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: disagree | 20:32 |
| *** joearnold has joined #openstack-meeting | 20:32 | |
| *** devcamcar_ has joined #openstack-meeting | 20:32 | |
| vishy | because if we don't have consistency guidelines, I might just scrub the current api and use Direct API! | 20:32 |
| vishy | :) | 20:32 |
| jorgew | _0x44: Let's not do that please. | 20:32 |
| _0x44 | sandywalsh: See devcamcar_'s email. | 20:32 |
| johnpur | there 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 summit | 20:33 |
| pvo | vishy: 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 |
| jmckenty | pvo: WHY are we freezing APIs separate from releases? | 20:33 |
| vishy | pvo: I'm kidding, of course | 20:33 |
| devcamcar_ | o/ | 20:33 |
| jmckenty | I still don't get this "FREEZE THE API" discussion | 20:33 |
| jorgew | zns: +1, and the PTL should probably decide where that stable point is. | 20:33 |
| pvo | jmckenty: I think at release, that is the api. | 20:33 |
| _0x44 | vishy: +1, that's what we should have done to begin with. | 20:33 |
| *** edconzel has quit IRC | 20:33 | |
| *** edconzel_ is now known as edconzel | 20:33 | |
| jmckenty | pvo: +1 | 20:33 |
| pvo | it doesn't matter if its 'frozen' or whatnot. | 20:33 |
| notmyname | vishy: 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 |
| vishy | notmyname, jmckenty, this is why we need to define guidelines | 20:34 |
| sandywalsh | jmckenty, give the integrators/partners something to work against | 20:34 |
| * _0x44 pipes down since this is a PPB meeting. | 20:34 | |
| sandywalsh | jmckenty, albeit incomplete | 20:34 |
| vishy | notmyname: +1 to that. | 20:34 |
| jmckenty | sandywalsh: the integrators and partners have no business trying to build against an API in between releases | 20:34 |
| jmckenty | the faster we iterate, the faster we'll have an API the partners can live with | 20:34 |
| sandywalsh | jmckenty, they do, they just can't bitch when things change | 20:35 |
| johnpur | jmckenty: you guys are working against cactus? | 20:35 |
| vishy | if 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 |
| vishy | i think that is totally reasonable | 20:35 |
| jbryce | vishy: +1 | 20:35 |
| vishy | then the core teams can figure out how they will solve that requirement | 20:35 |
| sandywalsh | freeze on sprints, not on releases | 20: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 openstack | 20:35 |
| vishy | devcamcar_: because we don't own it. | 20:35 |
| jbryce | which is again one of the 2 primary things the proposal addresses--push what the API can do under the PTL/project team | 20:36 |
| sandywalsh | devcamcar, because that's not our motivation (speaking for our team at least) | 20:36 |
| *** dprince has quit IRC | 20:36 | |
| devcamcar_ | sandywalsh: what is your movitation? | 20:37 |
| sandywalsh | devcamcar, other functionality, not ec2 compatibility | 20:37 |
| sandywalsh | devcamcar, if that's someone's priority, someone should start coding it | 20:37 |
| devcamcar_ | sandywalsh: on whose behalf are you speaking? | 20:37 |
| jmckenty | Someone would, if the API supported it :p | 20:38 |
| sandywalsh | heh, no one ... just me :) | 20:38 |
| _0x44 | sandywalsh: Floating IPs aren't a priority for Ozone? | 20:38 |
| jbryce | sandywalsh: you are pointing out the problem | 20: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 api | 20:38 |
| sandywalsh | I code what I'm told to code | 20:38 |
| devcamcar_ | the code is there, why not have the api represent it? | 20:38 |
| jbryce | sandywalsh: 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 currently | 20:38 |
| jmckenty | So if I'm clear - if I need a change to the nova API to expose existing functionality, Vishy can approve that? | 20:38 |
| jbryce | jmckenty: correct | 20:39 |
| vishy | jbryce: 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 PPB | 20:39 |
| *** jaypipes has joined #openstack-meeting | 20:39 | |
| jmckenty | 2 +1 | 20:39 |
| vishy | jbryce: then we can discuss how 2 happens if it is actually voted on. | 20:39 |
| jmckenty | but "oversight" should be direct conversation whenever possible, IMO | 20:39 |
| jorgew | At anytime, features can be exposed through the API — as core features which require PPL apporval — or as extensions which don't. | 20:40 |
| jbryce | vishy: this is what i've been trying to say the whole meeting. = ) | 20:40 |
| sandywalsh | devcamcar, just a matter of prioritization ... it isn't the priority currently. Perhaps it should be? | 20:40 |
| *** mandell has joined #openstack-meeting | 20:40 | |
| jbryce | we 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 suggested | 20:41 |
| vishy | jbryce: 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 months | 20: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 extensions | 20:41 |
| jmckenty | jaypipes is here now | 20:41 |
| jmckenty | we have quorum | 20:41 |
| jbryce | ttx left | 20:41 |
| jmckenty | ah, right | 20:41 |
| jorgew | My proposal is 2! | 20:41 |
| sandywalsh | devcamcar, not sure the importance of it being an extension or not? | 20:41 |
| * jaypipes needs to read through a log. | 20:42 | |
| jorgew | Though I should probably be reworded somewhat. | 20:42 |
| jbryce | jorgew: i think we should tweak wording | 20:42 |
| jmckenty | sandywalsh: extensions aren't guaranteed to be in any specific distro | 20:42 |
| sandywalsh | ah, gotcha | 20:42 |
| *** jsavak has quit IRC | 20:42 | |
| jorgew | jbryce: for sure | 20:42 |
| jmckenty | they essentially lead to standards proliferation | 20:42 |
| notmyname | so 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 issue | 20:42 |
| * notmyname is being dense | 20:42 | |
| sandywalsh | devcamcar, I see your point | 20: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 extension | 20:43 |
| jmckenty | Hey, as long as we're clear that project PTLs own APIs, | 20:43 |
| jaypipes | would someone please summarize #1 and #2 for me. apologies for tardiness. | 20:43 |
| devcamcar_ | notmyname: it's a fair point | 20:43 |
| creiht | I would also point out that jorgew's proposal is not #2, it is a possible implementation of #2 | 20:43 |
| jmckenty | we can sort out the API standards with bourbon and beatings | 20:43 |
| jbryce | notmyname: there are multiple openstack api's notmyname | 20:43 |
| sandywalsh | devcamcar, because that's the sandbox we've been given to play in. | 20:43 |
| johnpur | devcamcar: agree. we should be able to code a dashboard that runs solely against the OS API(s). | 20:43 |
| sandywalsh | we can't go outside our sandbox | 20:43 |
| vishy | notmyname: there is also keystone and soon quantum | 20:43 |
| jmckenty | we can now | 20:43 |
| devcamcar_ | johnpur: we have | 20:43 |
| jbryce | an 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 |
| notmyname | vishy: indeed | 20:44 |
| devcamcar_ | johnpur: new dashboard is OS API only | 20:44 |
| devcamcar_ | maybe it makes more sense to call it OpenStack Compute API and OpenStack Storage API? | 20:44 |
| vishy | creiht: +1 | 20:44 |
| notmyname | devcamcar_: +1 | 20:44 |
| johnpur | awesome, we are a bit behind, and need to use some ec2 calls to fill out all the functionality | 20:44 |
| notmyname | devcamcar_: otherwise who knows what you're talking about :-) | 20:44 |
| jbryce | notmyname: we are talking about all of them | 20: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 up | 20:45 |
| sandywalsh | extensions should only be mandatory when extending a frozen version | 20:45 |
| jmckenty | And frozen happens at release dates, yes? | 20:46 |
| jmckenty | or at milestones | 20:46 |
| johnpur | devcamcar: looking forward to syncing to Diablo final and seeing how you use the API and integrate with Keystone | 20:46 |
| sandywalsh | or sprint dates | 20:46 |
| sandywalsh | yea | 20: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 core | 20:46 |
| vishy | jmckenty, sandywalsh, if we get the vote out of the way (next week), then we are free to decide how to do that | 20:46 |
| jorgew | sandywalsh: I can see where that rule can apply — but there be reasons other than this for extensions. | 20:46 |
| sandywalsh | jorgew, such as? | 20:47 |
| zns | jmckenty: 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 |
| notmyname | jbryce: 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 |
| jmckenty | sure, extensions are for features that aren't supported in all drivers | 20:47 |
| jmckenty | sandywalsh: ==^ | 20:47 |
| devcamcar_ | jmckenty: +1 | 20:47 |
| jmckenty | e.g., Xen-specific | 20:47 |
| jbryce | notmyname: that is one of the issues, yes | 20:47 |
| jorgew | sandy: Take Atlas, some features work in Zeus but not Citrix — those end up as extensions | 20:47 |
| jorgew | right | 20:47 |
| jmckenty | jorgew: Atlas is OT in here, sorry | 20:48 |
| jmckenty | it's not proposed for incubation yet | 20:48 |
| jorgew | Understood... | 20:48 |
| jorgew | Same thing with keystone though | 20:48 |
| jmckenty | no | 20:49 |
| *** Tushar has joined #openstack-meeting | 20:49 | |
| sandywalsh | jmckenty, my interpretation of extensions was "the API is blessed, all other stuff will be done as extensions" | 20:49 |
| jmckenty | keystone was accepted to core | 20:49 |
| vishy | sandywalsh: also extensions for vendor specific deployments that aren't shipped in nova core | 20:49 |
| jmckenty | right? | 20:49 |
| sandywalsh | vishy, makes sense ... but then there's the distro issue, as mentioned above | 20:49 |
| jbryce | jmckenty: jorgew is saying it's the same situation with keystone where different auth backends have different features exposed through extensions | 20:49 |
| vishy | sandywalsh: I would like 3rd parties to be able to supply extension/scheduler/driver and have their third party code run | 20:49 |
| *** mandell has quit IRC | 20:49 | |
| jorgew | sady: PTL decides what's an extension or not — end of story…however, should accunt for backend drivers user requirements, maturity etc | 20:50 |
| vishy | sandywalsh: they can supply their own packages etc. | 20:50 |
| jmckenty | zns: +1 for PTL defining freeze dates, as long as it's a) published, and b) in sync with other projects whenever possible | 20:50 |
| notmyname | so what problems remain when the API definition is controlled by the PTL/devs? | 20:50 |
| jmckenty | notmyname: I think guidelines are still a good idea | 20:50 |
| *** nati has joined #openstack-meeting | 20:50 | |
| vishy | notmyname: guidelines for consistency | 20:50 |
| *** mandell has joined #openstack-meeting | 20:50 | |
| sandywalsh | so, the argument of extensions being bad for distro reasons doesn't sound like such a big deal. | 20:50 |
| jmckenty | e.g., so that it's clear what should be an extension | 20:50 |
| zns | correct. 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 |
| johnpur | devilish consistency | 20:50 |
| jmckenty | sandywalsh: the argument is just that essentially (logically) CORE features shouldn't be extensions | 20:51 |
| sandywalsh | logically | 20:51 |
| notmyname | jmckenty: vishy: guidelines are a noble goal. but the details of them are very important | 20:51 |
| jorgew | notmyname: And the forward looking draft that users can look at and comment on is important | 20:51 |
| sandywalsh | jmckenty, but practically, no biggue | 20:51 |
| jmckenty | jorgew: I think that's a very different idea | 20:51 |
| sandywalsh | biggie | 20:51 |
| notmyname | jorgew: no. | 20:51 |
| jmckenty | don't try and conflate that | 20:51 |
| vishy | notmyname: 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 them | 20:51 |
| jorgew | jmckenty: Explain? | 20:52 |
| jmckenty | vishy: I'm the reverse | 20:52 |
| sandywalsh | jorgew, should draft = extension, later to be rolled into core? | 20:52 |
| jmckenty | I'd much rather define them now than assign that responsibility to someone | 20:52 |
| vishy | jmckenty: we can't define them until we've decided who owns them | 20:52 |
| jmckenty | sandywalsh and jorgew: no | 20:52 |
| sandywalsh | jorgew, vs. document | 20:52 |
| jmckenty | PPB owns them | 20:52 |
| jbryce | that's what vishy is talking about | 20:52 |
| vishy | jmckenty: good so we need to vote on that so it is documented | 20:53 |
| annegentle | I'd prefer that specs don't live on docs.openstack.org, the precedence set is that spec work is on the wiki. | 20:53 |
| jaypipes | jmckenty: the guidelines, right? not the APIs themselves? sorry if I'm late to the convo... | 20:53 |
| jorgew | sandywalsh: 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 PTL | 20:53 |
| jmckenty | jorgew: collecting info for roadmap of features (+/- user feedback to API style, etc) shouldn't be conflated with the rest of this discussion | 20:53 |
| annegentle | that's my only feedback after reading jorgew's proposal | 20:53 |
| jmckenty | jaypipes: right, the guidelines only | 20:53 |
| notmyname | I 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 VP | 20:53 |
| jaypipes | k | 20:53 |
| jaypipes | jbryce: is there a voteable item here? | 20:54 |
| jmckenty | Can I propose that everyone in the PPB hack on http://etherpad.openstack.org/HACKING-txt | 20:54 |
| vishy | options 1) project owns apis + guidelines 2) project owns apis, ppb owns guidelines 3) ppb owns apis and guidelines | 20:54 |
| jbryce | jaypipes: not today | 20:54 |
| jmckenty | and that we vote on that as guidelines next week? | 20:54 |
| jmckenty | jaypipes: we're short a quorum | 20:54 |
| jaypipes | jbryce: k, thx | 20:54 |
| annegentle | I'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 |
| sandywalsh | as 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 |
| vishy | if 2 wins we can define what the guidelines are | 20:54 |
| jorgew | jmckenty: How are useres supposed to have discussions about the API as a whole? | 20:54 |
| annegentle | Just want to be API user advocate. | 20:54 |
| jmckenty | jorgew: why would users ever have discussions about an API instead of about the system? | 20:55 |
| jmckenty | again, it's a separate issue | 20:55 |
| *** salv has joined #openstack-meeting | 20:55 | |
| jmckenty | jbryce: how did we do about doing this in 10 minutes? | 20:56 |
| jmckenty | :p | 20:56 |
| creiht | users are not likely to have much input on anything until they can actually use it | 20:56 |
| jbryce | haha | 20:56 |
| johnpur | jmckenty: s/users/devs | 20:56 |
| jmckenty | right, 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 |
| jbryce | creiht: 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 |
| jmckenty | sandywalsh: if it's an extension, it's dangerous for people to build anything that depends on it | 20:57 |
| jorgew | jmkckenty: Sorry by users I mean operators, vendors… the API is important to them because it's a product for them | 20:57 |
| jmckenty | sandywalsh: unless they control the deployment | 20:57 |
| vishy | sandywalsh: it will still need review to get promoted into core | 20:57 |
| sandywalsh | vishy, what if I don't care if it makes it into core? that's someone else's concern | 20:58 |
| vishy | sandywalsh: and core means we're obligated to not break it | 20:58 |
| *** jrouault has joined #openstack-meeting | 20:58 | |
| jmckenty | jorgew: 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 specs | 20:58 |
| notmyname | jbryce: so this isn't actually a meeting, right? because we have no quorum | 20:58 |
| jorgew | jmckenty: An extension can gain tracktion if it supports a feature users want. | 20:58 |
| jbryce | notmyname: it's a non-binding meeting. = ) | 20:58 |
| sandywalsh | vishy, users can call POST /foo and know it's going to work | 20:58 |
| jorgew | jmckenty: The API is where users, vendors, devs, etc meet — it's a common interface — it's a great place to engage the community etc | 20:59 |
| jmckenty | jorgew: that's architect's nonsense. | 20:59 |
| vishy | sandywalsh: we have no contracts on extensions... | 20:59 |
| notmyname | jorgew: jmckenty: but you still haven't solve the issue of communicating the needs from users to devs. | 20:59 |
| notmyname | it comes down to people talking | 20:59 |
| notmyname | interested parties | 20:59 |
| vishy | sandywalsh: core just means we're committed to supporting it/not breaking it | 20:59 |
| jbryce | our time is up | 20:59 |
| vishy | sandywalsh: so if a user doesn't care about that, they can surely build on top of extensions | 21:00 |
| sandywalsh | vishy, gotcha ... so it's always best to code as an extension (which may not, actually, be a bad thing) | 21:00 |
| creiht | just because you don't have a spec, doesn't mean outsiders don't have input... patches are always welcome :) | 21:00 |
| vishy | sandywalsh: i think most people will | 21:00 |
| jbryce | #endmeeting | 21:00 |
| jorgew | jmckenty: The process is working with other projects where users, vendors, and devs get together to sort out what will be on the API | 21:00 |
| *** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/" | 21:00 | |
| openstack | Meeting ended Tue Aug 30 21:00:30 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:00 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-20.03.html | 21:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-20.03.txt | 21:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-20.03.log.html | 21:00 |
| sandywalsh | jbryce, haha | 21:00 |
| zns | creiht: not all users are developers. | 21:00 |
| *** liemmn has joined #openstack-meeting | 21:00 | |
| sandywalsh | nice | 21:00 |
| vishy | and here comes the other meeting | 21:00 |
| *** danwent has joined #openstack-meeting | 21:00 | |
| vishy | #startmeeting | 21:00 |
| openstack | Meeting started Tue Aug 30 21:00:48 2011 UTC. The chair is vishy. Information about MeetBot at http://wiki.debian.org/MeetBot. | 21:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic. | 21:00 |
| pvo | keep going? | 21:00 |
| *** pem has joined #openstack-meeting | 21:00 | |
| *** troytoman-away is now known as troytoman | 21:00 | |
| * vishy is channeling ttx | 21:01 | |
| pvo | I'm not sure we reached any kind of consensus there | 21:01 |
| jmckenty | agenda? | 21:01 |
| vishy | welcome to the release meeting | 21:01 |
| vishy | :) | 21:01 |
| jmckenty | there's no consensus | 21:01 |
| *** pem is now known as Guest23118 | 21:01 | |
| carlp | ooh, exciting | 21:01 |
| pvo | where then, does this get resolved? | 21:01 |
| jbryce | pvo, jmckenty: there was concensus on a couple of points. we can work on the rest later | 21:01 |
| vishy | notmyname, still here? | 21:01 |
| notmyname | yes | 21:01 |
| *** rohitagarwalla has joined #openstack-meeting | 21:01 | |
| *** Vek has joined #openstack-meeting | 21:01 | |
| vishy | #topic swift status | 21:02 |
| *** openstack changes topic to "swift status" | 21:02 | |
| vishy | any updates? | 21:02 |
| pvo | jbryce: I'm not sure we want to drag this out longer. | 21:02 |
| notmyname | we're finishing up our next release | 21:02 |
| notmyname | swift 1.4.3 will be the diablo release | 21:02 |
| notmyname | if you want something in it, make your merge proposal soon | 21:03 |
| notmyname | as in tonight, if possible | 21:03 |
| notmyname | I'll be in SF next week for a meetup. http://www.meetup.com/openstack/events/30605231/ | 21:03 |
| notmyname | I think that's about it | 21:03 |
| *** tsuzuki_ has joined #openstack-meeting | 21:03 | |
| vishy | questions for the swift PTL? | 21:04 |
| *** hisaharu has joined #openstack-meeting | 21:04 | |
| vishy | i'll take that as a no | 21:04 |
| vishy | #topic Glance Status | 21:04 |
| *** openstack changes topic to "Glance Status" | 21:04 | |
| vishy | jaypipes: ping | 21:04 |
| jaypipes | vishy: https://launchpad.net/glance/+milestone/diablo-rbp | 21:05 |
| jaypipes | vishy: we got D4 out the door with most of the targeted BPs and bugs... | 21:05 |
| jaypipes | vishy: 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,z | 21:05 |
| jaypipes | vishy: other than that, working with a number of folks on QA/testing efforts, but no Glance-specific updates. | 21:06 |
| vishy | good deal | 21:07 |
| vishy | questions for the glance ptl? | 21:07 |
| glenc | o/ | 21:07 |
| *** jmckenty has quit IRC | 21:07 | |
| jaypipes | glenc: shoot | 21:07 |
| glenc | jaypipes, what is blocking the protected-properties BP? | 21:07 |
| glenc | https://blueprints.launchpad.net/glance/+spec/protected-properties | 21:08 |
| jaypipes | glenc: the functional tests for keystone and client integration: | 21:08 |
| jaypipes | https://review.openstack.org/333 | 21:08 |
| jaypipes | https://review.openstack.org/350 | 21:08 |
| glenc | gotcha - once that's done, we (or someone else) can begin work on that? | 21:08 |
| jaypipes | if folks can hop on to those reviews, that would unblock it. | 21:08 |
| jaypipes | glenc: yes sir! | 21:08 |
| glenc | thank you | 21:08 |
| jaypipes | np | 21:08 |
| vishy | any more questions for jaypipes | 21:09 |
| vishy | ? | 21:09 |
| vishy | ok, moving on | 21:09 |
| jaypipes | glenc: also, if you could get me a highball glass, rocks, and scotch, that might help. | 21:09 |
| vishy | #topic Nova Status | 21:09 |
| *** openstack changes topic to "Nova Status" | 21:09 | |
| * vishy switches hats | 21:09 | |
| glenc | Laphroaig or Lagavulin? | 21:09 |
| jaypipes | glenc: anything. | 21:10 |
| vishy | We got a lot of features into D4, but we now have a huge buglist | 21:10 |
| vishy | and a lot of stuff under review | 21:10 |
| vishy | I've started targeting bugs to rbp | 21:10 |
| vishy | https://launchpad.net/nova/+milestone/diablo-rbp | 21:10 |
| *** msinhore has quit IRC | 21:11 | |
| vishy | I know that all of the developers have plenty of internal team milestones, but we all need to band together to make diablo a success | 21:11 |
| vishy | There are two critical bugs that need to be addressed. I would really like a volunteer for each of these: | 21:11 |
| vishy | https://bugs.launchpad.net/bugs/833552 | 21:11 |
| uvirtbot | Launchpad bug 833552 in nova "No easy migration from old auth to keystone" [Critical,Triaged] | 21:11 |
| vishy | https://bugs.launchpad.net/bugs/834189 | 21:12 |
| uvirtbot | Launchpad bug 834189 in nova "XenServer and KVM handle local storage differently" [Critical,Triaged] | 21:12 |
| pvo | vishy: re 833, difficulty? We need this too. | 21:12 |
| vishy | the 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 Diablo | 21:12 |
| vishy | as far as i'm concerned, we can't ship diablo without these solved | 21:12 |
| *** tsuzuki_ has quit IRC | 21:12 | |
| pvo | "not easy" from the bug, but how long would you guess if you were working it? | 21:12 |
| vishy | pvo: I don't think it is hard, i think it is a script using auth manager that talks to keystone-manage | 21:13 |
| *** ddutta has joined #openstack-meeting | 21:13 | |
| jaypipes | vishy: could you elaborate why the inconsistency b/w the disk setup is a critical bug? | 21:13 |
| vishy | the trick is making sure it works and updating it since keystone is changing a lot | 21:13 |
| jaypipes | vishy: I'm just curious, is all... | 21:13 |
| vishy | jaypipes: I think it is a huge defect to have images work completely differently between our to main hypervisors | 21:14 |
| vishy | * two | 21:14 |
| zns | vishy: you'd need both Nova and Keystone installed on the same machine (keystone-manage doesn't use the REST API). Just fyi... | 21:14 |
| vishy | zns: good point, it should probably use the rest api | 21:14 |
| zns | vishy: keystone-manage shouldn't change that much... | 21:14 |
| zns | it's the API that is changing mostly. | 21:14 |
| vishy | zns: or you could just install nova to run the script on the keystone machine | 21:14 |
| vishy | zns: anyway we need something | 21:15 |
| jaypipes | vishy: 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 |
| pvo | vishy: ant and I will take a stab at that. | 21:15 |
| pvo | we're blocked on it | 21:15 |
| vishy | jaypipes: no, it is arbitrary | 21:15 |
| jaypipes | vishy: k, good to know. thx | 21:15 |
| vishy | pvo: nice | 21:15 |
| vishy | pvo: the other one will need to include your team | 21:15 |
| vishy | I will start a mailing list discussion on the other one | 21:16 |
| pvo | vishy: yes, will coordinate on it. | 21:16 |
| pvo | vishy: sounds good | 21:16 |
| zns | pvo: if you handle the nova side, we can commit to update the script if we change keystone... | 21:16 |
| vishy | and I'll assign the auth one to you | 21:16 |
| pvo | zns: its a deal | 21:16 |
| vishy | zns great: | 21:16 |
| pvo | vishy: just assigned to myself | 21:16 |
| vishy | #action vishy to email the list about the other critical bug and request help on reviews and bug fixing | 21:16 |
| zns | * wondering if he should have just stayed quiet * | 21:16 |
| *** somik has joined #openstack-meeting | 21:16 | |
| vishy | so all teams please test/install/report bugs/fix bugs/write tests | 21:17 |
| nati | gotcha | 21:17 |
| vishy | lets not repeat the cactus release where we obsoleted it two weeks after the release | 21:17 |
| vishy | questions for the nova ptl? | 21:17 |
| hisaharu | other bugs can not be merged in diablo-rdp? | 21:18 |
| zns | pvo: cool. Lemme know when you have it (and where) and I'll follow the changes dolphm is doing. | 21:18 |
| comstud | vishy: 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 |
| vishy | hisaharu: any bug can be fixed. | 21:18 |
| hisaharu | vishy: ok | 21:18 |
| comstud | vishy: (merge prop about to go back into 'needs review') | 21:18 |
| vishy | comstud: 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 |
| comstud | vishy: sounds good | 21:19 |
| vishy | in other words I have no problem with it going in as a second option, but primary option sounds scary | 21:19 |
| nati | could you add bug 835919 for RBP? we are working | 21:19 |
| uvirtbot | Launchpad bug 835919 in nova "Single default gateway should be offered to VM on multi-NICs environment." [Undecided,New] https://launchpad.net/bugs/835919 | 21:19 |
| comstud | vishy: 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 |
| comstud | vishy: safer than kombu as primary for now..i agree | 21:20 |
| vishy | nati: done | 21:20 |
| *** mdomsch has quit IRC | 21:20 | |
| nati | thanks! | 21:20 |
| vishy | comstud: cool get that merge in | 21:20 |
| comstud | vishy: will do | 21:20 |
| comstud | having a flags issue right now :-/ | 21:20 |
| vishy | in general, I don't mind extensions going in as well as long as they don't tmess with underlying code too much | 21:20 |
| comstud | seems to not be obeying rpc_backend in all cases | 21:20 |
| comstud | and always loading default | 21:20 |
| vishy | any more questions? | 21:20 |
| vishy | comstud: hehe, uh oh :) | 21:20 |
| comstud | yeah | 21:21 |
| comstud | might need to use LazyPluggable like db code | 21:21 |
| vishy | comstud ping me offline if you need another set of eyes. | 21:21 |
| comstud | we'll see. anyway.. :) carry on | 21:21 |
| comstud | will do | 21:21 |
| vishy | #topic Incubated Project Status | 21:21 |
| *** openstack changes topic to "Incubated Project Status" | 21:21 | |
| vishy | zns: updates? | 21:21 |
| vishy | devcamcar_: are you still here? | 21:22 |
| zns | Accepted to core (no longer incubated?) | 21:22 |
| danwent | quantum: we dropped D4, are working on bug fixes for diablo-rbp | 21:22 |
| devcamcar_ | vishy: yep yep | 21:22 |
| danwent | quantum: main focus moving forward will be stabilization and documentation :) | 21:22 |
| annegentle | yay docs! | 21:22 |
| zns | Changes were bigger than expected. | 21:22 |
| zns | Latest code (not reviewed, not yet passing tests, but there just to share with others): https://review.openstack.org/#change,342 | 21:22 |
| vishy | zns: yeah I don't know if you get your own slot until diablo time, but I suppose it doesn't matter either way | 21:22 |
| zns | APIs are published,m though: | 21:23 |
| zns | Full API: https://github.com/openstack/keystone/blob/d349b349c50e0683432f5ae843bd2dc83599c1b6/keystone/content/admin/identityadminguide.pdf?raw=true | 21:23 |
| zns | Service API: https://github.com/openstack/keystone/blob/master/keystone/content/service/identitydevguide.pdf?raw=true | 21:23 |
| zns | That review *should* be merged in by end of week (although we had said that last week). | 21:23 |
| zns | Any questions? | 21:23 |
| vishy | questions for Keystone PTL? | 21:23 |
| vishy | :) | 21:23 |
| vishy | devcamcar_: any updates on the project formerly known as dashboard? | 21:24 |
| annegentle | For 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 novaclient | 21:25 |
| annegentle | http://docs.openstack.org/incubation/identity-dev-guide/content/ | 21:25 |
| zns | annegentle: thank you :-) | 21:25 |
| devcamcar_ | quantum support has almost landed as well | 21:25 |
| danwent | woohoo :) | 21:25 |
| devcamcar_ | just waiting on a few units tests to get added to the branch and then we can merge it in | 21:25 |
| vishy | nice | 21:25 |
| markvoelker | devcamcar_ I think they're in and waiting your review? | 21:25 |
| vishy | devcamcar_: any progress on packaging? | 21:26 |
| devcamcar_ | markvoelker: odd, i didn't get notified, i will look again | 21:26 |
| markvoelker | devcamcar_: https://github.com/4P/openstack-dashboard/pull/92 | 21:26 |
| devcamcar_ | vishy: we are able to push to pypi so you can pip install django-openstack portion at least | 21:26 |
| devcamcar_ | there is some debate around what it means to "package" a django site though | 21:26 |
| vishy | devcamcar_: I'd love to be able to apt-get bourbon | 21:27 |
| vishy | devcamcar_: 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 yet | 21: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 dashboard | 21:28 | |
| devcamcar_ | medberry: nice :) | 21:29 |
| vishy | other questions for Dash ptl? | 21:29 |
| glenc | "sandwich" as in "apt-get sandwich" oops "sudo apt-get sandwich" | 21:29 |
| vishy | glenc: wouldn't me-a-sandwich be better for that? | 21:29 |
| glenc | :D | 21:30 |
| vishy | apt-get me-a-sandwich | 21:30 |
| vishy | ok danwent, anything else on quantum? | 21:30 |
| danwent | sorry for jumping in before, didn't realize this was so structured :) | 21:30 |
| danwent | only other thing to add is that we continue to work on nova integration | 21:30 |
| vishy | danwent: ttx is much better at this than me :) | 21:30 |
| danwent | if any nova core devs are available to review the quantum-manager branch, it would be much appreciated | 21:31 |
| danwent | that's about it | 21:31 |
| vishy | danwent: is that the last piece needed for diablo? | 21:31 |
| danwent | https://code.launchpad.net/~danwent/nova/qmanager-new | 21:31 |
| danwent | yup | 21:31 |
| pvo | danwent: we're lining up to look at it today. | 21:31 |
| pvo | we've had a few guys out. | 21:32 |
| danwent | pvo: thanks! | 21:32 |
| vishy | looks like rick just gave you a review | 21:32 |
| vishy | as well :) | 21:32 |
| pvo | jk0 and tr3buch3t have been ETO | 21:32 |
| danwent | should have kept refreshing the page i guess :P | 21:32 |
| devcamcar_ | quantum dashboard support just landed ;) | 21:33 |
| danwent | keep refreshing :) | 21:33 |
| markvoelker | devcamcar_: w00t! | 21:33 |
| vishy | danwent: also, some networks are created in fixtures (see nova/tests/__init__.py which might explain why you were seeing that issue with associate_pool | 21:33 |
| vishy | questions for quantum ptl? | 21:33 |
| danwent | vishy: thanks, yes, i tracked it down to some fixed IPs created with null networks in test_compute… should be working now | 21:33 |
| vishy | ok then | 21:34 |
| vishy | #topic General Discussion | 21:34 |
| *** openstack changes topic to "General Discussion" | 21:34 | |
| vishy | anyone have anything? | 21:34 |
| vishy | ok then | 21:35 |
| vishy | #endmeeting | 21:35 |
| *** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/" | 21:35 | |
| openstack | Meeting ended Tue Aug 30 21:35:19 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:35 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-21.00.html | 21:35 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-21.00.txt | 21:35 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-21.00.log.html | 21:35 |
| glenc | Great meeting, vishy | 21:35 |
| vishy | thx glenc | 21:35 |
| *** edgarmagana has joined #openstack-meeting | 21:36 | |
| *** rnirmal has quit IRC | 21:37 | |
| *** hisaharu has left #openstack-meeting | 21:37 | |
| *** Vek has left #openstack-meeting | 21:38 | |
| *** Guest23118 has quit IRC | 21:41 | |
| *** devcamcar_ has left #openstack-meeting | 21:44 | |
| *** devcamcar_ has quit IRC | 21:44 | |
| *** nati has quit IRC | 21:46 | |
| *** nati has joined #openstack-meeting | 21:46 | |
| *** edconzel has quit IRC | 21:48 | |
| *** edconzel has joined #openstack-meeting | 21:48 | |
| *** nati has quit IRC | 21:51 | |
| *** Tushar has quit IRC | 21:52 | |
| *** ryu_ishimoto has joined #openstack-meeting | 21:53 | |
| *** Jamey has joined #openstack-meeting | 21:59 | |
| *** liemmn has quit IRC | 22:00 | |
| danwent | ok, hello net stackers…. not usual that we have so so much time between the main meeting and this one | 22:00 |
| danwent | maybe it was because vish runs speedy meetings :) | 22:00 |
| *** ying has joined #openstack-meeting | 22:01 | |
| salv | hello dan | 22:01 |
| markvoelker | o/ | 22:01 |
| edgarmagana | hi everybody! | 22:01 |
| danwent | #startmeeting | 22:01 |
| openstack | Meeting started Tue Aug 30 22:01:50 2011 UTC. The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot. | 22:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic. | 22:01 |
| rohitagarwalla | o/ | 22:01 |
| danwent | agenda: http://wiki.openstack.org/Network/Meetings | 22:01 |
| somik | o/ | 22:02 |
| *** SumitNaiksatam has joined #openstack-meeting | 22:02 | |
| ddutta | :) | 22:02 |
| danwent | #topic general status | 22:02 |
| *** openstack changes topic to "general status" | 22:02 | |
| danwent | don't' forget to sign up for openstack essex summit : http://wiki.openstack.org/Summit/Essex | 22:02 |
| danwent | is troy around? | 22:02 |
| *** Jamey has quit IRC | 22:03 | |
| danwent | ddutta mentioned that there's not donate update today, but they're hoping for an API spec writeup very soon | 22:03 |
| danwent | ok, will skip melange for now. we can circle back. | 22:03 |
| danwent | #topic quantum | 22:03 |
| *** openstack changes topic to "quantum" | 22:03 | |
| danwent | so we're now past "feature freeze" | 22:04 |
| *** shwetaap has joined #openstack-meeting | 22:04 | |
| ddutta | next week for sure! | 22:04 |
| danwent | which means the only things that should be dropping into trunk should be bug fixes and tests. | 22:04 |
| *** Jamey has joined #openstack-meeting | 22:04 | |
| danwent | now is the time to really be testing all of your use cases and make sure they are working…. | 22:04 |
| danwent | Sept 10th is "release branch point" release, after which only serious bugs will be committed on the branch. | 22:05 |
| danwent | any questions/thoughts? | 22:05 |
| danwent | currently, anyone can assign a bug to diablo-rbp... | 22:05 |
| danwent | https://launchpad.net/quantum/+milestone/diablo-rbp | 22:05 |
| troytoman | o/ | 22:05 |
| salv | We should try not to have unassigned bugs on rbp milestone at this stage | 22:05 |
| danwent | hey troy, can we circle back to melange in a bit, or do you have to run? | 22:05 |
| troytoman | i'll be here | 22:06 |
| danwent | troy: thx | 22:06 |
| danwent | particularly if they are high priority or above, which means they should be fixed before diablo-rbp | 22:06 |
| salv | I think if we cannot find takers by end of the week, we should probably untarget those bugs | 22:06 |
| danwent | salv: agreed. | 22:06 |
| danwent | right now I want to focus on getting things stable as quickly as possible. | 22:07 |
| danwent | We've done a good job of clearing out the merge pipeline… merges now should be simple and targeted. | 22:07 |
| danwent | so 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 |
| danwent | only two active reviews, since we got the cisco code merged: https://code.launchpad.net/quantum/+activereviews | 22:08 |
| salv | What should we do with the auth branch. Technically it is a feature, so we should delay it to Essex now. | 22:08 |
| danwent | salv's keystone branch is just waiting on final input from ziad | 22:08 |
| SumitNaiksatam | thanks Dan for the review and merge | 22:08 |
| danwent | salv: it has an exception, so technically it can go in, but we don't have client code that uses it | 22:09 |
| salv | But I'd say that it is a feature which can be easily turned off, so we should not worry about integration. | 22:09 |
| danwent | as far as I know, so I'm not sure there is much of a point of pushing it for diablo | 22:09 |
| salv | And, as Dan said, it has an exception :) | 22:09 |
| danwent | salv: yeah, I'm not worried… just wondering if it is useful until we modify the client lib | 22:09 |
| danwent | and I'd rather not mess with the client lib right now. | 22:09 |
| danwent | is anyone working on keystone support in the client lib? | 22:10 |
| salv | I don't think so. | 22:10 |
| danwent | #action #danwent create blueprint for keystone support in client lib… currently unassigned. | 22:10 |
| danwent | salv: I'm fine with it going if we can get it in the next few days | 22:10 |
| salv | I'm waiting for a reply from Ziad. | 22:11 |
| danwent | its pretty decoupled from everything else and is definitely a step toward where we want to be. | 22:11 |
| danwent | salv: 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 |
| somik | I agree, auth is pretty isolated adn can be easily turned off | 22:11 |
| *** jrouault has quit IRC | 22:11 | |
| danwent | code is already reviewed from a netstack-core perspective too, so its good to go once ziad looks at it. | 22:12 |
| salv | for 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 rbp | 22:12 |
| salv | I was talking about auth token in client library, of course | 22:12 |
| danwent | salv: I think is probably a bit much to address before rbp, unless we have someone volunteering to get it done ASAP…. | 22:12 |
| danwent | I want to minimize changes in areas that affect everyone, and the client lib affects a lot of people. | 22:12 |
| *** DZ has joined #openstack-meeting | 22:13 | |
| danwent | bug is fine, as I don't think there's a lot of design work to be done and written up in a blueprint | 22:13 |
| salv | Let'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 Guest75932 | 22:13 | |
| danwent | salve: sounds good. | 22:14 |
| *** Guest75932 has quit IRC | 22:14 | |
| danwent | ok, 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 |
| salv | Very good. | 22:15 |
| danwent | I 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 |
| salv | Weren't you already planning a change to nova-manage? | 22:15 |
| danwent | #action #danwent, create bug for utility to view vif-ids in nova | 22:15 |
| danwent | salv: 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 |
| salv | danwent: agreed. | 22:17 |
| danwent | Ok, sounds like heckj has a fix for the cheetah issue on the build system | 22:17 |
| heckj | danwent: yep - in and solved, Verified earlier today | 22:17 |
| danwent | and congrats to arvind and team…. the quantum dashboard work just got merged into dashboard! | 22:17 |
| salv | thank a lot heckj | 22:18 |
| *** zns has quit IRC | 22:18 | |
| danwent | heckj: much appreciated | 22:18 |
| salv | cheers to the GUI team | 22:18 |
| heckj | salv: sorry to leave it wait until today, I lost track from the weekend... | 22:18 |
| danwent | on quantum packaging.... | 22:18 |
| salv | heckj: np. That will teach us to think twice before adding a dependency | 22:18 |
| danwent | tyler 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 diablo | 22:19 |
| danwent | he will be sending an email out hopefully tomorrow about this. | 22:19 |
| danwent | if 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 |
| danwent | of course, we would make sure the new structure is available early for testing | 22:19 |
| danwent | any questions/thoughts on packaging? | 22:20 |
| danwent | Last point is documentation. I contacted Anne Gentle (lead of OpenStack packaging) about getting the ball rolling there. | 22:20 |
| *** dizhou has joined #openstack-meeting | 22:21 | |
| danwent | will 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 |
| danwent | Ok, anything else on quantum? | 22:21 |
| danwent | #topic open discussion | 22:21 |
| *** openstack changes topic to "open discussion" | 22:21 | |
| salv | Troy is still waiting... | 22:21 |
| danwent | ah, troy, can you talk about melange? | 22:21 |
| troytoman | sure. | 22:22 |
| danwent | salv: hehe, same thought | 22:22 |
| troytoman | most work is focused on addressing comments we got from the nova team. | 22:22 |
| troytoman | expect most of that work to be done this week. | 22:22 |
| danwent | troy: 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 |
| troytoman | otherwise we are working on getting it integrated with quantum so we can do some scale testing | 22:23 |
| troytoman | danwent: yes | 22:23 |
| troytoman | we are pushing updates there | 22:23 |
| danwent | great. I still need to test the QuantumManager with melange again before we really push it into nova... | 22:23 |
| troytoman | there are some areas where nova still gets IPs from it's DB | 22:23 |
| danwent | I tested it a while back, but there have been some changes. | 22:23 |
| troytoman | we will need to refactor those calls to go through the network manager. | 22:24 |
| danwent | great. | 22:24 |
| troytoman | haven't sorted out exactly how/who to do that yet but should figure that out this week as well | 22:24 |
| troytoman | we have moved several things in the openstack-commons | 22:24 |
| troytoman | we will probably propose to change quantum to leverage some of those common elements as well | 22:25 |
| *** ying has quit IRC | 22:25 | |
| troytoman | but, we are getting that code finalized before sorting that out | 22:25 |
| *** ying has joined #openstack-meeting | 22:26 | |
| danwent | great. anything else? | 22:26 |
| troytoman | nope | 22:26 |
| danwent | #topic open discussion (for real this time) | 22:26 |
| *** openstack changes topic to "open discussion (for real this time)" | 22:26 | |
| danwent | not to jinx it, but this could be our shortest meeting ever :) | 22:26 |
| *** HowardRoark has quit IRC | 22:27 | |
| salv | Do you want me to start talking about random things :) | 22:27 |
| danwent | I was worried someone would do that! | 22:27 |
| danwent | ok, thanks folks! | 22:27 |
| danwent | #endmeeting | 22:27 |
| *** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/" | 22:27 | |
| openstack | Meeting ended Tue Aug 30 22:27:32 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 22:27 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-22.01.html | 22:27 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-22.01.txt | 22:27 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-30-22.01.log.html | 22:27 |
| salv | Bye, have a good one! | 22:27 |
| edgarmagana | ciao | 22:27 |
| danwent | bye! | 22:27 |
| markvoelker | adios | 22:27 |
| *** Jamey has quit IRC | 22:27 | |
| *** markvoelker has left #openstack-meeting | 22:27 | |
| SumitNaiksatam | thanks, bye! | 22:27 |
| *** edgarmagana has quit IRC | 22:27 | |
| *** SumitNaiksatam has quit IRC | 22:28 | |
| *** markvoelker has joined #openstack-meeting | 22:28 | |
| *** ddutta has left #openstack-meeting | 22:29 | |
| *** mandell has left #openstack-meeting | 22:29 | |
| *** ryu_ishimoto has quit IRC | 22:32 | |
| *** shwetaap has left #openstack-meeting | 22:33 | |
| *** dizhou has quit IRC | 22:34 | |
| *** nati has joined #openstack-meeting | 22:40 | |
| *** mattray has quit IRC | 22:42 | |
| *** joearnold has quit IRC | 22:44 | |
| *** blamar has quit IRC | 22:44 | |
| *** notmyname has quit IRC | 22:44 | |
| *** termie has quit IRC | 22:44 | |
| *** RichiH has quit IRC | 22:44 | |
| *** comstud has quit IRC | 22:44 | |
| *** Daviey has quit IRC | 22:44 | |
| *** jeremyb has quit IRC | 22:44 | |
| *** antonym has quit IRC | 22:44 | |
| *** carlp has quit IRC | 22:44 | |
| *** cbeck has quit IRC | 22:44 | |
| *** Adri2000 has quit IRC | 22:44 | |
| *** zykes- has quit IRC | 22:44 | |
| *** bhall has quit IRC | 22:44 | |
| *** xtoddx has quit IRC | 22:44 | |
| *** jorgew has left #openstack-meeting | 22:44 | |
| *** danwent has left #openstack-meeting | 22:46 | |
| *** ryu_ishimoto has joined #openstack-meeting | 22:47 | |
| *** rohitagarwalla has quit IRC | 22:48 | |
| *** ryu_ishimoto has quit IRC | 22:48 | |
| *** johnpur has quit IRC | 22:53 | |
| *** joearnold has joined #openstack-meeting | 22:54 | |
| *** carlp has joined #openstack-meeting | 22:54 | |
| *** cbeck has joined #openstack-meeting | 22:54 | |
| *** Adri2000 has joined #openstack-meeting | 22:54 | |
| *** blamar has joined #openstack-meeting | 22:54 | |
| *** comstud has joined #openstack-meeting | 22:54 | |
| *** notmyname has joined #openstack-meeting | 22:54 | |
| *** termie has joined #openstack-meeting | 22:54 | |
| *** RichiH has joined #openstack-meeting | 22:54 | |
| *** zykes- has joined #openstack-meeting | 22:54 | |
| *** Daviey has joined #openstack-meeting | 22:54 | |
| *** bhall has joined #openstack-meeting | 22:54 | |
| *** jeremyb has joined #openstack-meeting | 22:54 | |
| *** xtoddx has joined #openstack-meeting | 22:54 | |
| *** antonym has joined #openstack-meeting | 22:54 | |
| *** edconzel has quit IRC | 22:56 | |
| *** joearnold has quit IRC | 23:03 | |
| *** blamar has quit IRC | 23:03 | |
| *** notmyname has quit IRC | 23:03 | |
| *** termie has quit IRC | 23:03 | |
| *** RichiH has quit IRC | 23:03 | |
| *** comstud has quit IRC | 23:03 | |
| *** Daviey has quit IRC | 23:03 | |
| *** jeremyb has quit IRC | 23:03 | |
| *** antonym has quit IRC | 23:03 | |
| *** carlp has quit IRC | 23:03 | |
| *** cbeck has quit IRC | 23:03 | |
| *** Adri2000 has quit IRC | 23:03 | |
| *** zykes- has quit IRC | 23:03 | |
| *** bhall has quit IRC | 23:03 | |
| *** xtoddx has quit IRC | 23:03 | |
| *** joearnold has joined #openstack-meeting | 23:05 | |
| *** carlp has joined #openstack-meeting | 23:05 | |
| *** cbeck has joined #openstack-meeting | 23:05 | |
| *** Adri2000 has joined #openstack-meeting | 23:05 | |
| *** blamar has joined #openstack-meeting | 23:05 | |
| *** notmyname has joined #openstack-meeting | 23:05 | |
| *** termie has joined #openstack-meeting | 23:05 | |
| *** RichiH has joined #openstack-meeting | 23:05 | |
| *** zykes- has joined #openstack-meeting | 23:05 | |
| *** Daviey has joined #openstack-meeting | 23:05 | |
| *** bhall has joined #openstack-meeting | 23:05 | |
| *** jeremyb has joined #openstack-meeting | 23:05 | |
| *** xtoddx has joined #openstack-meeting | 23:05 | |
| *** antonym has joined #openstack-meeting | 23:05 | |
| *** medberry is now known as med_out | 23:05 | |
| *** nati has quit IRC | 23:08 | |
| *** nati has joined #openstack-meeting | 23:09 | |
| *** novas0x2a|laptop has quit IRC | 23:13 | |
| *** nati has quit IRC | 23:13 | |
| *** HowardRoark has joined #openstack-meeting | 23:14 | |
| *** creiht has left #openstack-meeting | 23:17 | |
| *** novas0x2a|laptop has joined #openstack-meeting | 23:20 | |
| *** markvoelker has quit IRC | 23:22 | |
| *** salv has quit IRC | 23:26 | |
| *** heckj has quit IRC | 23:35 | |
| *** ohnoimdead has quit IRC | 23:40 | |
| *** nati has joined #openstack-meeting | 23:53 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!