22:00:36 <danwent> #startmeeting
22:00:37 <openstack> Meeting started Tue May 15 22:00:36 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:42 <danwent> hello quantum team
22:00:46 <salv> Hello!
22:00:56 <markvoelker> o/
22:00:58 <garyk> hi
22:01:07 <danwent> #link Agenda: http://wiki.openstack.org/Network/Meetings
22:01:07 <SumitNaiksatam> Hi All!
22:01:22 <danwent> #topic Folsom-1 Release
22:01:37 <danwent> #info 1 week until Folsom-1 branch point
22:01:46 <danwent> #link https://launchpad.net/quantum/+milestone/folsom-1
22:02:03 <danwent> Most everything is in review or already committed, which is great.
22:02:13 <rkukura> hi
22:02:37 <danwent> As a community, I think we really need to pitch in and do what we can to make sure the v2.0 API gets in and tested…. there's still a good deal of work there
22:02:40 <danwent> is jkoelker around?
22:02:49 <danwent> (or perhaps he should be coding? :P)
22:03:07 <danwent> Was good to see that people were commenting on the etherpads:
22:03:36 <danwent> #links API v2.0 etherpad:  http://etherpad.openstack.org/quantum-v2-api
22:03:47 <danwent> though conversations get a bit hard to follow after a while on the etherpad
22:04:06 <edgarmagana> hola mundo!
22:04:32 <danwent> I'm hoping jkoelker and _cerberus_ will have a first cut of the API code by thursday.
22:04:51 <_cerberus_> O_o
22:04:55 <danwent> I'll be working on plugin interface and wiring a base plugin
22:05:02 <danwent> _cerberus_: yeah, I know, but if you do the math...
22:05:14 <danwent> _cerberus_:  what can people do to help out?
22:05:16 <_cerberus_> danwent: we have a team outing tomorrow ;-)
22:05:18 <jkoelker> sorry, was coding
22:05:22 <danwent> _cerberus_: damn....
22:05:46 <danwent> ok, well, I'm just trying to work backward from tuesday branch point.
22:05:46 <jkoelker> thursday eh?
22:05:59 <jkoelker> well nothing like the present to start setting expectations... ;)
22:06:08 <danwent> or do we not consider tuesday branch point feasible?
22:06:16 <jkoelker> thursday might be pushing it, if we have to include XML
22:06:29 <jkoelker> i can probably get you a JSON only by Friday-ish
22:06:53 <danwent> jkoelker: ok, i think we obviously have to support xml eventually, but for a concrete impl that people can look at, I hink json should be a-ok
22:07:01 <jkoelker> sounds good to me
22:07:12 <jkoelker> the serialization should be a middleware anyway...
22:07:14 * jkoelker ducks
22:07:24 <danwent> but my sense is that a review on something this big would have to start early monday to have a good chance of landing by end of tuesday
22:07:25 * _cerberus_ stands behind jkoelker, still shorter
22:07:39 <danwent> :)
22:08:15 <danwent> I'm clearing my plate of other stuff to help out this week, and hopefully other quantum team members can help out as wel.
22:08:37 <danwent> so as you get an idea of things that other people might be able to bite off, please let people know.
22:08:48 <salv> I will happily review over the weekend.
22:08:51 <danwent> (xml serlialization/deserialization might be one)
22:08:58 <_cerberus_> We're tackling the networks and ports controllers atm
22:09:04 <_cerberus_> Basically everything else is fair game.
22:09:08 <danwent> salv:  great, early feedback will be really helpful.
22:09:15 <_cerberus_> We've been yak shaving about how to clean up all the fiddly bits like serialization and whatnot
22:09:23 <danwent> _cerberus_: ok, I'm working on the plugin interface, and we already have basic DB models right?
22:09:33 <danwent> are those committed anywhere, or just on etherpad?  would be good to get them committed.
22:09:36 <jkoelker> github.com/jkoelker/quantum/tree/melange is the repo
22:09:46 <_cerberus_> dragondm was looking into the models
22:10:05 <jkoelker> yea we have them sketched out the etherpad
22:10:14 <danwent> _cerberus_:  i'd save the yak shaving and get a first cut in so people get start to get a sense of the code.  I'd like to avoid everything landing at the last minute :)
22:10:16 <dragondm> yup.
22:10:22 <_cerberus_> Of course
22:10:25 <danwent> jkoelker: are models ready to be committed?
22:10:30 <dragondm> not yet
22:10:59 <danwent> ok… pls ping me when they are.
22:11:00 <dragondm> there was some refactoring to do, but they should be tommorow
22:11:08 <danwent> dragondm: cool, thanks.
22:11:09 <dragondm> will do
22:11:53 <danwent> cool, well let the rest of us know how we can help you out here.  a lot of things in F-2 depend on getting the API in, so I want to minimize slippage :)
22:12:22 <danwent> Next topic for F-1 is the set of outstanding reviews
22:12:33 <danwent> We're actually in not so bad shape.
22:12:59 <danwent> I'd encourage reviewers to spend cycles on things that are bugs/bps targeted for F-1
22:13:09 <danwent> and higher priority over lower priority
22:13:18 <edgarmagana> danwent: will do!
22:13:39 <danwent> any reviews that are important for F-1 (other than the v2.0 API) that are not listed on the agenda?
22:13:48 <danwent> #info Man page: https://review.openstack.org/#/c/7192/
22:13:56 <danwent> #info Agent Common Dir: https://review.openstack.org/#/c/7460/
22:14:03 <danwent> #info Client --debug flag: https://review.openstack.org/#/c/7336/
22:14:10 <danwent> #info LB-plugin tuntap issue: https://review.openstack.org/#/c/7433/
22:14:17 <danwent> #info Multi-node Quantum devstack: https://review.openstack.org/#/c/7001/
22:14:32 <danwent> if so, please make sure they get targeted for F-1, and that they are appropriately targeted.
22:14:48 <danwent> Since we have a lot of new people since the last release, I wanted to quickly cover the milestone release propose.
22:14:51 <danwent> process
22:15:05 <danwent> We'll branch late tuesday of next week.
22:15:06 <garyk> that would be great
22:15:33 <danwent> at that point, we'll have a milestone-proposed branch, which will only be used for important bug fixes, and master will be re-opened for F-2
22:15:48 <danwent> even bugs that need to go into milestone-proposed should first be pushed to master.
22:16:17 <danwent> you can then notify me that it needs to be pulled into milestone-proposed (there is no review needed for this step, unless it is import complicated than a cherry-pick)
22:17:12 <danwent> On wed, Thierry will check with me to make sure there aren't any important issues still outstanding, and if so, he will take the contents of milestone-proposed and release it as F-1 sometime in the following 24 hours.
22:17:34 <danwent> so if we're close to a release and you hit what you think is a blocker, let me know ASAP.
22:18:00 <danwent> during that time, please keep you eyes on the mailing list, as I will send out a note if we urgently need reviews on a bug fix.
22:18:08 <danwent> ok, any questions/concerns about the process?
22:18:51 <danwent> Ok, moving on :)  ( think everyone's falling asleep)
22:18:59 <danwent> one last comment on F-1
22:19:14 <danwent> #info we moved the keystone integration blueprint out of F-1, though we still need to early in F-2: https://blueprints.launchpad.net/quantum/+spec/authorization-support-for-quantum
22:19:23 <danwent> _cerberus_: who should that be assigned to?
22:19:30 <danwent> currently it is troytoman
22:19:34 <_cerberus_> Kevin Mitchell
22:19:38 <danwent> lpid?
22:20:08 * salv reminds folk to remind Kevin to get in touch with me
22:20:20 <danwent> turns out there are a lot of kevin mitchells on launchpad
22:20:55 <_cerberus_> klmitch, I believe
22:20:55 <danwent> #action: send kevin mitchell a note to contact salv about keystone + quantum
22:21:13 <danwent> got it, thanks.
22:21:16 <_cerberus_> https://launchpad.net/~klmitch
22:21:18 <_cerberus_> yeah
22:21:20 <danwent> Ok, anything else for F-1?
22:21:42 <danwent> #topic community topics
22:21:50 <danwent> a couple items I wanted to bring up
22:22:26 <danwent> First off, I don't think we ever wrapped up the "discussion" around python 2.4 and whether we should enforce that any code that might be pulled in by an agent will be compatible.
22:23:02 <garyk> this could be very problematic for the RPC support (so i think)
22:23:14 <danwent> I think there were concerns that openstack-common code will be used in agents, and thus this requirement would be somewhat "viral".  I believe (but am not sure) that openstack in general decided not to focus on 2.4 support.
22:23:37 <danwent> but if someone wants to champion this, I don't want to be the one standing in their way
22:23:50 <danwent> is mnewby here?
22:23:56 <garyk> rpc support => some form of openstack common
22:23:59 <danwent> I think he discussed this ont he ML
22:24:48 <danwent> #action #danwent revive python 2.4 in agent discussion on ML, get to conclusion
22:24:53 <rkukura> openstack common rpc also depends on common cfg, which I'd like to see the agents and server use
22:25:01 <danwent> rkukura: +1
22:25:13 <danwent> rkukura: want to create a BP around adding cfg support?
22:25:28 <rkukura> danwent: sure
22:25:33 <danwent> thx
22:25:58 <rkukura> what milestone?
22:26:20 <danwent> rkukura:  probably F-2, as we don't want people having to change their config file (if required) later in the release cycle...
22:26:38 <mnewby> i'm here
22:26:47 <danwent> I expect the set of people testing out quantum as it prepares to be core to keep growing each milestone.
22:26:52 <danwent> mnewby: hey
22:27:28 <garyk> anyone else having devstack quantum issues or is it just me?
22:27:28 <danwent> was trying to see what we need to do to drive the python 2.4 in agents discussion
22:27:41 <danwent> garyk: please hold one sec
22:28:00 <mnewby> danwent: What kind of discussion?
22:28:15 <mnewby> danwent: Is there some question as to whether 2.4 support is necessary?
22:28:48 <danwent> mnewby:  yes, I think there was some discussions around the implications of 2.4 support for openstack-common
22:29:18 <mnewby> danwent: The question is simple - should quantum support Xen?
22:29:23 <danwent> and whether that means that we should try to make all code used by agents (likely to grow considerably with security groups, dhcp, etc.) 2.4 compatible.
22:29:56 <danwent> mnewby:  I think of it more as should the existing agents be able to run on XenServer dom0
22:30:18 <mnewby> danwent: Given that xen isn't moving in the near term, the questions are the same.
22:30:19 <danwent> some people had mentioned approaches for using the service VM… I believe Citrix folks did this for some items in essex
22:31:08 <danwent> mnewby: well, there's actually kronos that runs xenserver on newer debian, but I believe we're both focused on commercial XenServer, which is the main platform.
22:31:30 <danwent> salv: are you able to comment?  is running an agent in dom0 pretty much our only option?
22:31:33 <mnewby> danwent: We're using XCP here at internap, which closely follows xenserver.
22:31:51 <danwent> mnewby:  sounds like you have a vested interest :)
22:31:55 <danwent> that's fair.
22:32:05 <salv> From my experience it is the only efficient option so far
22:32:24 <mnewby> Nova has the same issue, btw.
22:32:36 <mnewby> Agents intended to run in dom0 have to be python2.4 compatible.
22:32:47 <salv> I heard of people which upgraded their dom0 python environment to 2.6, but this practice is not advisable.
22:33:03 <mnewby> What would drive agents to not be 2.4 compatible?
22:33:11 <danwent> mnewby: I thought someone said that nova only uses xenserver "plugins", and that their main agents (i.e., nova-compute) runs in the service vm.
22:33:24 <danwent> mnewby: I think code that we write is easy to control
22:33:25 <salv> danwent: correct.
22:33:28 <mnewby> danwent: I'm pretty sure that's not true.
22:33:38 <s0mik> danwent: I think thats correct
22:33:39 <mnewby> danwent: There is agent code in nova, too.
22:33:47 <danwent> openstack-common code is more of a concern, as we'll likely be using rpc, config, etc. from there.
22:33:57 <danwent> perhaps you can work with them to make sure it is 2.4 compatible
22:33:59 <salv> ok, now I'm confused :)
22:34:16 <danwent> mnewby:  what is not true?
22:34:17 <mnewby> salv: Sorry, I was delayed.  You're right.
22:34:28 <salv> mnewby: by agent code you mean code which is supposed to run on dom0?
22:34:41 <mnewby> danwent: that nova agent code doesn't run in dom0.
22:34:42 <mnaser> afaik, there is no services running on the dom0 (and it has been something that was enforced not to run in dom0 due to security)
22:34:43 <danwent> I think we may be using the term agent loosely here.
22:34:43 <mnewby> salv: yes
22:34:54 <danwent> mnewby: yes, that's what I was trying to say
22:35:19 <mnaser> there are xenapi plugins that are included (simple files) that are being called from the service VM on the node.  the small xenapi plugins extend the functionality of the xapi that nova-compute connects to
22:35:21 <mnewby> mnaser: I reviewed code as recently as february that was intended to be run in dom0.
22:35:32 <danwent> ok, well, regardless, from salv's comments it sounds like our agent code would need to run on dom0
22:35:38 <danwent> so I'd like to focus on how we could make that work.
22:35:51 <danwent> perhaps coordinating with the openstack-common folks is a good next step
22:36:12 <danwent> I believe mnewby is already working with mtaylor to get some automated testing in.
22:36:15 <rkukura> do the nova VIF drivers currently run in dom0?
22:36:21 <salv> The alternative to running the agent in dom0 is cumbersome and involves development of new plugins. I tried it back last october :)
22:36:23 <mnewby> Despite all the apparent enthusiasm to do so, there is no requirement that we use rpc at all let alone from openstack common.
22:36:25 <danwent> rkukura: not the xenserver one
22:36:56 <danwent> salv: yeah, I don't want to slow things down by implementing a lot of platform specific stuff if we can avoid it...
22:37:17 <danwent> rkukura: xenserver vif driver using XAPI api, which makes webservice call to dom0
22:37:34 <danwent> (salv can correct me)
22:37:48 <salv> danwent: no need to correct, you;re rigth
22:37:50 <rkukura> danwent: could that be done by something like the rootwrap hook?
22:38:06 <danwent> rkukura: don't follow...
22:38:21 <salv> Btw, There's some code for baseline network protection which is not a xapi plugin and is supposed to run in dom0
22:38:24 <danwent> mnewby:  sure, but at the least the config stuff..
22:38:46 <danwent> salv: are those the OVS filters?
22:38:52 <salv> danwent: yes
22:39:13 <mnewby> danwent: We may want to consider holding off on using openstack.common until dom0 is no longer 2.4.  I will check, but keeping common 2.4 compatible will probably not be possible.
22:39:37 <danwent> ok, well, sounds like there's still a lot to explore here.  let's take this offline
22:40:12 <danwent> I just wanted to make sure we were either moving forward with the discussion, or had reached a conclusion.  Let's keep talking about this on the ML.  In the mean time, I'm fine with reviewers requesting 2.4 compliance for our agent code.
22:40:37 <mnewby> ok
22:40:50 <danwent> but I suspect we will want to leverage openstack-common functionality in agents, so I think we need to explore more there.
22:40:53 <danwent> sound fair?
22:41:15 <danwent> i'll take that as agreement :)
22:41:26 <danwent> Ok, on a new topic...
22:41:42 <danwent> I wanted to encourage people to help out in responding to questions on the ML about quantum.
22:42:09 <danwent> and also to sign up to be notified when people submit questions via answers.launchpad.net/quantum
22:42:37 <danwent> the load is definitely going up, now that more people are trying out quantum, and we want them to have a good experience.
22:42:45 <danwent> its also a good chance to identify gaps in our documentation.
22:43:01 <danwent> and one last comment
22:43:19 <danwent> #info anyone interested in helping maintain essex/stable branches for quantum should ping me.
22:43:39 <danwent> #topic open discussion
22:43:47 <danwent> anyone have anything else to discuss?
22:43:48 <garyk> devstack?
22:44:03 <danwent> ah, thanks garyk
22:44:11 <danwent> are you talking about the linuxbridge issue you mentioned?
22:44:23 <SumitNaiksatam> garyk: are you referring to the issue about bridge and gw devices created? or is it something else?
22:44:36 <garyk> danwent: correct
22:44:48 <danwent> lately i've been using devstack with OVS on the version that is under review:  https://review.openstack.org/#/c/7001/
22:45:02 <danwent> but I saw that issue as well when testing with linuxbridge… didn't have time to explore it.
22:45:28 <SumitNaiksatam> garyk: I noticed it first when I was reviewing your agent changes
22:45:36 <danwent> i'm not seeing a similar issue with OVS, so I suspect it is specific to the interface-driver (which is different between linuxbridge and OVS)
22:45:46 <garyk> i guess i'll invest some time and explore
22:46:14 <danwent> garyk: great… would be good to have more people familiar with that code as well.  I can be a point of contact if you have questions about what is going on there.
22:46:30 <danwent> (in terms of QuantumManager code).  SumitNaiksatam is probably best for anything that is linuxbridge specific.
22:46:39 <danwent> or just send to the ML :)
22:46:51 <garyk> ok, i'll take a look and get back to you guys
22:46:56 <danwent> thx
22:46:59 <danwent> anything else?
22:47:05 <SumitNaiksatam> yeah, I am looking at it as well
22:47:13 <garyk> SumitNaiksatam: tx
22:47:30 <danwent> ok, let's see what we can all do to help out with reviews this week, and to help with the new API code.
22:47:35 <garyk> scaling agents: in process of getting it up and running
22:47:50 <garyk> would like to discuss one issue here or can take it to the ML
22:47:56 <danwent> garyk: go ahead
22:48:00 <danwent> just in time :P
22:48:53 <garyk> From my understanding concensus was to have the agent use attachment id to retrieve the network info. There may be false positives here if the plugin does not ensure that this is unique system wide.
22:49:09 <mnewby> it's a uuid, no?
22:49:24 <danwent> mnewby:  yes, but multiple switches could claim to have it.
22:49:44 <mnewby> that doesn't sound very uuid-like
22:50:26 <garyk> if the vif could notify the agent with the id's then it is not a problem.
22:50:31 <danwent> mnewby: this actually happens in real life, like when a VM migrates from one server to another, for a brief period of time that vif (and its UUID) actuallly exists in two locations.
22:50:45 <mnewby> danwent: ah, gotcha
22:51:01 <danwent> garyk: not sure I follow...
22:51:06 <mnewby> garyk: what about udev notification?
22:51:23 <danwent> garyk: do you mean vif-drivers?
22:51:42 <danwent> garyk: maybe write an email to the ML on this?
22:52:15 <garyk> ok - mail will be best
22:52:44 <danwent> ok, last call.  any quick updates before we close out?
22:53:01 <danwent> thanks folks, talk to you next week (and see you on gerrit :P)
22:53:07 <danwent> #endmeeting