19:59:59 <jbryce> #startmeeting
20:00:00 <openstack> Meeting started Tue Feb 14 19:59:59 2012 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:20 <ewanmellor> o/
20:00:28 <jbryce> roll call. who's here?
20:00:43 <johnpur> o/
20:00:46 <termie> o/
20:00:49 <danwent> o/
20:00:51 <ewanmellor> Red 1, standing by.
20:01:00 <jk0> \o
20:01:22 <anotherjesse> o/
20:01:29 <pvo> o--
20:02:00 <jaypipes> o/
20:02:01 <jbryce> so that's 6...will we get a 7th?
20:02:05 <jbryce> there we go
20:02:12 <jeblair> mtaylor is on his way
20:02:20 <zns> zns here
20:02:32 <jbryce> ok, we'll wait a couple of minutes
20:02:37 <mtaylor> o/
20:02:41 <jbryce> #topic Quantum core promotion
20:02:46 <jbryce> http://wiki.openstack.org/Projects/CoreApplication/Quantum
20:03:03 <jbryce> danwent updated the previous proposal with some updates from the incubation time period
20:03:52 <danwent> I think key take-away is that bleeding-edge openstack shops have already started using quantum to counter some of the key networking issues they are seeing.
20:04:17 <johnpur> I support the promotion... the project is being run well, is becoming a key target, and is supported by ttx from a release standpoint
20:04:24 <danwent> meanwhile, we've been making good progress toward integrating into openstack processes, thanks to folks like ttx, mtaylor, annegentle
20:05:31 <danwent> happy to answer questions / take comments.
20:05:31 <jbryce> danwent: it looks like a pretty good list of developers on there. how spread out are the actual volume of contributions?
20:05:33 <mtaylor> the quantum guys have been very responsive and have integrated well into the tooling
20:06:22 <anotherjesse> danwent: is the goal to phase out nova-network (being core would mean recommendation/requirement that openstack clouds use quantum instead of nova-network)?
20:06:23 <danwent> jbryce:  those are people who have contributed "regularly", though some from cisco team have had other responsibilities lately
20:06:26 <pvo> jbryce: we've been working closely with them, but I understand the implications there.
20:06:27 <johnpur> having a standardized networking set of layers will be key to getting to future states of federation, cross-cloud resource management, etc.
20:07:12 <danwent> I think there are very strong contribution already from cisco, citrix, nicira, and rackspace, as well as openstack infrastructure folks like monty and james blair
20:07:14 <pvo> anotherjesse: I understood the transition to be somewhat like auth was. Or should have been .
20:07:35 <danwent> anotherjesse:  have talked with vish about this.  he would like to evaluate whether we can rip out nova-network in folsom.
20:07:37 <anotherjesse> pvo: with diablo we deprecated the nova built-in auth and are removing in folsom
20:07:53 <danwent> I think doing so in 6-months will take a commitment from existing nova team members as well as quantum members though
20:07:56 <anotherjesse> pvo: err, removing in essex or folsom
20:08:29 <mtaylor> ++
20:08:36 <anotherjesse> danwent: a transition phase is great :)
20:08:42 <mtaylor> I do like the idea of having quantum in core _before_ we start that transition phase
20:09:03 <jbryce> danwent: what do you think the essex quantum release will look like. even though quantum won't be part of the core, i think we saw that with the timing of core promotions people expected the new projects to "just work" even if they aren't core for essex. i'd like to make sure we can set expectations properly
20:09:09 <johnpur> anotherjesse: agree on transition phase, the question is when
20:09:10 <danwent> anotherjesse: I agree. my main concern would be people trying to move to quickly to rip out nova-network.  we have a decent "half-and-half" strategy right now.
20:09:20 <jbryce> danwent: i know you guys have been following all the e milestones already
20:09:20 <anotherjesse> danwent: I'm primarily asking from an API perspective - if we remove/deprecate nova-network, users of openstack clouds could keep using the existing APIs and if they wanted richer network APIs could switch to using quantum directly?
20:09:25 <danwent> though half-and-half sucks long-term
20:09:52 <anotherjesse> danwent: kinda like how you can use "image-list" in nova (which calls out to glance), or if you need a richer API use glance directly
20:10:03 <pvo> anotherjesse: I was guess remove by or at folsom
20:10:14 <danwent> jbryce:  the targeted use case of driving network creation + port attachment (what is documented in our admin guide) should be solid for essex
20:10:16 <devcamcar> o/
20:11:15 <danwent> anotherjesse:  that's another thing I've been talking about with vish.  one model would be to let APIs like the ec2 API proxy to quantum for backward compat
20:11:21 <devcamcar> mtaylor: +1 to having quantum in core and then migrating
20:11:32 <danwent> anotherjesse: though new functionality would likely be exposed only via Quantum API.
20:11:45 <johnpur> danwent: +1
20:11:55 <devcamcar> +1
20:12:29 <danwent> anotherjesse:  yes, glance analogy is a good one.  In a sense, that is what we've done already, as you can drive quantum using nova-manage commands for creating networks.  Gives good backward compat.
20:12:38 <anotherjesse> mtaylor / devcamcar: I think we need to have a well documented plan of what existing nova network APIs will work in Folsom (or whenever quantum becomes core) with both quantum & nova-network
20:12:50 <mtaylor> anotherjesse: ++
20:13:16 <devcamcar> is the goal to have quantum replace all of the relevant nova-network pieces by folsom release?
20:13:43 <pvo> does quantum really mean quantum+melange?
20:13:43 <anotherjesse> devcamcar: core means it is a part of openstack, we've learned with keystone being half pregnant is harmful to developers and users
20:13:58 <mtaylor> I don't think we necessarily need to migrate by folsom - I thnk that's a call for vish - I just think that if we do migrate, all of the migration steps should be done once quantum is core
20:14:04 <mtaylor> what anotherjesse said
20:14:12 <mtaylor> pvo: good question ...
20:14:16 <danwent> devcamcar:  that is the goal long-term, but would need commitment from nova team to achieve it in such a short time frame
20:14:34 <mtaylor> danwent: can we accept quantum without accepting melange or should we be considering both?
20:14:35 * anotherjesse is texting vishy
20:14:51 * mtaylor should add an IRC-bot to SMS gateway...
20:14:53 <devcamcar> so probably by G release nova-network goes away and is fully replaced by quantum/melange would be my assumption
20:14:56 <pvo> another option is to merge them into a single project.
20:15:01 <danwent> pvo:  that's a good question.  I've been talking with troy about options for more closely coupling melange and quantum
20:15:02 <pvo> since they are intertwined.
20:15:26 <devcamcar> pvo: ideologically that would make sense - fewer boundaries and moving parts is always preferable to 200 different projects ...
20:15:44 <anotherjesse> devcamcar: having it so removal of nova-network can be done without any users having to know would be the issue
20:15:58 <danwent> devcamcar:  I would feel much more confident about G.  Not that I wouldn't love to do it by F, if enough people pitch in.
20:16:03 <devcamcar> anotherjesse: shudder
20:16:23 <danwent> devcamcar:  definitely from a tenant API perspective a closer coupling of quantum + melange makes sense.
20:16:45 <danwent> troy and I have chatted about this on several occassions.  Plan was to propose something concrete at F summit.
20:16:52 <devcamcar> melange becomes core in folsom or g?
20:16:52 <pvo> danwent: I might agree on your timeline for G, but would hope for F.
20:17:07 <jbryce> i talked to troy as well and i think it's probably a separate question from promotion for quantum itself
20:17:58 <pvo> jbryce: it may be, but it surely affects the timeline for integration
20:18:16 <pvo> if we take quantum but not melange that might be … interesting
20:18:28 <tr3buchet> fully replaced
20:18:58 <anotherjesse> danwert: I think it might be good to have a section on the details of the migration plan for nova-network.  my only concern with saying +1 to core is the question of what network APIs does an openstack cloud need to expose to be considered "openstack"
20:19:01 <johnpur> pvo: if that is true it argues for collapsing/integrating the projects
20:19:45 <devcamcar> anotherjesse: +1 - i'm not sure i've ever seen it articulated in detail.  i think i know, but maybe i dont know what i dont know :)
20:19:52 <danwent> anotherjesse:  right now a lot of the nova non-ec2 network apis are extensions, right?
20:20:05 <anotherjesse> danwent: it is already a little confusing, and I would prefer that we clean up our position on network APIs in nova (with and without quantum) instead making it more complicated (adding quantum to the mix without a definitive plan for transitions)
20:20:31 <tr3buchet> anotherjesse: +1
20:20:37 <pvo> anotherjesse: is network enough functionality to be standalone? Is that the question?
20:20:39 <anotherjesse> danwent: yep!  although they are on by default.  I know bcwaldon was hoping on removing the "extension" label in folsom
20:21:07 <jbryce> anotherjesse: is it worth delaying promotion to core another 6 months to have that laid out, or something that we should make a priority for the 6 months?
20:21:23 <danwent> Ok, from talking with vish I believe his plan is to be pretty aggressive about avoiding additional network capabilities in nova, assuming the long term plan is quantum.
20:21:28 <johnpur> can we get a clear design/go-forward plan in shape to discuss in SF?
20:21:47 <pvo> johnpur: ++
20:21:49 <danwent> I think so.  The key thing is that we need nova people on board as well as quantum people.
20:22:02 <anotherjesse> jbryce: I don't know if it will take 6 months - it could be that it is a relatively small task
20:22:13 <danwent> anotherjesse: I agree.
20:22:23 <pvo> anotherjesse: I think the hinge is melange
20:22:23 <anotherjesse> (most of) nova people want to move quantum, just want it to be orderly
20:22:32 <pvo> anotherjesse: maybe not though.
20:22:44 <pvo> I haven't tested splitting that functionality.
20:22:54 <danwent> pvo:  what functionality?
20:22:55 <anotherjesse> jbryce: when does the core vs. not decision need to happen?
20:22:58 <jbryce> since the promotion time windows are only pre-release every 6 months, then i'd be in favor of promoting it to core for folsom and marking out some these things as critical tasks to work on
20:23:00 <anotherjesse> (for folsom)
20:23:07 <jbryce> anotherjesse: next couple of weeks
20:23:09 <pvo> having nova manage ips and quantum manage networking
20:23:24 <pvo> without melange
20:23:27 <danwent> pvo:  this works already
20:23:27 <devcamcar> pvo: sounds reasonable
20:23:38 <pvo> danwent: cool… I hadn't worked with it in that config
20:23:42 <danwent> in fact, it is the default mode of running quantum.
20:23:48 <anotherjesse> jbryce: so we can add success criteria to the proposal that "assuming X (api, melange, …)" it goes core
20:23:53 <anotherjesse> and work through that in the next week
20:24:00 <danwent> though I do believe long-term the flexibility + APIs of melange are what we want.
20:24:39 <jbryce> so what are the key things we'd like to have to feel comfortable promoting it for folsom?
20:24:48 <jbryce> 1) plan for transition with nova-network
20:24:57 <jbryce> 2) draft for melange integration
20:25:10 <jbryce> 3) documentation of desired network api end state
20:25:20 <jbryce> did i miss anything?
20:25:31 <devcamcar> 4) documentation of delta of capabilities with vanilla nova-network vs nova-network + quantum
20:25:52 <devcamcar> 5) bonus points: #4 + melange
20:26:00 <devcamcar> let the community have a clear roadmap
20:26:04 <johnpur> ** able to have in place to discuss in April and plan for the Folsom release
20:26:46 <danwent> Ok, I'll start out by setting up a more in-depth dicussion with vishy
20:26:56 <jbryce> danwent hit some of those as bullets on his updated proposal but basically we'd like to get more details
20:27:12 <danwent> jbryce: ok, sounds good.  thanks for the feedback everyone
20:27:30 <jbryce> what else? any other concerns that we think we'd like answered before approving a promotion?
20:27:50 <jbryce> i think that quantum has done an awesome job so far in incubation
20:27:58 <devcamcar> agree!
20:28:08 <johnpur> jbryce: they are the standard so far...
20:28:21 <danwent> thanks guys.  so next week, same bad channel :) ?
20:28:22 <ewanmellor> jbryce: Was about to say the same thing.  We should thank Dan for running his project so well!
20:28:55 <jbryce> yes...thanks, dan. it's made openstack look like we're figuring out what we're doing with this incubation thing.  = )
20:29:05 <johnpur> he he
20:29:08 <jbryce> so let's plan on discussing again next week
20:29:08 <danwent> :)
20:29:21 <jbryce> #topic open discussion
20:29:29 <jbryce> anything else?
20:29:32 <jbryce> break early?
20:29:42 <mtaylor> I got nothing
20:29:52 <johnpur> do we have any further progress or direction on fits testing?
20:29:56 <jbryce> johnpur: i just got to cloud connect and am eating cotton candy from hp cloud services
20:30:16 <johnpur> jbryce: :)
20:30:25 <anotherjesse> johnpur: fits would need to know our network api plan :)
20:31:01 <jbryce> johnpur: i think it's stalled a little
20:31:18 <johnpur> also, are we going to address/comment on the foundation thoughts from Red Hat that was posted?
20:31:21 <jbryce> i'll send a note out and see if what our next step with it should be
20:33:14 <jbryce> johnpur: are you referring to markmc's proposal? we actually incorporated a couple of ideas from there in the draft structure we put up friday and my plan is to continue iterating from that draft structure (with the mailing list, meetup tomorrow, webinars, etc)
20:33:49 <johnpur> jbryce: yes, good to hear. there was some good ideas there.
20:34:40 <jbryce> anything else?
20:35:48 <jbryce> all right. thanks everyone!
20:36:02 <jbryce> #endmeeting