21:00:37 <danwent> #startmeeting quantum
21:00:39 <openstack> Meeting started Mon Jan 21 21:00:37 2013 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:40 <emagana> hi folks!
21:00:43 <openstack> The meeting name has been set to 'quantum'
21:00:51 <danwent> #info agenda: http://wiki.openstack.org/Network/Meetings
21:00:55 <garyk> hi
21:01:02 <mlavalle> hi
21:01:06 <danwent> #topic announcements
21:01:10 <alexpilotti> hi
21:01:29 <danwent> #info I updated the "community projects" page with some work items that would be useful for the whole community in Grizzly, but currently have no one assigned: http://wiki.openstack.org/QuantumStarterBugs
21:01:43 <danwent> #info if you're looking for a way to get more engaged with the community, please take a look at this list.
21:01:53 <danwent> others, feel free to add additional projects to this page
21:02:20 <danwent> (even if they are assigned to you, but you're having trouble finding time to work on them, and would be happy if someone else took it off your plate)
21:02:28 <danwent> any other announcements?
21:02:49 <danwent> #topic documentation
21:03:06 <arosen> hi
21:03:10 <danwent> seems like we still have this floating around: https://bugs.launchpad.net/openstack-manuals/+bug/1088304
21:03:12 <uvirtbot> Launchpad bug 1088304 in openstack-manuals "quantum security group doc is confusing when it comes to use nova security group features" [High,In progress]
21:03:29 <nati_ueno> Hi
21:03:58 <danwent> arosen or nati_ueno does it make sense just to remove references to the nova handler for now, since it is not merged?
21:04:17 <gongysh> that bug is waiting for the nova-security commands to be implemented to call quantum.
21:04:34 <gongysh> just like the way we do in floating ip.
21:04:41 <arosen> danwent:  I think so since we are not going to push the nova handler upstream.
21:05:06 <nati_ueno> so whta's blocker?
21:05:07 <arosen> danwent:  yup what gongysh said
21:05:07 <danwent> gongysh: yes, but I suspect that when we complete https://blueprints.launchpad.net/nova/+spec/nova-quantum-security-group-proxy, the config instructions will be diference
21:05:14 <nati_ueno> s/whta/wtat/
21:05:44 <danwent> nati_ueno: that nova blueprint isn't currently being worked on.
21:06:10 <nati_ueno> danwent: nova-quantum-security-group-proxy,?
21:06:15 <danwent> the approach arosen used in the past used the security group triggers in nova, but its not a fully reliable mechanism, hence, it is better to do more of a redesign in nova
21:06:23 <danwent> nati_ueno: yes
21:06:43 <danwent> arosen is assigned, but i think its below a stack of stuff for him
21:07:09 <nati_ueno> May I take that?
21:07:26 <amotoki> do we need nova proxy for sg? Regarding floating ip proxy, it only works when one nic. It may fail when nova instance has multiple nics.
21:08:01 <danwent> amotoki: i think its important for people who use euca-* commands, or deploy with only one nic.
21:08:14 <amotoki> danwent: i see.
21:08:16 <salv-orlando> I think the sg proxy can made to work with multiple nice, with some caveats. arisen, what's your take?
21:08:21 <danwent> amotoki: to proxy floating-ips, but not security groups seems strange.
21:08:26 <salv-orlando> arisen => arosen (damn autocorrect)
21:08:39 <arosen> nati_ueno: yea i think it should work fine with multiple nics.
21:08:55 <arosen> Using the security group handler that we have now it works fine with muliple nics.
21:09:00 <danwent> ok, well, we don't need to design it here, but let's have nati_ueno and arosen agree to follow-up, with nati_ueno potentially working on it.
21:09:17 <danwent> #action nati_ueno and arosen: follow up about nova security group proxy blueprint https://blueprints.launchpad.net/nova/+spec/nova-quantum-security-group-proxy
21:09:22 <arosen> danwent:  nati_ueno sounds good to me.
21:09:23 <nati_ueno> How we handle source_ip on multi nic case?
21:09:32 <nati_ueno> danwent: gotcha
21:09:45 <danwent> next doc bug that is 'high': https://bugs.launchpad.net/openstack-manuals/+bug/1099837
21:09:47 <uvirtbot> Launchpad bug 1099837 in openstack-manuals "dhcp-agent and l3-agent should run without namespace" [High,Triaged]
21:09:54 <danwent> amotoki: the title of this bug seems deceptive
21:10:14 <danwent> really its saying that they should not be run together on the same host, if use_namespace = False, right?
21:10:31 <amotoki> yes.
21:10:34 <danwent> amotoki: I also have a half written email to be sent to the list about this, as I think the limitations that we need to document are even more severe
21:10:59 <danwent> #action danwent sent out note on issues when name_spaces are disabled
21:11:23 <danwent> there are currently no items in the api-docs labeled as 'high'
21:11:43 <danwent> but from last meeting we had an action item on salv-orlando to file additional issues around any extensions not current documented
21:11:47 <danwent> salv-orlando: any progress on that?
21:11:57 <danwent> i shall i re-issue the action item.
21:12:03 <salv-orlando> yes. The news is that there no progress :)
21:12:11 <gongysh> I opened the bug
21:12:12 <salv-orlando> seriously the cisco ones are all undocumented
21:12:17 <salv-orlando> but that's little news
21:12:52 <salv-orlando> what we regard as 'community' extensions are documented. I heard provider networks were not documented
21:13:01 <salv-orlando> but I recall Bob filed the patch and it was approved
21:13:22 <rkukura> that was to the admin guide, not the api guide
21:13:27 <salv-orlando> I see
21:13:31 <danwent> ok, is there a reason it doesn't show here: https://bugs.launchpad.net/openstack-api-site/+bugs?field.tag=netconn-api
21:13:42 <danwent> (for the api docs?)
21:13:53 <salv-orlando> ok cool. Dan, please reissue the action and I will send a note with items to complet
21:14:27 <danwent> #action salv-orlando to file doc bugs for new undocumented API
21:14:27 <danwent> extensions (both netconn-api and openstack-manuals)
21:14:36 <danwent> argh
21:14:48 <danwent> #action salv-orlando to file doc bugs for new undocumented API  extensions (both netconn-api and openstack-manuals)
21:14:54 <danwent> stupid copy/paste :)
21:14:58 <danwent> ok, anything else on docs?
21:15:19 <salv-orlando> #action all quantum people to beat salv-orlando if he forgets about it again
21:15:32 <gongysh> ahah
21:15:36 <danwent> salv-orlando: careful, these meetings are fully archived :P
21:15:40 <Nachi> lol
21:15:46 <danwent> salv-orlando: that counts as evidence in court
21:15:53 <danwent> #topic grizzly-3 milestone status
21:16:08 <danwent> #info branch date for g-3 is Feb 19th, that is less than a month away
21:16:28 <danwent> #info the number of blueprints filed last week was 31 (insanely high) and has increased to 36 this week.
21:17:38 <danwent> #info summary is that we're very unlikely to get even most of this stuff merged.  If you have something that is not a community priority ('high' or above), best to make sure you line up reviewers ahead of time, as they will likely be crunched later in the cycle.
21:18:20 <danwent> due to the holiday, i don't think a lot of the sub-team leaders added items to the agenda.  I will send an email bugging them about this later this week, so we're ready for next weeks meeting.
21:18:35 <danwent> #action danwent bug sub-team leads to fill in agenda items for next weeks meeting
21:18:36 <salv-orlando> It might be rude, but I think we should agree on a number of about 20 bps, and then defer the others.
21:19:06 <salv-orlando> there's just no way we can do 36, especially as most members of the core are busy with development as well
21:19:12 <garyk> salv-orlando: i agree with you.
21:19:19 <markmcclain> I agree too
21:19:33 <enikanorov> salv-orlando: is it a matter of time spent on reviews?
21:19:58 <danwent> my feeling is that core devs should feel "compelled" to do reviews for community items that are "high" or above
21:20:25 <danwent> anything that is medium or low, they should review based on whether they think its a valuable contribution, but would not be "obligated".
21:20:32 <salv-orlando> Time on review and time developing. I can't commit more than 40% of time on reviews, for instance. And the remaining 60% I'm generating burden for reviewers through code :)
21:21:12 <danwent> my general policy is that if you're medium or below, you need to convince a reviewer that your stuff brings value (or horse-trade with them)
21:21:40 <danwent> but if we think it woudl be valuable to start booting out items this early, I think there is a lot of "not started" items to look at :)
21:21:42 <emagana> danwent: +1
21:22:57 <danwent> so, do you all want to specify particular non-high/critical BPs to remove
21:23:20 <danwent> or just have a policy that core devs are only "compelled" to make sure high/critical blueprints get merged.
21:23:26 <danwent> i'm fine either way
21:23:35 <markmcclain> I think high above
21:23:49 <salv-orlando> I'm fine too… my real goal if avoiding the code deluge that usually happen in the last week
21:24:20 <danwent> yeah, everyone tries to push everything in G-3, and there's no reason this should put an insane burden on core devs.
21:24:32 <danwent> we need to stay focused on key community items
21:24:53 <danwent> plus, each core dev will have his own project priorities, from which he can allocate additional review time.
21:25:14 <zykes-> will the l3 + dhcp scaling / ha stuff lad for G ?
21:25:40 <danwent> zykes-: it is ranked 'high', so it means its a community priority, and thus is likely to land
21:26:01 <danwent> ok, anyone else want to discuss this more before we move on?
21:26:57 <danwent> #info due to extremely high number of blueprints, it is decided that core devs need only be "compelled" for focus on community blueprints "high and above", and can choose which medium/low blueprints they feel are valuable enough to the community to be reviewed.
21:27:14 <danwent> i noticed XML support was filed: https://blueprints.launchpad.net/quantum/+spec/quantum-v2-api-xml
21:27:22 <gongysh> yes
21:27:25 <danwent> do we feel this is valuable enough to merit a 'high' ranking?
21:27:40 <danwent> i tend to think so, but wanted to check with people.
21:27:52 <danwent> (assuming we think the approach is clean)
21:28:35 <gongysh> I don't assume it can get in with just two patch sets
21:28:38 <danwent> other than that, there are still some continueing discussions around vif-plugging on the ML, but i'm marking garyk's BP as implemented, since further changes are likely only in nova: https://blueprints.launchpad.net/quantum/+spec/vif-plugging-improvements
21:28:57 <danwent> gongysh: ok, let's keep it at high for now
21:29:13 <salv-orlando> I've started the review. The point is that we need to see whether the way in which collections and null values are handled is satisfactory.
21:29:22 <salv-orlando> but I'm happy to spend time on this.
21:29:24 <danwent> salv-orlando: ok.
21:29:28 <gongysh> yes.
21:29:28 <danwent> nati_ueno: https://blueprints.launchpad.net/quantum/+spec/quantum-security-groups-iptables-ovs
21:29:34 <gongysh> see the test cases.
21:29:39 <mestery> danwent: I've been reviewing the Nova side changes for VIF plugging as well. Some of them appear likely to go in soon.
21:30:09 <danwent> mestery: yes, i need to get my reviews in today.  as we saw last week, it seems like some of these reviews are going a little too quickly :)
21:30:25 <nati_ueno> danwent: The bp is under review now
21:30:37 <danwent> nati_ueno: is whiteboard still accurate that you are blocked by: https://bugs.launchpad.net/nova/+bug/1050433
21:30:40 <uvirtbot> Launchpad bug 1050433 in nova "LibvirtBridgeDriver crashes when spawning an instance with NoopFirewallDriver" [High,Confirmed]
21:30:57 <nati_ueno> danwent: I'll check
21:31:01 <danwent> which is unassigned and not targeted for g-3?
21:31:23 <danwent> nati_ueno: ok, anything else to add on this BP?
21:31:43 <danwent> gongysh: https://blueprints.launchpad.net/quantum/+spec/quantum-scheduler
21:31:45 <nati_ueno> danwent: The fix is in https://review.openstack.org/#/c/19126/. We should update bug report
21:32:22 <danwent> nati_ueno: ok, please do
21:32:23 <salv-orlando> I think this blueprint is already covered by at least two core devs, isn't?
21:32:32 <danwent> salv-orlando: ah, thanks for asking
21:32:35 <nati_ueno> danwent: sure
21:33:28 <danwent> looks like arosen and amotoki are actively reviewing the OVs plugin SG patch, so we should be covered there
21:33:38 <danwent> going back to the xml patch for a sec
21:33:43 <danwent> do we have two core devs there yet?
21:33:47 <danwent> if its 'high', we should
21:34:01 <garyk> danwent: i started to look at it and asked a question or two
21:34:08 <markmcclain> I've reviewed the XML patch
21:34:23 <markmcclain> and salv-orlando is on it too right?
21:34:32 <danwent> yup, with salv-orlando we should be covered
21:34:49 <salv-orlando> yes, I'll work on XML as well.
21:34:52 <gongysh> markmcclain: I have uploaded a new patch set.
21:34:57 <danwent> ok, now back to gongysh for https://blueprints.launchpad.net/quantum/+spec/quantum-scheduler
21:35:30 <danwent> looks like salv-orlando and garyk are reviewing.  i'll promise a review today as well :)
21:35:44 <gongysh> thanks
21:36:26 <danwent> gongysh: if you haven't already, you'll notice that i put a freeze on the nova side change until the quantum side merges.
21:36:42 <gongysh> danwent: I can understand.
21:36:54 <danwent> ok, next up, lbaas
21:37:11 <danwent> we have https://blueprints.launchpad.net/quantum/+spec/lbaas-agent-and-rpc as well as https://blueprints.launchpad.net/quantum/+spec/lbaas-haproxy-driver
21:37:19 <enikanorov> good progress on both
21:37:31 <enikanorov> Ilya is going to put the first one on review this week
21:38:05 <enikanorov> however we have planned to add dev management and scheduling as well, but danwent moved it out g-3
21:38:18 <enikanorov> i still think it's something we should have in some form
21:38:19 <sthakkar> based on the update in the blueprint, review is expected to post later this week
21:38:21 <danwent> enikanorov: yeah, i think that makes sense
21:38:37 <sthakkar> do we have core devs?
21:38:43 <danwent> ok, please make a note to update that on the blueprint.
21:38:51 <sthakkar> (for those that are imminently posting)
21:39:01 <enikanorov> danwent: what bp you are meaning now?
21:39:05 <danwent> (i.e., the whiteboard section of the blueprint) if you have estimates of when the review will be avialable
21:39:15 <danwent> both of the two mentioned above
21:39:17 <salv-orlando> I think I can do review on both patches. I've already done the reviews for the other two LB patches
21:39:24 <danwent> https://blueprints.launchpad.net/quantum/+spec/lbaas-agent-and-rpc as well as https://blueprints.launchpad.net/quantum/+spec/lbaas-haproxy-driver
21:39:44 <enikanorov> ok, regarding lbaas i think there is one thing that is totally missing
21:39:51 <danwent> if something is priority 'high', we should be tracking its progress weekly.
21:39:51 <enikanorov> and we even didn't discuss it
21:40:06 <danwent> enikanorov: yes?
21:40:17 <gongysh> enikanorov: what is it?
21:40:27 <enikanorov> i'd call it "service insertion configuration" or something
21:40:49 <enikanorov> in fact, all we've done for lbaas misses device configuration for particular insertion
21:41:01 <enikanorov> *for particular insertion type
21:41:13 <enikanorov> so we didn't even agree on which type will be default
21:41:45 <danwent> enikanorov: are you talking about how they "plug" into L2 networks, or something else?
21:41:55 <enikanorov> yes
21:42:05 <enikanorov> l2 and l3
21:42:36 <danwent> this is something we discussed at the summit, I believe.
21:42:57 <danwent> anyway, probably best to start an ML thread on this, as we only have 18 minutes in the meeting.
21:43:03 <amotoki> do you have a plan to add lbaas support in devstack?
21:43:41 <enikanorov> ok, i think i'll start such thread
21:43:54 <danwent> enikanorov: great, thank you
21:44:09 <enikanorov> and less of concern, we have salv-orlando's code regarding service types, but no use of it yet
21:44:37 <danwent> enikanorov: because there will only be one driver to start?
21:44:38 <enikanorov> is it something left for better days of after grizzly?
21:44:41 <salv-orlando> enikanorov: I think it's up to you guys if you want to add support the lb plugin for service types.
21:44:52 <salv-orlando> Otherwise I can do that on top of your patch as soon as it is available
21:44:54 <avishayb> I have submitted a BP on this (service type)
21:44:56 <salv-orlando> assuming that it's doable
21:45:08 <salv-orlando> yeah let's avyshayb do that then
21:45:27 <enikanorov> ok, i'll check it out
21:45:30 <danwent> i think avishayb's blueprint is general, not specific to lbaas?
21:45:46 <bobmel> Sorry, which bp is that?
21:45:57 <danwent> avishayb: i read the blueprint quickly, but it wasn't clear to me what it meant
21:46:03 <danwent> avishayb: do you have a pointer?
21:46:10 <enikanorov> danwent: is there a chance we can have scheduling& dev management in g-3? code is ready, btw
21:46:49 <danwent> enikanorov: at this point, its the review cycle that worries me more than anything.  let's get the base lbaas stuff in, and then see where we stand with respect to the G-3 deadline
21:46:52 <avishayb> the idea is to add the service type (Golden,Silver,etc) on the VIP creation
21:47:28 <danwent> avishayb: yes, but isn't that what salvatore's blueprint already enables? or are you just talking about making sure the lbaas plugin supports the service-type introduced by salv-orlando ?
21:47:54 <avishayb> The BP explains how to do it.
21:47:57 <danwent> ok, running low on time, so let's move this discuss to ML if we can't wrap it up quickly.
21:48:22 <enikanorov> may i send you guys an email regarding the scheduling& dev management explaining in details of what have been done so you could decide? I think a part of that code should be in one way or another, so you have to choose which part and how to do it bettter
21:48:33 <danwent> salv-orlando: do we need to discuss more before reaching consensus on "core" nature of provider network and l3 apis?
21:48:56 <salv-orlando> I think in light of what we said today
21:49:07 <salv-orlando> we will consider "de facto core"
21:49:15 <salv-orlando> meaning document them as core api, but don't touch the code
21:49:26 <danwent> enikanorov: i think it makes sense to have basic scheduling in your lbaas plugin.  But I don't want the community consumed by a larger debate on representing devices and scheduling in G-3… there's just too much on our plate already
21:50:04 <danwent> salv-orlando: but does "core" mean that all plugins need to expose it, or it is more like the "community supported extensions" idea i mentioned on the ML?
21:50:23 <enikanorov> danwent: yep. the code is simplistic. it's all about conf management rather than about comprehensive scheduling or dev management.
21:50:46 <danwent> enikanorov: ok, pls send note.  we're running out of time in meeting :)
21:50:52 <salv-orlando> community supported extensions
21:51:07 <salv-orlando> that's what I mean by "de facto"
21:51:26 <danwent> salv-orlando: ok, I think that makes sense.  Unless we see significant disagreement on the ML, let's document that somewhere and go with it as a plan
21:51:28 <SumitNaiksatam> sounds reasonable to me too
21:51:38 <salv-orlando> benefit/burdess ratio is definitely too low
21:51:48 <salv-orlando> burdess -> burden
21:52:13 <danwent> ok, given time constraints, please let me know if there are updates for quantum tempest or quantum horizon,
21:52:27 <danwent> otherwise, i want to discuss quantum stable, quantum client, and the brocade plugin in the final minutes
21:52:36 <amotoki> go ahead.
21:52:41 <danwent> #topic quantum stable
21:52:54 <danwent> garyk, i believe mark is targeting jan 24th for all stable fixes being in ?
21:53:01 <danwent> for final release on the 31st?
21:53:16 <garyk> danwent: yes. just have one minor backport to do and then a few in the queue. looking good at the moment
21:53:44 <danwent> garyk: ok, great work.  please sent a note to the core team once you have the full list ready for review, as the 24th is before our next meeting.
21:53:49 <danwent> #topic quantum client
21:53:55 <garyk> danwent: ok, will do
21:54:04 <danwent> I wanted to start having a section where we track these items, as sometimes they end up under the radar
21:54:37 <danwent> gongysh: looks like we still need to create a 2.0 release in launchpad to track client changes that we will release in conjunction with grizzly?
21:54:50 <gongysh> 3.0?
21:54:56 <danwent> gongysh: ah, yes :)
21:55:09 <danwent> gongysh, markmcclain anything else on client/cli side?
21:55:21 <gongysh> markmccleain said he is going to study it.
21:55:21 <markmcclain> not from me
21:55:31 <danwent> in general, i just want to make sure we're using launchpad to keep track of releases and high priority items.
21:55:38 <enikanorov> we have lbaas-cli changes on review as well
21:55:46 <gongysh> study how to create a 3.0 milestone on launchpad.
21:55:48 <enikanorov> close to approval, i believe
21:55:49 <danwent> enikanorov: yup, exactly. :)
21:56:02 <danwent> ok, markmcclain you are going to be creating the milestone on LP?
21:56:12 <markmcclain> yes
21:56:27 <danwent> #action markmcclain to create 3.0 milestone on LP for python-quantumclient project and associate appropriate blueprints
21:56:36 <danwent> #topic open discussion
21:56:46 <danwent> ok the one topic i had for open discussion was the brocade plugin
21:56:54 <danwent> shiv has pushed code to a public github repo
21:56:58 <shiv> brocade plugin is ready for review-checkin - need bp approval
21:57:07 <danwent> and garyk has volunteered to be core maintainer.
21:57:40 <danwent> while garyk has a lot on his plate, he is also extremely active in the community, so i think he has the cycles to maintain this if he says he will
21:57:55 <danwent> is there an active review already?
21:58:07 <danwent> last i saw, i just saw code on github
21:58:32 <markmcclain> also has the code on github been brought up to hacking standards?
21:58:54 <shiv> are we ok to move code to quantum?
21:59:05 <danwent> markmcclain: i would assume that is  pre-req to getting it merged into quantum, but if they missed some items, it can be handled in review.
21:59:29 <danwent> shiv: are you familar with the HACKING guidlines?  make sure the code is compliant will save a lot of reviewer pain
21:59:43 <garyk> danwent: shiv : let me know when it is in gerrit for review
21:59:45 <danwent> garyk: can you confirm for the logs that you are going to be the maintainer?
21:59:56 <shiv> will take care of that, also i have gary for guidance.
22:00:14 <garyk> danwent: yes, i confirm. is this written in stone?
22:00:15 <shiv> gary: yes..
22:00:19 <danwent> probably up to the maintainer to make sure the code is in reasonable shape before asking other core devs to review
22:00:27 <danwent> garyk: IRC stone :)
22:00:43 <garyk> danwent: :) and now its pumpkin.
22:00:49 <danwent> ok, so I just want to make sure no one has any significant concerns with this plugin being added to the main repo
22:00:58 <danwent> if you do, please work with garyk and shiv on them.
22:01:13 <shiv> lmk, any issues, thx.
22:01:13 <danwent> at this point, i'll approve the BP and it can be posted to gerrit for more detailed review
22:01:25 <danwent> we are over time, but does anyone have any other open issues?
22:01:46 <garyk> i am going to crash. thanks and good night
22:01:54 <danwent> #info brocade plugin with garyk as a maintainer is cleared to begin review for merging into the main repo
22:02:04 <danwent> #endmeeting