15:01:18 <mlavalle> #startmeeting neutron_l3
15:01:18 <openstack> Meeting started Thu Oct 12 15:01:18 2017 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:19 <Swami> hi
15:01:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:22 <openstack> The meeting name has been set to 'neutron_l3'
15:01:24 <haleyb> hi
15:01:27 <mlavalle> hi
15:01:30 <davidsha> Hi
15:01:46 <mlavalle> nice to be in 'known territory'
15:02:05 <mlavalle> #topic Announcements
15:02:37 <mlavalle> Q-1 milestone is next week
15:02:51 <mlavalle> please keep that in mind
15:03:17 <mlavalle> We are less than one week away from the summit in Sydney
15:03:24 <mlavalle> a month, that is
15:04:05 <mlavalle> haleyb, davidsha: you'll be missed Down Under
15:04:21 <davidsha> mlavalle: :(
15:04:31 <mlavalle> Swami and I will do all the beer drinking for you :-)
15:04:35 <davidsha> :P
15:04:39 <Swami> mlavalle: sure
15:04:53 <mlavalle> although we are not beer drinkers
15:05:03 <haleyb> damn, beer :)
15:05:29 <davidsha> Should that be logged as an agreed action :P
15:05:39 <mlavalle> Finally, I made a failed a attempt earlier today to host the drivers meeting at an alternate time
15:05:52 <mlavalle> some drivers are available at the new time
15:06:07 <mlavalle> so please stay tuned for further annoucements on this topic
15:06:40 <mlavalle> we will settle on an alternate time that is better for people in the Europe, Middle East and the US East Coast
15:07:00 * mlavalle felt like a sucker earlier today
15:07:14 <mlavalle> any other annoucements?
15:07:18 <davidsha> mlavalle: There isn't a drivers meeting later this evening then?
15:07:29 <mlavalle> davidsha: it might happen
15:07:36 <davidsha> kk
15:08:03 <Swami> mlavalle: I saw that even last week it was a very short meeting.
15:08:20 <mlavalle> no last week we had a good meeting
15:08:46 <mlavalle> what you saw was armax testing whether we could run a meeting in the Neutron channel
15:09:06 <mlavalle> ok, moving on
15:09:15 <Swami> mlavalle: Ok now I got it.
15:09:23 <mlavalle> #topic Bugs
15:09:35 <mlavalle> please go ahead Swami
15:09:37 <Swami> mlavalle: thanks
15:10:06 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1716782
15:10:08 <openstack> Launchpad bug 1716782 in neutron "DVR multinode job has linuxbridge agent mech driver defined" [Low,Confirmed] - Assigned to Brian Haley (brian-haley)
15:10:40 <Swami> This is a new bug that was filed and we did not discuss on this.
15:11:02 <Swami> haleyb: you did file this bug.
15:11:26 <haleyb> yes and i have a devstack fix, might just need a push
15:11:35 <Swami> haleyb: Do you think that we need to remove the linuxbridge mech driver.
15:11:52 <Swami> haleyb: Ok, once you push it in then we can review it.
15:12:00 <haleyb> let me find the link
15:12:02 <mlavalle> is that a fix in the devstack repo?
15:12:14 <haleyb> https://review.openstack.org/#/c/503741/
15:12:28 <haleyb> oh, it's already hit devstack master, that's just a pike backport
15:12:52 <haleyb> let me update the bug, somehow didn't get updated
15:13:25 <Swami> haleyb: ok so we can add backport-potential to it.
15:13:30 <Swami> and close this bug.
15:13:46 <Swami> The next in the list is
15:13:49 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1718788
15:13:50 <openstack> Launchpad bug 1718788 in neutron "DVR: Migrate centralized unbound floatingip to the respective host when the port is bound" [High,In progress] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
15:14:04 <Swami> This patch is still failing gate on merge.
15:14:38 <Swami> #link https://review.openstack.org/#/c/505324/ patch link
15:15:01 <Swami> Issued a recheck yesterday and still failing with volume tests.
15:15:29 <Swami> haleyb: we should probably skip this volume test similar to what we did a year ago.
15:16:09 <haleyb> Swami: did we add a decorator?
15:16:30 <Swami> haleyb: yes I think so for one of the volume tests.
15:16:58 <Swami> The next in the list is
15:17:01 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1718345
15:17:02 <openstack> Launchpad bug 1718345 in neutron "ml2_distributed_port_bindings not cleared after migration from DVR" [Medium,In progress] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
15:17:27 <Swami> #link https://review.openstack.org/#/c/508808/
15:18:07 <Swami> This patch is still work in progress. I have to add a functional test to validate the portbindings cleared.
15:18:49 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1716401
15:18:51 <openstack> Launchpad bug 1716401 in neutron "FWaaS: Ip tables rules do not get updated in case of distributed virtual routers (DVR)" [Undecided,New] - Assigned to Reedip (reedip-banerjee)
15:19:08 <Swami> mlavalle: Did you get any update from the FWaaS meeting on this issue.
15:19:24 <Swami> reedip: ping
15:19:36 <mlavalle> no I didn't, I was trying to run the drivers meeting
15:20:13 <Swami> mlavalle: ok I don't see reedip here, he is not responding. I will check back later on this.
15:20:20 <mlavalle> ok
15:20:29 <Swami> mlavalle: Maybe I will ping Sridark and let him know.
15:20:53 <mlavalle> yeah, they have their own channel, #openstack-fwaas
15:21:20 <Swami> mlavalle: yes will ping them on the fwaas channel.
15:21:29 <Swami> The last one for today is
15:21:32 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1717302
15:21:33 <openstack> Launchpad bug 1717302 in neutron "Tempest floatingip scenario tests failing on DVR Multinode setup with HA" [High,Confirmed]
15:22:13 <Swami> Still I am investigating this problem. I could not spend much time on this last week. I will see if I can pay attention to this in the coming week.
15:22:33 <haleyb> Swami: even with the two arping fixed the east-west fip tests still fail.  i added info from the duplicate just now
15:22:44 <Swami> Also I have pushed in a patch for the fullstack testing for DVR.
15:23:04 <Swami> haleyb: yes, that's my assumption.
15:23:24 <haleyb> great.  i think if we get that fixed and the trunk test the scenario test will be happy :)
15:23:35 <mlavalle> ++
15:23:44 <Swami> haleyb: hoping :)
15:24:18 <Swami> #link https://review.openstack.org/#/c/507658/ - full stack test patch
15:24:59 <Swami> I discussed this with haleyb and also with ihar. There is some setup issue seen with this patch.
15:25:22 <Swami> Which is clear at this point on why it is failing.
15:25:48 <Swami> So added a simple patch to see if the setup issue is still seen. I have also seen the setup issue in this patch.
15:26:02 <haleyb> Swami: does that require the other agent mode patch?
15:26:08 <Swami> #link https://review.openstack.org/#/c/510192/
15:26:35 <Swami> haleyb: Yes I initially had it all together. Then in order to debug the issue  I had to split it.
15:27:17 <Swami> Also if we have the agent type mode patch as a separate patch that would also help davidsha to write his tests for the dvr_bridge type.
15:27:35 <haleyb> Swami: ahh, we should link them together, either same topic, or just have second depend on first?  does it need it to pass?
15:28:00 <Swami> haleyb: Yes I will link it together today. Since the first one was failing, I did not link it.
15:28:07 <Swami> haleyb: but will do.
15:28:17 <haleyb> i.e. rebase second to first and gerrit will have them both on right side
15:28:35 <Swami> haleyb: yes will address it.
15:28:40 <haleyb> jenkins likes it now, zuul not so much
15:29:00 <mlavalle> 510192?
15:29:23 <davidsha> yup
15:29:24 <Swami> 510192 failed jenkins.
15:29:33 <haleyb> yeah, but zuul doesn't like anything, reminded of an old Life Cereal commercial about Mikey...
15:29:52 <mlavalle> I just looked at the zuul failures
15:29:58 <mlavalle> not related to the patch
15:29:59 <Swami> oops! yes zuul failure is seen not jenkins
15:30:02 <haleyb> Swami: well, it passed jenkins, maybe didn't fix the test?
15:30:08 <davidsha> jenkins has a +1 on 510192
15:30:19 <Swami> haleyb: yes the tests are still failing, that is my concern.
15:30:46 <mlavalle> those zuul failures related to file permissions is the reason they delayed the roll out again this week
15:30:53 <Swami> These two line change is in the host_desc and it should not cause the tests to fail.
15:31:23 <Swami> mlavalle: back to you. That's all I had for today.
15:31:37 <mlavalle> ok, I don't have any other bugs this week
15:31:53 <mlavalle> any other bugs we should discuss from the team this week
15:31:57 <mlavalle> ?
15:33:00 <mlavalle> #topic Openflow DVR
15:33:12 <mlavalle> davidsha: you are up
15:34:21 <davidsha> Thanks, This week I've been focused on neutron-classifier, but I've been working on testing some north south issues I've noticed.
15:35:34 <Swami> sorry just got dropped.
15:35:35 <mlavalle> any thing elase you want to share with the team
15:35:38 <mlavalle> ?
15:35:47 <davidsha> The way openflow dvr does N/S traffic is by copying the source MAC from br-ex however im having an issue with it responding
15:36:09 <davidsha> Sorry, I'm rewriting the line once or twice each time
15:36:45 <Swami> davidsha: When you say N/S is it for floatingIP or for SNAT
15:36:45 <davidsha> I'm investigating this issue at the mement, and hoping to have it resolved by the next PS
15:37:06 <davidsha> Floating IP
15:37:24 <Swami> davidsha: thanks
15:37:36 <mlavalle> is openflow dvr a name you like?
15:37:38 <sean-k-mooney> SNAT could be added later but davids current patches are intended to replace teh dvr on the compute nodes only
15:38:03 <davidsha> mlavalle: It's not quite dvr_kickass but it's do ;)
15:38:03 <Swami> mlavalle: dragonflow is also openflow based dvr.
15:38:19 <davidsha> it'll*
15:38:21 <sean-k-mooney> Swami: so is odl and ovn
15:38:40 <sean-k-mooney> but in the context of the l3 agent i think it makes sense
15:38:46 <mlavalle> yeah
15:39:40 <Swami> openflow is too generic, since everyone is using it.
15:40:08 <Swami> even the current dvr uses openflow along with namespaces.
15:40:32 <sean-k-mooney> Swami: do you have another suggestion
15:40:39 <davidsha> dvr_bridge is probably best then
15:40:58 <davidsha> As it uses OpenFlow Bridges in place of network namespaces
15:41:02 <sean-k-mooney> davidsha: that was the original name but it could be confused with linux bridge
15:41:16 <davidsha> True.
15:41:55 <Swami> sean-k-mooney: no I don't have anything right now, but you can call it no_namespace_dvr
15:42:09 <sean-k-mooney> if nameing is the main issue holding this work back though i think we are getting to a good place with this work
15:43:14 <davidsha> armax did suggest dvr_kickass if we really are stuck.
15:43:47 <davidsha> But are there any questions?
15:43:59 <mlavalle> ok, for the purposes of naming the topic in this meeting, will use dvr_kickass
15:44:05 <Swami> I like dvr_bridge
15:44:52 <mlavalle> ok, let's revisit next week
15:45:00 <mlavalle> anything else, davidsha?
15:45:01 <davidsha> +1
15:45:11 <davidsha> Not unless there are questions
15:45:24 <davidsha> but I don't think there are?
15:45:24 <Swami> nothing else from me.
15:45:39 <mlavalle> #topic Multiple port bindings
15:46:07 <mlavalle> so on my side I spent time reviewing the currently proposed implementation
15:46:33 <mlavalle> #link https://review.openstack.org/#/c/414251/
15:46:54 <mlavalle> I have decided to keep the API in the service plugin proposed there
15:47:03 <mlavalle> but don't worry, sean-k-mooney
15:47:27 <mlavalle> I will implement this in ML2 using callbacks
15:47:40 <mlavalle> that was the approach that was followed with segments
15:47:56 <sean-k-mooney> placeing it in a service plugin may allow you to use it as a mixin/callback from a monolitic plugin if not useing ml2
15:47:58 <mlavalle> which also have a service plugin for the API
15:48:33 <mlavalle> exactly, I think with this approach we get the best of both worlds
15:48:42 <mlavalle> I'll keep the service plugin
15:48:47 <sean-k-mooney> +1
15:48:49 <mlavalle> \and implement the callbacks in ML2
15:49:06 <mlavalle> and then we live the door open for other plugins
15:50:07 <sean-k-mooney> so from my side i have started to look at the code to determin how to pass the new bindings to the destination node and how to cater for mixed old+new computes.
15:50:18 <mlavalle> so expect to see over the next few days a dependent patch on the current one with the callbacks in ML2
15:51:02 <sean-k-mooney> i will update the spec with what i am discovering and relect the ml2-> service plugin change also
15:51:41 <mlavalle> from the point of view of the nova spec, you assume ml2 implementation
15:51:47 <mlavalle> can ^^^
15:52:19 <sean-k-mooney> yes well form nova ml2 vs core plugin should not be visable but ml2 is better understood
15:52:29 <mlavalle> yeap
15:53:13 <mlavalle> I think our focus over the next few days is to get the nova spec approved
15:53:42 <sean-k-mooney> yes i will try and respond to any feedback as it comes in
15:54:08 <mlavalle> right now it is failing Jenkins
15:54:21 <sean-k-mooney> and passing zuul v3
15:54:27 <mlavalle> LOL
15:54:49 <sean-k-mooney> there were dependcy issue in the jenkins runs
15:55:37 <sean-k-mooney> ill be updating the spec later today so ill hold of on rechecking for now
15:55:43 <mlavalle> ok
15:55:50 <mlavalle> sounds good
15:56:59 <mlavalle> anything else on this topic?
15:57:12 <sean-k-mooney> no not for this week.
15:57:35 <mlavalle> Thanks for the update
15:57:43 <mlavalle> #topic Open Agenda
15:58:02 <mlavalle> any other topic we should discuss in 3 minutes?
15:58:07 <mlavalle> 2
15:58:23 <davidsha> I have nothing.
15:58:27 <Swami> I have nothing
15:58:58 <mlavalle> ok team, thanks for attending
15:59:04 <mlavalle> see you next week
15:59:05 * cdent waves at mlavalle
15:59:33 * mlavalle waves back at cdent, smiling
15:59:36 * edleafe waves too
15:59:37 <mlavalle> #endmeeting