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