21:00:37 #startmeeting quantum 21:00:39 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:40 hi folks! 21:00:43 The meeting name has been set to 'quantum' 21:00:51 #info agenda: http://wiki.openstack.org/Network/Meetings 21:00:55 hi 21:01:02 hi 21:01:06 #topic announcements 21:01:10 hi 21:01:29 #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 #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 others, feel free to add additional projects to this page 21:02:20 (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 any other announcements? 21:02:49 #topic documentation 21:03:06 hi 21:03:10 seems like we still have this floating around: https://bugs.launchpad.net/openstack-manuals/+bug/1088304 21:03:12 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 Hi 21:03:58 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 that bug is waiting for the nova-security commands to be implemented to call quantum. 21:04:34 just like the way we do in floating ip. 21:04:41 danwent: I think so since we are not going to push the nova handler upstream. 21:05:06 so whta's blocker? 21:05:07 danwent: yup what gongysh said 21:05:07 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 s/whta/wtat/ 21:05:44 nati_ueno: that nova blueprint isn't currently being worked on. 21:06:10 danwent: nova-quantum-security-group-proxy,? 21:06:15 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 nati_ueno: yes 21:06:43 arosen is assigned, but i think its below a stack of stuff for him 21:07:09 May I take that? 21:07:26 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 amotoki: i think its important for people who use euca-* commands, or deploy with only one nic. 21:08:14 danwent: i see. 21:08:16 I think the sg proxy can made to work with multiple nice, with some caveats. arisen, what's your take? 21:08:21 amotoki: to proxy floating-ips, but not security groups seems strange. 21:08:26 arisen => arosen (damn autocorrect) 21:08:39 nati_ueno: yea i think it should work fine with multiple nics. 21:08:55 Using the security group handler that we have now it works fine with muliple nics. 21:09:00 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 #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 danwent: nati_ueno sounds good to me. 21:09:23 How we handle source_ip on multi nic case? 21:09:32 danwent: gotcha 21:09:45 next doc bug that is 'high': https://bugs.launchpad.net/openstack-manuals/+bug/1099837 21:09:47 Launchpad bug 1099837 in openstack-manuals "dhcp-agent and l3-agent should run without namespace" [High,Triaged] 21:09:54 amotoki: the title of this bug seems deceptive 21:10:14 really its saying that they should not be run together on the same host, if use_namespace = False, right? 21:10:31 yes. 21:10:34 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 #action danwent sent out note on issues when name_spaces are disabled 21:11:23 there are currently no items in the api-docs labeled as 'high' 21:11:43 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 salv-orlando: any progress on that? 21:11:57 i shall i re-issue the action item. 21:12:03 yes. The news is that there no progress :) 21:12:11 I opened the bug 21:12:12 seriously the cisco ones are all undocumented 21:12:17 but that's little news 21:12:52 what we regard as 'community' extensions are documented. I heard provider networks were not documented 21:13:01 but I recall Bob filed the patch and it was approved 21:13:22 that was to the admin guide, not the api guide 21:13:27 I see 21:13:31 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 (for the api docs?) 21:13:53 ok cool. Dan, please reissue the action and I will send a note with items to complet 21:14:27 #action salv-orlando to file doc bugs for new undocumented API 21:14:27 extensions (both netconn-api and openstack-manuals) 21:14:36 argh 21:14:48 #action salv-orlando to file doc bugs for new undocumented API extensions (both netconn-api and openstack-manuals) 21:14:54 stupid copy/paste :) 21:14:58 ok, anything else on docs? 21:15:19 #action all quantum people to beat salv-orlando if he forgets about it again 21:15:32 ahah 21:15:36 salv-orlando: careful, these meetings are fully archived :P 21:15:40 lol 21:15:46 salv-orlando: that counts as evidence in court 21:15:53 #topic grizzly-3 milestone status 21:16:08 #info branch date for g-3 is Feb 19th, that is less than a month away 21:16:28 #info the number of blueprints filed last week was 31 (insanely high) and has increased to 36 this week. 21:17:38 #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 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 #action danwent bug sub-team leads to fill in agenda items for next weeks meeting 21:18:36 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 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 salv-orlando: i agree with you. 21:19:19 I agree too 21:19:33 salv-orlando: is it a matter of time spent on reviews? 21:19:58 my feeling is that core devs should feel "compelled" to do reviews for community items that are "high" or above 21:20:25 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 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 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 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 danwent: +1 21:22:57 so, do you all want to specify particular non-high/critical BPs to remove 21:23:20 or just have a policy that core devs are only "compelled" to make sure high/critical blueprints get merged. 21:23:26 i'm fine either way 21:23:35 I think high above 21:23:49 I'm fine too… my real goal if avoiding the code deluge that usually happen in the last week 21:24:20 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 we need to stay focused on key community items 21:24:53 plus, each core dev will have his own project priorities, from which he can allocate additional review time. 21:25:14 will the l3 + dhcp scaling / ha stuff lad for G ? 21:25:40 zykes-: it is ranked 'high', so it means its a community priority, and thus is likely to land 21:26:01 ok, anyone else want to discuss this more before we move on? 21:26:57 #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 i noticed XML support was filed: https://blueprints.launchpad.net/quantum/+spec/quantum-v2-api-xml 21:27:22 yes 21:27:25 do we feel this is valuable enough to merit a 'high' ranking? 21:27:40 i tend to think so, but wanted to check with people. 21:27:52 (assuming we think the approach is clean) 21:28:35 I don't assume it can get in with just two patch sets 21:28:38 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 gongysh: ok, let's keep it at high for now 21:29:13 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 but I'm happy to spend time on this. 21:29:24 salv-orlando: ok. 21:29:28 yes. 21:29:28 nati_ueno: https://blueprints.launchpad.net/quantum/+spec/quantum-security-groups-iptables-ovs 21:29:34 see the test cases. 21:29:39 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 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 danwent: The bp is under review now 21:30:37 nati_ueno: is whiteboard still accurate that you are blocked by: https://bugs.launchpad.net/nova/+bug/1050433 21:30:40 Launchpad bug 1050433 in nova "LibvirtBridgeDriver crashes when spawning an instance with NoopFirewallDriver" [High,Confirmed] 21:30:57 danwent: I'll check 21:31:01 which is unassigned and not targeted for g-3? 21:31:23 nati_ueno: ok, anything else to add on this BP? 21:31:43 gongysh: https://blueprints.launchpad.net/quantum/+spec/quantum-scheduler 21:31:45 danwent: The fix is in https://review.openstack.org/#/c/19126/. We should update bug report 21:32:22 nati_ueno: ok, please do 21:32:23 I think this blueprint is already covered by at least two core devs, isn't? 21:32:32 salv-orlando: ah, thanks for asking 21:32:35 danwent: sure 21:33:28 looks like arosen and amotoki are actively reviewing the OVs plugin SG patch, so we should be covered there 21:33:38 going back to the xml patch for a sec 21:33:43 do we have two core devs there yet? 21:33:47 if its 'high', we should 21:34:01 danwent: i started to look at it and asked a question or two 21:34:08 I've reviewed the XML patch 21:34:23 and salv-orlando is on it too right? 21:34:32 yup, with salv-orlando we should be covered 21:34:49 yes, I'll work on XML as well. 21:34:52 markmcclain: I have uploaded a new patch set. 21:34:57 ok, now back to gongysh for https://blueprints.launchpad.net/quantum/+spec/quantum-scheduler 21:35:30 looks like salv-orlando and garyk are reviewing. i'll promise a review today as well :) 21:35:44 thanks 21:36:26 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 danwent: I can understand. 21:36:54 ok, next up, lbaas 21:37:11 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 good progress on both 21:37:31 Ilya is going to put the first one on review this week 21:38:05 however we have planned to add dev management and scheduling as well, but danwent moved it out g-3 21:38:18 i still think it's something we should have in some form 21:38:19 based on the update in the blueprint, review is expected to post later this week 21:38:21 enikanorov: yeah, i think that makes sense 21:38:37 do we have core devs? 21:38:43 ok, please make a note to update that on the blueprint. 21:38:51 (for those that are imminently posting) 21:39:01 danwent: what bp you are meaning now? 21:39:05 (i.e., the whiteboard section of the blueprint) if you have estimates of when the review will be avialable 21:39:15 both of the two mentioned above 21:39:17 I think I can do review on both patches. I've already done the reviews for the other two LB patches 21:39:24 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 ok, regarding lbaas i think there is one thing that is totally missing 21:39:51 if something is priority 'high', we should be tracking its progress weekly. 21:39:51 and we even didn't discuss it 21:40:06 enikanorov: yes? 21:40:17 enikanorov: what is it? 21:40:27 i'd call it "service insertion configuration" or something 21:40:49 in fact, all we've done for lbaas misses device configuration for particular insertion 21:41:01 *for particular insertion type 21:41:13 so we didn't even agree on which type will be default 21:41:45 enikanorov: are you talking about how they "plug" into L2 networks, or something else? 21:41:55 yes 21:42:05 l2 and l3 21:42:36 this is something we discussed at the summit, I believe. 21:42:57 anyway, probably best to start an ML thread on this, as we only have 18 minutes in the meeting. 21:43:03 do you have a plan to add lbaas support in devstack? 21:43:41 ok, i think i'll start such thread 21:43:54 enikanorov: great, thank you 21:44:09 and less of concern, we have salv-orlando's code regarding service types, but no use of it yet 21:44:37 enikanorov: because there will only be one driver to start? 21:44:38 is it something left for better days of after grizzly? 21:44:41 enikanorov: I think it's up to you guys if you want to add support the lb plugin for service types. 21:44:52 Otherwise I can do that on top of your patch as soon as it is available 21:44:54 I have submitted a BP on this (service type) 21:44:56 assuming that it's doable 21:45:08 yeah let's avyshayb do that then 21:45:27 ok, i'll check it out 21:45:30 i think avishayb's blueprint is general, not specific to lbaas? 21:45:46 Sorry, which bp is that? 21:45:57 avishayb: i read the blueprint quickly, but it wasn't clear to me what it meant 21:46:03 avishayb: do you have a pointer? 21:46:10 danwent: is there a chance we can have scheduling& dev management in g-3? code is ready, btw 21:46:49 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 the idea is to add the service type (Golden,Silver,etc) on the VIP creation 21:47:28 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 The BP explains how to do it. 21:47:57 ok, running low on time, so let's move this discuss to ML if we can't wrap it up quickly. 21:48:22 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 salv-orlando: do we need to discuss more before reaching consensus on "core" nature of provider network and l3 apis? 21:48:56 I think in light of what we said today 21:49:07 we will consider "de facto core" 21:49:15 meaning document them as core api, but don't touch the code 21:49:26 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 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 danwent: yep. the code is simplistic. it's all about conf management rather than about comprehensive scheduling or dev management. 21:50:46 enikanorov: ok, pls send note. we're running out of time in meeting :) 21:50:52 community supported extensions 21:51:07 that's what I mean by "de facto" 21:51:26 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 sounds reasonable to me too 21:51:38 benefit/burdess ratio is definitely too low 21:51:48 burdess -> burden 21:52:13 ok, given time constraints, please let me know if there are updates for quantum tempest or quantum horizon, 21:52:27 otherwise, i want to discuss quantum stable, quantum client, and the brocade plugin in the final minutes 21:52:36 go ahead. 21:52:41 #topic quantum stable 21:52:54 garyk, i believe mark is targeting jan 24th for all stable fixes being in ? 21:53:01 for final release on the 31st? 21:53:16 danwent: yes. just have one minor backport to do and then a few in the queue. looking good at the moment 21:53:44 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 #topic quantum client 21:53:55 danwent: ok, will do 21:54:04 I wanted to start having a section where we track these items, as sometimes they end up under the radar 21:54:37 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 3.0? 21:54:56 gongysh: ah, yes :) 21:55:09 gongysh, markmcclain anything else on client/cli side? 21:55:21 markmccleain said he is going to study it. 21:55:21 not from me 21:55:31 in general, i just want to make sure we're using launchpad to keep track of releases and high priority items. 21:55:38 we have lbaas-cli changes on review as well 21:55:46 study how to create a 3.0 milestone on launchpad. 21:55:48 close to approval, i believe 21:55:49 enikanorov: yup, exactly. :) 21:56:02 ok, markmcclain you are going to be creating the milestone on LP? 21:56:12 yes 21:56:27 #action markmcclain to create 3.0 milestone on LP for python-quantumclient project and associate appropriate blueprints 21:56:36 #topic open discussion 21:56:46 ok the one topic i had for open discussion was the brocade plugin 21:56:54 shiv has pushed code to a public github repo 21:56:58 brocade plugin is ready for review-checkin - need bp approval 21:57:07 and garyk has volunteered to be core maintainer. 21:57:40 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 is there an active review already? 21:58:07 last i saw, i just saw code on github 21:58:32 also has the code on github been brought up to hacking standards? 21:58:54 are we ok to move code to quantum? 21:59:05 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 shiv: are you familar with the HACKING guidlines? make sure the code is compliant will save a lot of reviewer pain 21:59:43 danwent: shiv : let me know when it is in gerrit for review 21:59:45 garyk: can you confirm for the logs that you are going to be the maintainer? 21:59:56 will take care of that, also i have gary for guidance. 22:00:14 danwent: yes, i confirm. is this written in stone? 22:00:15 gary: yes.. 22:00:19 probably up to the maintainer to make sure the code is in reasonable shape before asking other core devs to review 22:00:27 garyk: IRC stone :) 22:00:43 danwent: :) and now its pumpkin. 22:00:49 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 if you do, please work with garyk and shiv on them. 22:01:13 lmk, any issues, thx. 22:01:13 at this point, i'll approve the BP and it can be posted to gerrit for more detailed review 22:01:25 we are over time, but does anyone have any other open issues? 22:01:46 i am going to crash. thanks and good night 22:01:54 #info brocade plugin with garyk as a maintainer is cleared to begin review for merging into the main repo 22:02:04 #endmeeting