21:00:39 <carl_baldwin> #startmeeting networking 21:00:40 <openstack> Meeting started Mon Aug 3 21:00:39 2015 UTC and is due to finish in 60 minutes. The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:43 <openstack> The meeting name has been set to 'networking' 21:00:51 <Sukhdev> hello 21:00:53 <fitoduarte> . 21:01:07 <carl_baldwin> #link https://wiki.openstack.org/wiki/Network/Meetings 21:01:13 <fitoduarte> hi 21:01:20 <carl_baldwin> #topic Announcements / Reminders 21:01:25 <nanguyen> Hi 21:01:28 <carl_baldwin> #link https://launchpad.net/neutron/+milestone/liberty-2 21:01:30 <kevinbenton> hi 21:01:40 <emagana> hello all! 21:01:56 <carl_baldwin> There is a reminder about code reviewing on the agenda: 21:01:56 <xgerman> hi 21:02:09 <carl_baldwin> “We require 2 +2 votes before merging code” 21:02:16 <carl_baldwin> #link https://wiki.openstack.org/wiki/StableBranch#Processes 21:02:33 <carl_baldwin> #link http://docs.openstack.org/infra/manual/developers.html#code-review 21:02:42 <carl_baldwin> … and a general reminder about Neutron policies. 21:02:50 <carl_baldwin> #link http://git.openstack.org/cgit/openstack/neutron/tree/doc/source/policies 21:02:56 <carl_baldwin> #topic Bugs 21:03:36 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bug/1461172 21:03:36 <openstack> Launchpad bug 1461172 in neutron "neutron.tests.functional.agent.test_l3_agent.MetadataL3AgentTestCase.test_access_to_metadata_proxy times out intermittently" [High,Confirmed] 21:03:36 <uvirtbot> Launchpad bug 1461172 in neutron "neutron.tests.functional.agent.test_l3_agent.MetadataL3AgentTestCase.test_access_to_metadata_proxy times out intermittently" [High,Confirmed] 21:03:38 <uvirtbot> Launchpad bug 1461172 in neutron "neutron.tests.functional.agent.test_l3_agent.MetadataL3AgentTestCase.test_access_to_metadata_proxy times out intermittently" [High,Confirmed] https://launchpad.net/bugs/1461172 21:04:20 <carl_baldwin> amuller may not be around, anyone else know anything about this bug? 21:04:38 <kevinbenton> i've seen it happen 21:04:43 <kevinbenton> but other than that, no :) 21:05:00 <carl_baldwin> I’ll follow up on it. 21:05:20 <carl_baldwin> #action carl_baldwin will follow up on https://bugs.launchpad.net/neutron/+bug/1461172 21:05:20 <openstack> Launchpad bug 1461172 in neutron "neutron.tests.functional.agent.test_l3_agent.MetadataL3AgentTestCase.test_access_to_metadata_proxy times out intermittently" [High,Confirmed] 21:05:20 <uvirtbot> Launchpad bug 1461172 in neutron "neutron.tests.functional.agent.test_l3_agent.MetadataL3AgentTestCase.test_access_to_metadata_proxy times out intermittently" [High,Confirmed] 21:05:22 <uvirtbot> Launchpad bug 1461172 in neutron "neutron.tests.functional.agent.test_l3_agent.MetadataL3AgentTestCase.test_access_to_metadata_proxy times out intermittently" [High,Confirmed] https://launchpad.net/bugs/1461172 21:05:43 <carl_baldwin> Linuxbridge Gate Parity Bugs; 21:05:57 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bug/1312016 21:05:57 <openstack> Launchpad bug 1312016 in neutron "nova libvirtError: Unable to add bridge brqxxx-xx port tapxxx-xx: Device or resource busy" [High,In progress] - Assigned to Sean M. Collins (scollins) 21:05:57 <uvirtbot> Launchpad bug 1312016 in neutron "nova libvirtError: Unable to add bridge brqxxx-xx port tapxxx-xx: Device or resource busy" [High,In progress] 21:05:59 <uvirtbot> Launchpad bug 1312016 in neutron "nova libvirtError: Unable to add bridge brqxxx-xx port tapxxx-xx: Device or resource busy" [High,In progress] https://launchpad.net/bugs/1312016 21:06:21 <carl_baldwin> sc68cal: You are the current assignee. 21:07:01 <carl_baldwin> This one too: 21:07:07 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bug/1465837 21:07:07 <openstack> Launchpad bug 1465837 in neutron "Linux bridge: Dnsmasq is being passed None as an interface" [Medium,Confirmed] - Assigned to Sean M. Collins (scollins) 21:07:09 <uvirtbot> Launchpad bug 1465837 in neutron "Linux bridge: Dnsmasq is being passed None as an interface" [Medium,Confirmed] 21:07:10 <uvirtbot> Launchpad bug 1465837 in neutron "Linux bridge: Dnsmasq is being passed None as an interface" [Medium,Confirmed] https://launchpad.net/bugs/1465837 21:08:26 <sc68cal> carl_baldwin: ack - we have a fix for 1412016 - let me fetch the link 21:08:42 <sc68cal> https://review.openstack.org/193485 21:08:49 <r00tcoder> hello everyone 21:09:11 <sc68cal> I think we just need a respin to address a comment related to some new code that merged recentky 21:09:41 <sc68cal> the new BridgeInterfaceDriver class 21:10:06 <carl_baldwin> sc68cal: Thanks. 21:10:14 <sc68cal> 1465837 seems to be just noise in the logs, it doesn't appear to indicate any actual failures - so we can lower the priority 21:10:16 <carl_baldwin> Any other Bugs that should be mentioned? 21:10:51 <regXboi> not a bug (yet), but who is familiar with the experimental sideways grenade? 21:10:52 <carl_baldwin> sc68cal: I just noticed that the same thing was already discussed. 21:11:50 <sc68cal> carl_baldwin: right. we can probably lower it to low 21:11:54 <sc68cal> from medium 21:12:09 <carl_baldwin> sc68cal: ack 21:12:37 <carl_baldwin> regXboi: I’m not. Anyone who is maybe could ping you in the neutron room? 21:12:42 <regXboi> that works 21:12:52 <carl_baldwin> #topic Docs 21:12:57 <carl_baldwin> emagana: ping 21:13:05 <emagana> carl_baldwin: hi there! 21:13:33 <armax> regXboi: russellb was playing with it a bit 21:13:33 <emagana> WIP with the networking guide but as far as I know nothing to critical report besides keep asking for reviews 21:13:53 <emagana> Our wiki shows the most important ones 21:13:56 <regXboi> armax: ack 21:14:23 <carl_baldwin> emagana: Which wiki page? 21:14:29 <emagana> it seems that Matt is not around, so not sure if he got anything else 21:14:33 <carl_baldwin> Are they on the meeting page? 21:14:49 <emagana> #link http://wiki.openstack.org/Network/Meetings 21:14:54 <emagana> Yes! 21:15:08 <carl_baldwin> emagana: Thanks. It does look like they’re all there. 21:15:24 <emagana> carl_baldwin: nothing else! 21:15:39 <carl_baldwin> Thanks, emagana 21:15:54 <carl_baldwin> Now on to the on-demand agenda... 21:16:22 <carl_baldwin> #topic 3rd party Ci systems, Can they vote -1? 21:16:42 * sc68cal grabs his pointy stick 21:16:47 <carl_baldwin> #link https://review.openstack.org/#/c/207198/ 21:18:00 <carl_baldwin> Maybe this should be saved for mestery 21:18:14 <carl_baldwin> Anyone keen to discuss this now? 21:18:40 <carl_baldwin> #topic Liberty-3 BPs and reviews 21:18:59 <carl_baldwin> Reminder to reviewers to focus on these reviews. 21:19:02 <carl_baldwin> #link https://launchpad.net/neutron/+milestone/liberty-3 21:20:00 <carl_baldwin> Didn’t someone create a dashboard for milestone reviews in gerrit a while back? That might be useful again. 21:20:28 * carl_baldwin finds it a little more difficult to focus on a launchpad milestone to find gerrit reviews. 21:20:58 <carl_baldwin> Moving on... 21:21:02 <kevinbenton> i think dougwig had one 21:21:15 <sc68cal> I have a procedural question - the vlan aware vms spec 21:21:19 <kevinbenton> but it was basically a huge OR statement 21:21:37 <sc68cal> so, we merged the proposal, but I don't think we've seen a reply from anyone on the ML when mestery sent a mail to the ML about the status of the work 21:21:38 <carl_baldwin> kevinbenton: That’s pretty much what I remember about it too. 21:21:52 <kevinbenton> sc68cal: if there is no reply i think i will take over that spec 21:21:59 <sc68cal> and I think we've been pushing jroll to depend on that work for ironic 21:22:06 <sc68cal> s/we've/I have/g 21:22:08 <jroll> o.o 21:22:17 <jroll> oh, right 21:22:34 <sc68cal> or is it the vlan transparent one? or are they the same 21:22:42 <kevinbenton> not the same 21:23:00 <sc68cal> are they both in the same state? I know we have the API extension merged but has any work been done in the reference implementation for it? 21:23:06 <kevinbenton> jroll: the use case is for tagging to baremetal when a ToR ML2 driver isn't present, correct? 21:23:17 <kevinbenton> sc68cal: vlan transparent is basically a flag 21:23:23 <kevinbenton> sc68cal: that IS the implementation :) 21:23:39 <kevinbenton> sc68cal: vlan transparent just means you can pass tagged frames and they won't be stripped 21:23:47 <carl_baldwin> Does this have overlap with the next topic? (Ironic Provider Networks) 21:23:51 <jroll> kevinbenton: there's a number of use cases for baremetal using vlan tagging 21:23:55 <sc68cal> carl_baldwin: yes 21:24:09 * carl_baldwin had a hunch 21:24:11 <carl_baldwin> #topic Ironic provider networks 21:24:21 <carl_baldwin> #link https://review.openstack.org/#/c/152703/ 21:25:06 <kevinbenton> let me provide my quick tldr of this 21:25:11 <jroll> so, we talked about this last week. mestery_afk was going to investigate if vlan aware vms "just" solves this 21:25:27 <kevinbenton> there are environments where ports need to be told what to tag 21:25:59 <kevinbenton> either because there is no tor driver so it can't untag onto the correct vlan via the work Sukhdev et al have been working on 21:26:19 <kevinbenton> or because it just needs to access multiple networks 21:26:30 <kevinbenton> via one physical port 21:26:36 <kevinbenton> jroll: is that right? 21:27:06 <jroll> kevinbenton: there's also ToR drivers that require the instance to tag packets, but yes close enough 21:27:30 <kevinbenton> jroll: ok 21:27:41 <kevinbenton> vlan-aware-vms should solve 21:27:42 <kevinbenton> this 21:27:49 <kevinbenton> it lets us define a trunk port 21:27:59 <jroll> that's what I'm hearing, I'm also hearing nobody is actually working on it 21:28:02 <kevinbenton> and say, "network x should be on tag y" 21:28:21 <Sukhdev> jroll kevinbenton: for for - if we configured the "native vans" - that is equivalent to access port (i.e. untagged) 21:28:28 <Sukhdev> s/for/tor 21:28:41 <kevinbenton> Sukhdev: correct, but there are cases where the native vlan thing won't work 21:28:47 <kevinbenton> Sukhdev: either because they are missing a tor driver 21:28:59 <kevinbenton> Sukhdev: or because the tor driver is fussy and demands tags 21:29:33 <kevinbenton> jroll: you are correct that nobody appears to be working on it 21:29:49 <kevinbenton> jroll: i was waiting until the end of this week to see if the owner would respond 21:29:56 <kevinbenton> jroll: if not, i will take over and implement the spec 21:30:00 <jroll> kevinbenton: got it. 21:30:04 <kevinbenton> jroll: because i'm quite familiar with it 21:30:12 <jroll> looks like nova has punted this to M anyway 21:30:16 <jroll> so not a huge loss 21:30:21 <jroll> (time-wise) 21:30:26 <pcarver> Ericsson has a working implementation of VLAN aware VMs, but I don't have any info to offer on the status of the contribution to Neutron 21:30:41 <kevinbenton> jroll: we might be able to get into L if they see how simple the nova side should be :) 21:30:58 <sc68cal> pcarver: sadly that doesn' 21:30:59 <jroll> kevinbenton: heh, yeah maybe :P 21:31:00 <sc68cal> pcarver: help us 21:31:18 <kevinbenton> pcarver: right, i think that was based on an old version of the spec though that had regular ports 21:31:29 <kevinbenton> pcarver: instead of a new trunk port thingy 21:31:32 <sc68cal> pcarver: it would be nice if Ericsson was more active in the community :( 21:31:36 <JoshNang> kevinbenton: i'm more than happy to try getting an exception for the patch 21:31:56 <kevinbenton> JoshNang: awesome. 21:32:01 <kevinbenton> let's follow up on this next week 21:32:44 <kevinbenton> no point in asking for an exception if there is some big issue on the neutron side 21:32:44 <pcarver> sc68cal: I'll reach out to them and ask what their plans are. We're running their older implementation in production so I have a strong interest in them getting it into trunk. 21:32:53 <JoshNang> kevinbenton: wfm, though it might be too late for them to accept it. they're aiming to merge the code by next mon for exceptions 21:33:07 <sc68cal> pcarver: yes, that would be helpful, since that would prevent duplication of effort re kevinbenton 21:33:08 <JoshNang> kk 21:33:19 <kevinbenton> ok 21:33:41 <kevinbenton> pcarver: if it's the code i saw before, that won't be accepted as is :) 21:33:59 <kevinbenton> pcarver: because it used a regular neutron port for the trunk port 21:34:32 <kevinbenton> which doesn't match the spec 21:34:38 <pcarver> kevinbenton: I'm not saying it should be, I want the right implementation. But they do know it's a priority for us and they also know that what they delivered to us was a stopgap measure. 21:35:13 <kevinbenton> pcarver: ack 21:35:17 <carl_baldwin> I hear we’re going to follow-up on this next week. Is someone taking action for this week? 21:35:42 <jroll> I think the action item is "wait to see if anyone is working on the vlan aware VMs feature", right? 21:36:13 <carl_baldwin> kevinbenton: Did you have an action in mind? 21:36:32 <kevinbenton> Yes, wait until the end of the week 21:36:40 <carl_baldwin> ok 21:36:51 <kevinbenton> If no response, I'll start on it right away 21:36:55 <pcarver> Officially we want someone to respond to Kyle's email on the -dev list. Backchannel, I'll send a direct email to a few folks and see if I can prompt them to followup on list. 21:36:57 <carl_baldwin> kevinbenton: ack 21:37:08 <carl_baldwin> #topic Concrete plan to merge back pecan and QoS work 21:37:20 <carl_baldwin> #topic https://review.openstack.org/#/q/project:openstack/neutron+branch:feature/pecan+status:open,n,z 21:37:31 <kevinbenton> jroll: maybe we can preemptively figure out what it will look like on the Nova side... 21:37:46 <kevinbenton> jroll: and submit that code 21:37:58 <kevinbenton> jroll: and bug fix it later :) 21:38:16 <jroll> kevinbenton: heh, I'll poke 21:38:25 <kevinbenton> For pecan, there is still more stuff to be done before it's ready to merge 21:38:40 <carl_baldwin> kevinbenton: ack 21:38:49 <carl_baldwin> #topic partial upgrade support 21:39:21 * carl_baldwin thinks this on-demand agenda is getting unwieldy 21:39:35 <carl_baldwin> armax: russellb: Your name is on this. 21:39:37 <carl_baldwin> #link http://lists.openstack.org/pipermail/openstack-dev/2015-June/067156.html 21:41:08 <armax> carl_baldwin: hi 21:41:19 <carl_baldwin> armax: hi 21:41:21 <armax> carl_baldwin: that clearly went nowhere 21:42:01 <carl_baldwin> armax: ack 21:42:09 <carl_baldwin> #topic Flow classifier work 21:42:19 <carl_baldwin> #link https://etherpad.openstack.org/p/flow-classifier 21:42:55 <carl_baldwin> Nobody in particular is tagged on this topic. 21:43:46 <kevinbenton> armax told me he wanted to do that :) 21:44:28 <sc68cal> I've been nosy in that part of neutron, via SFC - but it seems like there hasn't been any cross-collaboration 21:44:37 <sc68cal> everyone is doing their own thing 21:45:09 * kevinbenton is shocked! 21:45:38 * regXboi misquotes: "kevinbenton: here are your winnings, sir" 21:45:44 <markmcclain> sc68cal: right.. kind of stinks 21:46:01 <armax> kevinbenton: is that so? 21:46:18 <pcarver> sc68cal: any particular reviews or specs you would want the SFC folks to look at? 21:46:20 <sc68cal> I just hope I'm not dooming us to that XKCD comic about standards - https://xkcd.com/927/ 21:46:40 <kevinbenton> armax: i was invoking you to come to the rescue 21:46:49 <pcarver> We separated out the flow classifier because it seems obvious that it applies to more than SFC 21:47:08 <sc68cal> pcarver: looks like that etherpad has some reviews, we may need to reach out to folks and organize 21:47:12 <pcarver> but I haven't yet come across prior implementations that we should have used instead 21:48:16 <sc68cal> https://review.openstack.org/#/c/190463/3 21:49:25 <pcarver> sc68cal: I'll take a look at that one 21:49:34 <carl_baldwin> We have a few more things to cover on the agenda… Okay to move on? 21:49:41 <sc68cal> carl_baldwin: ack 21:50:11 <markmcclain> sc68cal, pcarver: there are crud/rest update issues with that proposal 21:50:13 * carl_baldwin not sure if any of the other topics will solicit any more discussion though. 21:50:50 <carl_baldwin> Let me ask: In the last 10 minutes, are there topics on the agenda that we should be sure to hit? 21:51:07 <scheuran> carl_baldwin, I would like to bringup the macvtap stuff 21:51:18 <scheuran> carl_baldwin, last point on the agenda 21:51:29 <carl_baldwin> #topic macvtap ml2 driver and agent 21:51:34 <carl_baldwin> scheuran: The floor is yours. 21:52:00 <scheuran> it's about adding macvtap ml2 driver and agent to neutron 21:52:09 <scheuran> opened a rfe for it: https://bugs.launchpad.net/neutron/+bug/1480979 21:52:09 <openstack> Launchpad bug 1480979 in neutron "Adding macvtap ml2 driver and agent" [Undecided,New] 21:52:10 <uvirtbot> Launchpad bug 1480979 in neutron "Adding macvtap ml2 driver and agent" [Undecided,New] 21:52:11 <uvirtbot> Launchpad bug 1480979 in neutron "Adding macvtap ml2 driver and agent" [Undecided,New] https://launchpad.net/bugs/1480979 21:52:22 <scheuran> Kyle decided that macvtap agent and ml2 driver should land in the neutron tree 21:52:35 <scheuran> After discussion with a few folks, I see 2 options for it 21:52:42 <scheuran> #1 Copy (duplicate) required agent code like in the past. 21:52:51 <scheuran> #2 Extract a common base class for macvtap, linuxbridge and sriov-nic (impls are close to each other). Purpose: Sharing base agent code. 21:53:12 <scheuran> (But start with macvtap only in liberty - Others can follow wit Mitaka) 21:53:32 <sc68cal> scheuran: you sent a post to the ML about this today, right? 21:53:41 <scheuran> I wanted to hear your opinions on that - which way might be the best to move forward? 21:53:42 <scheuran> right 21:54:10 <sc68cal> scheuran: I've only read about halfway through, maybe we can discuss on the ML 21:54:14 <scheuran> ovs can not be covered with this base class - as it diverged too much from the rest over time 21:54:36 <markmcclain> yeah.. would like to read and discuss on ML as weel 21:54:39 <scheuran> sc68cal, sure also fine 21:54:56 <scheuran> any input is welcome to figure out a good direction! 21:55:23 <sc68cal> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/071207.html 21:55:41 <carl_baldwin> Let’s take it there and maybe follow up next week if a resolution is not found. 21:55:44 <scheuran> sc68cal, perfekt just was looking for it, too thanks! 21:55:48 <carl_baldwin> sc68cal: Thanks for the link. 21:56:08 <carl_baldwin> We have five minutes left. Any other requests for agenda items? 21:56:15 <sc68cal> scheuran: I will note I have some patches to the LB agent to make it more structured like the OVS agent is 21:56:29 <regXboi> move to take back the time and go get work done 21:56:49 <carl_baldwin> regXboi: +1 21:57:00 <carl_baldwin> I’m happy to give back 3 minutes. 21:57:12 <carl_baldwin> going once... 21:57:20 <scheuran> sc68cal, ok, let's discuss via ML or synchup tomorrow directly 21:57:24 <carl_baldwin> twice… 21:57:31 <carl_baldwin> #endmeeting