14:00:16 #startmeeting networking_ml2 14:00:17 Meeting started Wed Jul 3 14:00:16 2013 UTC. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:20 The meeting name has been set to 'networking_ml2' 14:00:23 good morning! 14:00:33 #link https://wiki.openstack.org/wiki/Meetings/ML2 Agenda 14:00:39 or afternoon! 14:00:55 I thought we could run through action items from last week quick. 14:01:22 There was some confusion on the "Instance ID" from Nova. I opened a blueprint, but will close it per comments from rkukura. https://blueprints.launchpad.net/nova/+spec/vm-instance-id-neutron 14:01:38 #topic Action Items From Last Week 14:01:52 I also opened a bug for proper OVS agent tunnel programming: https://bugs.launchpad.net/neutron/+bug/1196963 14:01:58 the device_id attribute already contains the instance ID 14:02:15 rkukura: Thanks for correcting my understanding there. :) 14:02:29 #link https://wiki.openstack.org/wiki/Neutron/ML2 ML2 Wiki Page 14:02:30 yes, sorry for the confusion in proposing this :) nice to see this is already there 14:02:48 I added an ML2 Wiki page, so we can now put things like devstack info there. 14:03:08 I'll take an action to add description text, links to slides to wiki page 14:03:15 rkukura: Thanks! 14:03:27 #action rkukura to update ML2 wiki with text and slides 14:03:41 rkukura: Thanks for updating this review with ML2 comments! https://review.openstack.org/#/c/33736/ 14:04:09 Is arosen here? 14:04:29 rkukura: May be too early for him. :) 14:04:46 I spoke with him about this, and am starting to think his approach makes sense for our BP 14:05:07 That's great news actually! I'll review it closer as well, though I saw your comments there. 14:05:12 Basically, expose our segment_list as a single attribute 14:05:37 That sounds like it will work. 14:05:43 I don't like the term "transport_zones" for segment_list though 14:06:13 OK, one more action item was for rcurran to send some notes on common code for MechanismDrivers. 14:06:21 rcurran: How goes that? 14:06:38 i had actually already started that email thread before last weeks IRC 14:06:53 If anyone feels full-fledged REST resources are needed for segments, please get involved in the Aaron's review 14:07:19 #action ML2 team to review https://review.openstack.org/#/c/33736/ in the context of multi-segment ML2 14:07:22 rkukura: you mean the ability to read/write the segment list directly from standardized Neutron APIs? 14:08:02 apech: Yes, although this approach does allow updating the list. 14:08:43 arosen pointed out that only admins would ever see this segment resource 14:09:31 I also like the extensibility of the list-of-dicts vs. fixed fields, but am a bit concerned about losing queryability 14:10:02 Seems like these are details that are easily hidden from the user, so admin-only access may be okay 14:10:24 rkukura: If we think this will cover ML2 multi-segment, do we look at having arosen move his work to be more generic to cover that BP? 14:11:12 mestery: The idea would be for his patch to [re]define the extension API, and our BP would cover implementing it for ml2 14:11:21 rkukura: Got it. 14:11:43 I want to formalize how this co-exists with the current provider extension 14:12:06 OK, lets move on to the next agenda item now. 14:12:29 Wanted to point out rcurran's email from a week ago, folks writing MechanismDrivers should have a look at that and respond as necessary. 14:12:48 Lets move on to blueprint updates now. 14:12:53 #topic Blueprint Updates 14:12:59 mestery: I thought the last discussion from last week is that rcurran was going to send out the common code he had in mind 14:13:07 that'd help. I'll certainly reread and respond too 14:13:29 apech: I think it was email and/or notes. :) 14:13:38 yes, but i had already sent out that email on 21-Jun 14:13:38 ah okay. sorry, missed that. will look 14:13:47 apech: No worries. 14:13:59 OK, lets start with apech's MechanismDriver BP 14:14:06 #link https://review.openstack.org/33201 Review for MechanismDriver BP 14:14:20 markmcclain: ping 14:14:30 garyk: Hi 14:14:39 apech: Any updates for everyone? 14:14:53 o/ 14:14:58 I sent out an update last night, which then promptly failed pep8 for a last minute change. About to re-update 14:15:05 I think it's getting close - appreciate the comments 14:15:16 garyk markmcclain: FYI, we're in the middle of hte ML2 meeting on this channel. :) 14:15:19 rkukura - think you'll have time to take a deeper look soon? 14:15:30 yes 14:15:38 mestery: oops. sorry. wrong channel :) 14:16:05 mestery: sorry.. I thought there was something you all wanted me to look at 14:16:35 apech: I need to look at the latest version of your patch as well based on our discussion on gerrit on a prior version. 14:17:00 Any other questions for apech on MechanismDriver BP? 14:17:09 mestery: great, thanks 14:17:50 Given it's a likely long holiday weekend here in the US this week, should we try to shoot for early next week getting this BP merged? 14:17:54 apech: It seems its getting very close, and just minor details should need changing 14:18:42 mestery: works for me. Hopefully others can just pull in changes to unblock their own development of ml2 mechanism drivers 14:19:14 #action ML2 subteam to review MechanismDriver blueprint with the goal of having it merge by early next week. 14:19:25 OK, lets move on. 14:19:33 #link https://blueprints.launchpad.net/quantum/+spec/ml2-portbinding ML2 PortBinding 14:19:42 rkukura: Any updates? 14:20:02 no progress yet, but will start this weekend (when other work will hopefully slow down) 14:20:33 rkukura: is your goal still to try to do this h2? not sure how long you think this will take 14:21:14 apech: I'd like to get in H2, shouldn't be too much code given the MechanismDriver work already in review 14:21:24 rkukura: great, thanks! 14:21:31 Thanks for the updates rkukura! 14:21:40 OK, any questions for PortBinding? 14:21:45 rkukura: any eta? 14:22:01 code in review by next week's meeting at latest 14:22:25 which is the H2 freeze, I think 14:22:25 rkukura: thanks 14:22:36 OK, lets move to the next agenda item. 14:22:46 #link https://review.openstack.org/33297 ML2 GRE Code Review 14:22:52 matrohon: Here? 14:22:58 mestery: yes 14:23:00 hi 14:23:06 hi matrohon! 14:23:12 How goes the bp/ml2-gre work? 14:23:53 it should be ok for a merge ASA i take the review into account 14:24:03 there is only nits 14:24:19 matrohon: Great! And apologies for my git review mishap which resulted in me rebasing your commit. :) 14:24:33 mestery: it' ok :) 14:24:36 The instructions on the wiki for dependent commits were not quite right it turns out. :) 14:24:52 but i'd like rkukura to validate the achitecture 14:25:06 with tunnel_type.py 14:25:20 and absctract method to handle endpoint managment 14:25:21 OK 14:25:24 matrohon: I agree, as the bp/ml2-vxlan is dependent on that as well. 14:25:39 #link https://review.openstack.org/#/c/35384/2 ML2 VXLAN Code Review 14:25:57 This was pushed out yesterday, and is dependent on matrohon's GRE work. 14:26:24 rkukura: you were talking about thinking of a better way to handle generic RPC calls 14:26:58 and to dispatch it in driver, no? 14:27:05 Looks like your TunnelTypeDriver may be more-or-less what I was thinking 14:27:18 rkukura: ok great! 14:27:47 OK, looks like both GRE and VXLAN BPs are moving along nicely then. 14:27:53 mestery: I reviewed your code about vxlan 14:27:53 We may also want more general ability for drivers to mix-in RPC handlers 14:28:06 matrohon: I saw that, thanks! I will plan to address comments today, appreciate it! 14:28:33 matrohon: I think your direction on the multicast group is a good one, and I'll address that today. 14:29:07 rkukura: ok, do you want us to think about that before ml2-gre and vxlan get merged 14:29:46 is this the issue of storing multicast groups with the endpoints, vs configuring single group? 14:30:34 I could be way off base on that 14:30:45 rkukura : I proposed to sort multicast group in VXLan allocation table 14:32:37 Lets continue the VXLAN multicast discussion in the review and on the mailing list. 14:32:46 What is the disposition of "I even wonder if it's really usefull, in this first implementation, to store multicast group in db if it has to be the same for every VNI."? 14:33:31 I was interpreting this as suggestion to not store groups in DB 14:33:40 OK with moving to email/gerrit 14:33:49 rkukura: Sorry, please continue. 14:34:00 rkukura : yes since bp vxlan-linuxbridge use a single multicast group for every VNI 14:34:20 matrohon rkukura: The crux of the issue is do we want to support more than one multicast group or not? 14:34:32 For the first cut of the code, I planned to support a single one for simplicity. 14:34:36 Thoughts? 14:35:06 mestery: exactly, it's not necessary in a first time, but you should have this feature in the future 14:35:26 I'm for keeping it simple until we are sure complexity is needed 14:35:35 matrohon: OK, I can file a blueprint to track this. 14:35:51 #action BP ml2/vxlan to support a single multicast group in first iteration 14:35:52 mestery : ok, great 14:36:13 #action mestery to file BP to add support for multiple multicast addresses to ML2 VXLAN code 14:36:33 OK, any more GRE or VXLAN discussion before we move on? 14:37:18 The next item was ml2-multi-segment-api, but I believe we previously discussed this already. 14:37:23 right 14:37:25 Do we need to discuss anything else on this now? 14:37:38 Just that we might track it for H3 14:37:55 rkukura: Good point. We should target that BP at H3 then, right? 14:38:00 was low priority, maybe change to medium if agreed on simple approach 14:38:35 I wanted to ask a question - I filed the BP for Arista driver, how come I do not see it in the Havana list? 14:38:53 Sukhdev_: Did you target it for H2/H3? 14:39:02 Do I have to take any additional step to include it in havana? 14:39:24 I did not specify - I thought the approver does that 14:39:30 I'll target it 14:39:42 rkukura: Thanks! 14:39:44 rkukura: thanks 14:39:55 OK, moving on to the next agenda item. 14:39:58 #topic Bugs 14:40:04 does this replace the original hardwaredriver BP? 14:40:28 #link https://review.openstack.org/#/c/33107/ OVS agent tunnel_types bug 14:40:31 rkukura: yes 14:40:39 rkukura: yes, original hardwaredriver BP can go away 14:40:44 H2 or H3? 14:41:02 H3 14:41:08 rkukura: Yong gave me a -2, and I thought this was so close. 14:41:41 #link https://docs.google.com/a/mestery.com/document/d/1NT3JVn2lNk_Hp7lP7spc3ysWgSyHa4V0pYELAiePD1s/edit#heading=h.4grgudkj8ei3 ML2 OVS Agent Changes Design 14:41:55 I added a spec on what the OVS Agent will look like after the changes are done. 14:42:00 rkukura: Your review would be appreciated! 14:42:17 I think he just wanted to understand the plan, and the writeup should help 14:42:37 Yes, agreed. I am now thinking to go the full way and implement everything in the document. 14:42:49 e.g. deprecate enable_tunneling in the server, add tunnel_types into the 'ovs' section, etc. 14:43:30 mestery : make sense 14:43:51 mestery: Two comments on that: 1) VLANs can already co-exist with flat, local, and gre networks. 2) should emphasize openvswitch agent supporting multiple tunnel types concurrently (with ml2) is goal 14:44:10 rkukura: Thank you, will update with those comments. 14:44:29 I'll plan a new version of the tunnel_types patch with the changes from the document for early next week at the latest. 14:44:52 OK - lets solicit feedback on the writeup on openstack-dev 14:45:29 we kind of have our own sandbox with ml2, but when we change agents or legacy plugins, people pay more attention 14:45:30 rkukura: I sent email to that affect I believe. 14:45:36 mestery : I assigned this bug to myself : https://bugs.launchpad.net/neutron/+bug/1196963 14:45:37 Launchpad bug 1196963 in neutron "Update the OVS agent code to program tunnels using ports instead of tunnel IDs" [Medium,New] 14:45:46 mestery : it's ok for you? 14:45:55 matrohon: I was going to discuss that one next. :) 14:46:01 matrohon: And yes, thank you for taking that one up! 14:46:06 mestery : ok sorry :) 14:46:21 #action mestery to send email to openstack-dev for the OVS Agent Writeup 14:46:51 matrohon: Do you think the bug you mentioned will be merged by H2? 14:47:01 For ML2, it will be important I think. 14:47:54 mestery : i will try to work on it asap 14:48:06 matrohon: Great, thank you! 14:48:18 is there a feature freeze for H2? 14:49:12 matrohon: Do you mean after H2? 14:50:08 I mean a date taht I have to respect? to let time for review? 14:50:08 H2 is 7/18, but I think a freeze on 7/10 was mentioned in the meeting 14:50:17 rkukura : ok 14:51:03 Maybe not 7/10: " Also it is now July, which means were are 10 days away from H2 feature freeze." 14:51:19 Also, keep in mind gerrit and CI are down this weekend for a day. 14:51:27 could be business days 14:51:28 And with the name change, that may cause some shifting and churn. 14:51:33 freeze is 7.10 14:51:51 markmcclain: thanks! 14:51:53 branch will be cut July 16th 14:52:40 markmcclain: End of day 7/10? 14:53:06 yes 14:53:42 OK, we're running low on time, any other bugs people want to discuss now related to ML2? 14:54:02 mestery: I'm all good 14:54:25 #topic Questions/Comments? 14:54:25 I'm good 14:54:41 OK, thanks for everyone's great work on all the ML2 items! 14:54:53 For those in the US, have a great holiday this week! 14:54:55 thanks! Happy 4th 14:54:58 #endmeeting