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