14:01:12 #startmeeting networking_ml2 14:01:14 Meeting started Wed Sep 11 14:01:12 2013 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:17 The meeting name has been set to 'networking_ml2' 14:01:23 #link https://wiki.openstack.org/wiki/Meetings/ML2 Agenda 14:01:42 * mestery kicks a tumbleweed to HenryG. 14:01:55 So, rkukura and I are hoping to have a very short meeting today. 14:02:07 So to that goal, I've setup a very tight agenda, please see the link above. 14:02:23 First, just a note: Modular Layer3 (e.g. L3 Routing plugin) merged this morning! 14:02:35 We'll need to document ML3 with ML2. 14:02:43 #action rkukura and mestery to document ML3 with ML2. 14:03:20 lets hold off on calling it ML3 for now, since it doesn't (yet) use drivers supporting mulitple technologies simultaneously 14:03:36 rkukura: OK, though it's too catchy to resist. ;) 14:03:51 We have one critical bug: bug 1223000 14:03:54 Launchpad bug 1223000 in neutron "ML2 port-binding fails if FQDN not used" [Critical,Confirmed] https://launchpad.net/bugs/1223000 14:04:09 I plan to fix that this week, but have several options 14:04:11 I discovered this while testing L2 Population on multi-node devstack 14:04:17 rkukura: Awesome! 14:04:37 1) fix nova to use getfqdn(), 2) break neutron to use gethostname(), or lazy queries 14:04:55 rkukura: For what it's worth, I'm using option 2 to work around this at the moment. 14:05:16 I'm wondering if that is best - be consistent across the projects 14:05:34 Makes sense 14:05:37 but I'm not sure what impact the change would have on continuous deployments 14:05:45 clearly less than changing nova would have, I think 14:05:53 Agreed 14:06:12 +1 for option 2, as neutron doesn't make a large use of CONF.host for now 14:06:37 feleouet: Good timing here. :) 14:06:38 can you add a configurable option for FQDN 14:06:42 option 3) lazy queries seems kind of complex and could introduce issues 14:06:55 For this late in Havana, I think option 2 is best. 14:06:55 sukhdev_: sure 14:07:03 agreed on 2 14:07:10 with config option I think 14:07:13 Yes 14:07:20 but default to matching nova 14:07:32 then maybe we can get similar option into nova 14:07:32 That seems reasonable. 14:07:50 The Nova change woudl be in Icehouse, right? 14:08:04 most likely 14:08:13 Cool 14:08:17 OK, lets move on. 14:08:25 We have one FFE left for Havana: The 3 L2 Population BPs 14:08:31 feleouet: How goes L2 Population? 14:08:37 If you see ML2 driver for Arista, I ran into the same FQDN issue - Nova vs LLDP - so, I added config option to solve this 14:08:39 hi, can i report issue with devstack + ml2 here? 14:08:54 mestery: works fine for me, and what about your testings? 14:08:56 dandrushko: Yes, devstack is later in the agenda. 14:09:02 thanks 14:09:11 mestery: is today the deadline for FFEs to merge? 14:09:23 feleouet: I am seeing some oddities, though not related to L2 Pop, will continue testing today. 14:09:30 rkukura: L2 Population FFE ends today, yes. 14:09:41 rkukura: Other FFEs have different end dates is my understanding. 14:09:58 We did quite extensive testing here, and it works really well 14:09:59 is it all-or-nothing for the 3 merges? 14:10:11 But didn't had mayny review comments 14:10:16 To fully utilize L2 pop, I think so. 14:10:34 feleouet: I think the code is fine, I'm just trying to test it out. :) 14:10:52 It could be a fair candidate for FFE, as proposed changes are essentially code addition. As long as l2population isn't activated, plugin and agents shouldn't be affected. 14:10:56 I will do my best to do at least a quick review this afternoon on all 3 14:11:05 rkukura: Thanks. 14:11:09 rkukura: thanks! 14:11:21 getting car serviced, so can do this in waiting room 14:11:24 feleouet: I'll get my testing done in the next 2 hours and also provide review/comments feedback. 14:11:26 I'll do my best to quickly address any comment 14:11:35 feleouet: Thanks! 14:12:00 feleouet: I'll keep an eye on these and make sure they merge if everything looks good,. 14:12:13 Anything else on L2 pop? 14:12:24 will this need documentation? 14:12:30 Yes 14:12:58 It's configurable on/off, so at a minimum we need to document that. But we may want to document it a bit more to describe how it works. 14:13:02 if it gets merged, we'll work on documenting the feature 14:13:15 lets get it in 14:13:24 Awesome. 14:13:29 OK, lets keep moving here. 14:13:32 thanks! 14:13:35 devstack and ML2 14:13:42 2 patches merged (see agenda link) 14:13:49 Only one left is defaulting devstack to ML2 over OVS 14:14:05 #link https://review.openstack.org/#/c/45493/ Default ML2 to LinuxBridge and OVS MDs 14:14:20 #link https://review.openstack.org/#/c/45697/ Augment instead of override "extra" ML2 paramaters 14:14:31 dandrushko: You are seeing issues with ML2 and devstack? 14:14:52 well, not really 14:15:33 basically i want to point that on a wiki with devstack+ml2 config guide there is option ML2_VLAN_RANGES=100:200 14:15:35 also need https://review.openstack.org/#/c/45565/, don't we?\ 14:15:39 for basic vlan configuration 14:16:02 I submitted a patch regarding devstack and jsonrpclib fix 14:16:04 but if this option enabled, i'm getting this 14:16:05 TRACE neutron.plugins.ml2.drivers.type_vlan NetworkVlanRangeError: Invalid network VLAN range: '100:200' - 'need more than 2 values to unpack' 14:16:06 rkukura: Was going to talk about that one next, but it fits here too 14:16:31 you need physical name on ML2_VLAN_RANGES 14:16:32 dandrushko: I think that is a bug, it should have a network identifier (e.g. something like physnet1:100:200) 14:16:32 without this option everything goes fine 14:16:38 rcurran: Exactly 14:16:49 dandrushko: this needs the physical_network just like the existing plugins' network_vlan_ranges 14:16:50 Sorry, not a bug, but a typo in the wiki 14:17:06 ok, thank you 14:17:42 sukhdev_: Looks like your jsonrpclib patch will be approved by garyk once you fix the commit message. Can you do that this morning? 14:18:24 sukhdev_: I've got concerns about the correct process for introducing a new dependency, but don't want to derail this fix 14:18:35 OK - I will do that - in order to make the change to comment, do i need to upload a new patch? or is there any cleaver way to do it? 14:18:58 Just do a "git commit --amend" to fix the message then "git review" again 14:19:25 rkukura: I saw your email and want to understand the concern and provide correct fix - but, am not familiar with this stuff yet :-) 14:19:37 sukhdev_: also, the devstack fix makes this an agent dependency, but its really a server dependency, right? 14:20:00 mestery: THX 14:20:07 sukhdev_: I have not had time to investigate it, but I think new dependencies are supposed to be added via OSLO. 14:20:36 There is some mechanism to coordinate that different projects don't have conflicting version requirements 14:20:42 Might be good to send an email to openstack-dev for feedback from the oslo folks. 14:20:43 what do you mean by server dependency? 14:21:01 sukhdev_: The arista MD runs in the neutron server 14:21:18 yes 14:21:21 so the depenency needs to be installed on the node where the server runs, not where agents run 14:21:37 ah - I see your point now 14:22:02 sukhdev_: sorry for not posting this on the review - I've been totally swamped, and wanted to figure out the overall process, but just have not got a chance 14:22:49 If you can point me to some documentation or anything which will lead me in the right direction, I can dig up and provide the feedback 14:23:12 sukhdev_ rkukura: Perhaps an email to the openstack-dev list to ping some oslo folks is in order here. 14:23:25 jsonrpclib seems to be already in oslo: 14:23:26 sukhdev_: Can you take care of that? Send them all the details and someone can likely help out. 14:23:27 https://github.com/openstack/requirements/blob/master/global-requirements.txt#L25 14:23:49 yes, it was added back in April 14:24:06 shouldn't we try to update neutron requirements? 14:24:30 feleouet: they are 14:24:46 feleouet: That may be what I was thinking of - really glad to see jsonrpclib is already there 14:24:54 I added it in the neutron requirements as a part of my patch 14:25:00 oh sorry, I missed something about this issue;) 14:25:08 so seems like devstack installing it is all that remains 14:25:45 In that case if the fix that I submitted should take care of the issue, right? 14:26:35 Probably - just would like to make sure we do this correctly for devstack - should it be listed somewhere under devstack/files if its python dependency? 14:26:51 But the change is installing agent packages. 14:26:52 we can take this to the review rather than use up the meeting time 14:26:55 I thought we needed this on the server? 14:27:00 rkukura: Good point. 14:27:15 OK, so the only other item is ML2 documentation. 14:27:29 rkukura and I plan to have a draft out hopefully before next Monday's Neutron team meeting. 14:27:44 Once that is out, getting as many people to review will be very helpful. 14:27:50 I am not familiar with how the files/* stuff is used - I will be happy to add it there, if you feel that is needed as well 14:28:04 rkukura: Anything else on documentation right now? 14:28:13 mestery: I'm setup to edit docs and you are out next week, so I can manage the edits 14:28:27 Can I raise one issue? 14:28:39 rkukura: Great! I may ping you to get setup for that too. 14:28:54 OK, that's all for the agenda then. 14:28:58 sukhdev_: Sure, go ahead. 14:29:41 port dict has name filed, and it is never set. I thought port binding was going to take care of it - but, no luck 14:29:55 how do we get the name filled in port dict? 14:30:26 that is port name, i meant 14:30:33 sukhdev_: Its not set in port_create because nova doesn't pass it 14:30:44 port name, or host_id? 14:30:53 port name 14:31:03 Isn't name optional? 14:31:07 it is always empty 14:31:23 Can you set it with port_update? 14:31:36 yes, the name is optional - but, it is very useful for the customers for the debuuging and they are asking for it 14:31:56 so don't we need to get nova to supply a name when creating the port then? 14:32:14 yes, we do 14:32:33 sukhdev_: Is there a bug in nova filed for this? I think that's the route to go here. 14:32:53 Shall I file a bug for Nova for this? 14:33:31 sukhdev_: makes sense to me, along with a patch 14:33:46 OK, that's all I had today. 14:33:52 sounds good - thanks for the input 14:34:03 Lets see if we can get L2 Population in today! 14:34:08 #endmeeting