15:00:24 <mlavalle> #startmeeting neutron_l3
15:00:29 <openstack> Meeting started Thu Nov  1 15:00:24 2018 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:32 <openstack> The meeting name has been set to 'neutron_l3'
15:00:48 <ralonsoh> hi
15:00:56 <haleyb> hi
15:01:26 <Swami> hi
15:01:52 <njohnston> o/
15:02:03 <mlavalle> #topic Announcements
15:02:36 <mlavalle> The Stein-2 milestone is already in progress
15:03:33 <mlavalle> I mentioned during the Neutron weekly meeting that we are not cutting releases in each milestone anymore
15:04:04 <mlavalle> in each intermdediate milestones we will release stable branches,
15:04:08 <mlavalle> neutron-lib
15:04:36 <mlavalle> The Summit in Berlin is in a week and a half
15:05:18 <mlavalle> Since I have to be there for meetings on the 10th, I'll start my trip next Thursday
15:05:31 <mlavalle> so I will miss the next two meetings
15:05:55 <mlavalle> do you want to run the next two meetings?
15:06:01 <mlavalle> or cancel one or both?
15:06:30 <haleyb> i can run if others will be here and not at the summit
15:06:36 <Swami> mlavalle: you can cancel one
15:06:59 <Swami> I am not attending Summit
15:07:12 <mlavalle> so how about haleyb runs the meeting next week and we cancel the one on the 15th?
15:07:17 <mlavalle> would that work?
15:07:28 <Swami> mlavalle: sounds good
15:07:30 <haleyb> +1
15:07:34 <mlavalle> cool
15:07:48 <mlavalle> I'll send a message to the ML after the meeting
15:08:00 <mlavalle> Any other announcements?
15:09:04 <mlavalle> There is something I also want to share with the team
15:09:25 <mlavalle> I have been appointed to the StarlingX Technical Steering Committee
15:09:56 <mlavalle> My employer was asked to nominate one person and I was the lucky one
15:10:16 <Swami> mlavalle: congratulations!
15:10:18 <njohnston> Congrats!
15:10:22 <mlavalle> I don't expect this to affect my duties in Neutron or this team
15:10:36 <mlavalle> but I want all you to be aware
15:10:48 <njohnston> It's a reflection of all the quality feedback you gave the StarlingX proposals at the PTG :-)
15:11:13 <mlavalle> njohnston: you are all my paryners in crime there :-)
15:11:23 <mlavalle> ok, moving on
15:11:27 <mlavalle> #topic Bugs
15:11:38 <mlavalle> Swami: please fire away
15:11:54 <Swami> mlavalle: thanks
15:12:03 <Swami> There are no new bugs this week.
15:12:07 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1786272
15:12:07 <openstack> Launchpad bug 1786272 in neutron "Connection between two virtual routers does not work with DVR" [Medium,In progress] - Assigned to Slawek Kaplonski (slaweq)
15:12:38 <Swami> The patch is ready to be blessed. #link https://review.openstack.org/#/c/597567/
15:12:47 <Swami> I think it is good to go.
15:12:56 <Swami> The next one in the review list is
15:13:26 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1796491
15:13:26 <openstack> Launchpad bug 1796491 in neutron "DVR Floating IP setup in the SNAT namespace of the network node and also in the qrouter namespace in the compute node" [Medium,In progress] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
15:13:51 <Swami> Here is the patch for review #link https://review.openstack.org/#/c/609924/
15:14:05 <Swami> haleyb: thanks for your review comments. I have addressed your comments.
15:14:27 <haleyb> Swami: thanks, will take a look
15:14:27 <Swami> I still see some zuul failure, I have issued a recheck, let me see how it goes.
15:14:36 <Swami> The next one in the list is
15:15:26 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1774459
15:15:26 <openstack> Launchpad bug 1774459 in neutron "Update permanent ARP entries for allowed_address_pair IPs in DVR Routers" [High,Confirmed] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
15:15:42 <Swami> This is the one that I am currently working on. Right now still it is a WIP.
15:15:57 <Swami> #link https://review.openstack.org/#/c/601336/
15:16:26 <mlavalle> I need to look at it
15:16:30 <mlavalle> sorry for the delay
15:16:38 <Swami> mlavalle: My questions and doubts on this patch was clarified by tidwellr and myself. So I am progressing and not blocked.
15:16:45 <mlavalle> ah ok
15:16:48 <mlavalle> great
15:17:06 <Swami> Right now I was able to successfully add a flow to the ARP_RESPONDER table when the GARP packet comes out.
15:17:25 <Swami> I may have to add code to add a flow also on the ingress path.
15:17:51 <Swami> So right now it seems positive, but might involve more work.
15:18:15 <Swami> mlavalle: haleyb: any early comments would be helpful.
15:18:22 <mlavalle> will do
15:18:35 <haleyb> ack
15:18:52 <Swami> thanks
15:18:59 <Swami> the next one is #link https://bugs.launchpad.net/neutron/+bug/1796824
15:18:59 <openstack> Launchpad bug 1796824 in neutron "Port in some type of device_owner should not allow update IP address" [Medium,In progress] - Assigned to LIU Yulong (dragon889)
15:19:23 <Swami> This patch is also up for review. #link https://review.openstack.org/612969
15:19:57 <liuyulong> and this: https://review.openstack.org/#/c/608909/
15:21:28 <mlavalle> added to my review pile
15:21:46 <Swami> liuyulong: sorry I missed the neutron-lib one thanks for posting it.
15:22:03 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1794991
15:22:03 <openstack> Launchpad bug 1794991 in neutron "Inconsistent flows with DVR l2pop VxLAN on br-tun" [Undecided,New]
15:22:46 <Swami> This bug I am not able to reproduce it locally. I am still trying to reproduce it. Untill we reproduce the problem, we don't know what is causing this problem.
15:23:53 <Swami> One of the related issue that I have seen is, if for any reason the DHCP tap interface goes down and comes up and if there is a VM that comes in at that time, there may be a RACE where the UNICAST-to-Tun flow rule for the dHCP tap interface is not created and so the VM does not get an IP.
15:24:01 <Swami> The solution is to restart the VM.
15:24:05 <haleyb> they only see it on Pike, if that matters
15:24:25 <Swami> haleyb: Yes I tried to reproduce this in Pike, but still couldn't
15:24:34 <haleyb> ah, ok
15:25:01 <Swami> So I was not able to reproduce the vxlan flow missing. But I will try to reproduce it
15:25:10 <Swami> That's all I have for today.
15:25:16 <Swami> mlavalle: back to you.
15:25:25 <mlavalle> Thanks Swami
15:27:28 <liuyulong> https://bugs.launchpad.net/neutron/+bug/1796824 one more thing about this bug, the patches are including some API behavior change, so we should approve it first.
15:27:28 <openstack> Launchpad bug 1796824 in neutron "Port in some type of device_owner should not allow update IP address" [Medium,In progress] - Assigned to LIU Yulong (dragon889)
15:27:31 <mlavalle> I wanted to comment on the bug about enabling IPv6 forwarding in HA routers. You are working on that one haleyb?
15:27:46 <haleyb> mlavalle: yes, it's on my plate
15:28:04 <mlavalle> yeah, since I assigned it to you, I am having trouble finding it
15:28:07 <mlavalle> thanks
15:28:25 <haleyb> i can find it
15:28:36 <mlavalle> yes, please
15:28:57 <haleyb> https://review.openstack.org/#/c/613396/
15:29:06 <haleyb> https://bugs.launchpad.net/neutron/+bug/1787919
15:29:06 <openstack> Launchpad bug 1787919 in neutron "Upgrade router to L3 HA broke IPv6" [High,In progress] - Assigned to Brian Haley (brian-haley)
15:29:44 <haleyb> i just threw that functional test out there, but i need to debug it locally
15:29:46 <mlavalle> the review is still wip
15:30:40 <mlavalle> and I can see you are including the ipv6_ra set up as well
15:30:44 <mlavalle> thanks
15:31:12 <haleyb> yes, although the code seems correct i wanted to verify it worked better on my setup
15:31:33 <Swami> haleyb: what is the bug related to 'ipv6_ra' setup
15:31:35 <mlavalle> yes, the verification is where I got stuck. Thanks for working on it
15:32:03 <mlavalle> Swami: The bug is about ha routers not working with IPv6
15:32:19 <Swami> mlavalle: ok the same bug. I thought it is a different one.
15:32:29 <haleyb> https://bugs.launchpad.net/neutron/+bug/1787919/comments/9 talks about RA
15:32:29 <openstack> Launchpad bug 1787919 in neutron "Upgrade router to L3 HA broke IPv6" [High,In progress] - Assigned to Brian Haley (brian-haley)
15:32:31 <mlavalle> and the submitter, among other things, suggested also setiing ipv6_ra in the fix
15:33:35 <mlavalle> liuyulong: thanks for bringing that bug / rfe up
15:33:42 <mlavalle> I'll take a look at it today
15:33:53 <haleyb> when we changed the ha code to only enable forwarding on the master router at start, we created this issue.  part of the problem is we don't want to change the forwarding setting unnecessarily since it causes dataplane disruption
15:34:12 <liuyulong> mlavalle, great, thanks
15:34:13 <haleyb> damn MLDv2
15:34:35 <mlavalle> exactly, haleyb :-)
15:34:59 <haleyb> so i need to test and watch tcpdump at the same time
15:35:07 <mlavalle> yeap
15:35:48 <mlavalle> ok, next one is https://bugs.launchpad.net/neutron/+bug/1789434
15:35:48 <openstack> Launchpad bug 1789434 in neutron "neutron_tempest_plugin.scenario.test_migration.NetworkMigrationFromHA failing 100% times" [High,Confirmed] - Assigned to Manjeet Singh Bhatia (manjeet-s-bhatia)
15:36:17 <mlavalle> and the proposed fix is here: https://review.openstack.org/#/c/611461/
15:36:32 <mlavalle> I can see that haleyb and Swami have provided feedback
15:37:04 <mlavalle> Finally
15:37:15 <mlavalle> I am working on this one https://bugs.launchpad.net/neutron/+bug/1795870
15:37:15 <openstack> Launchpad bug 1795870 in neutron "Trunk scenario test test_trunk_subport_lifecycle fails from time to time" [High,Confirmed] - Assigned to Miguel Lavalle (minsel)
15:37:28 <mlavalle> I am in the process of debigging it
15:37:42 <mlavalle> it's been hard to isolate
15:37:58 <mlavalle> so I will push a DNM patch soon to add some logging
15:38:13 <mlavalle> any other bugs we should discuss today?
15:39:34 <mlavalle> ok let's move on
15:39:46 <mlavalle> #topic Floating IPs and vnic_type
15:40:10 <ralonsoh> #link https://review.openstack.org/#/c/611059/
15:40:19 <mlavalle> Yesterday I came across this patch: https://review.openstack.org/#/c/611059
15:40:30 <mlavalle> you beat me to it, ralonsoh
15:40:58 <mlavalle> The reason I am bringing this up here is that I would like to give consistent feedback to ralonsoh
15:42:01 <mlavalle> in particular, I would like us to agree that is is ok for L3 to use the services of L2
15:42:09 <mlavalle> that's why L3 is above L2
15:42:46 <mlavalle> so it is ok for L3 code to call methods in the the core plugin
15:43:25 <mlavalle> For more details, please read he comment I left in the review yesterday
15:43:47 <liuyulong> IMO, it's ok for both approach. The current is something like, L3 try to bind floating IP to L2 port, but L2 port is not ready, L2 reject it. mlavalle's suggestion is L3 check the port in his own scope by calling L2 methods.
15:44:29 <ralonsoh> haleyb, what's your opinion?
15:44:33 <Swami> mlavalle: will take a look at it, I have added myself to the review.
15:44:42 <haleyb> yes, i think it's good.  my original thought was to abstract it via the registry code, but putting it in utils would be fine.  i could have just had a related change on my mind when i proposed that.  as long as we keep the layering intact
15:44:49 <haleyb> took we a while to type
15:45:13 <ralonsoh> ok, I'll refactor the patch
15:45:23 <haleyb> because i think the original code had the vnic type in the l3 code
15:45:44 <haleyb> glad mlavalle came along :)
15:46:08 <haleyb> as liuyulong said, they both work but miguel's suggestion should be faster
15:46:17 <mlavalle> thanks. I just wanted to avoid giving conflicting feedback
15:46:32 <ralonsoh> thanks everybody
15:46:40 <Swami> mlavalle: I agree with you
15:46:40 <mlavalle> thanks ralonsoh. will look for the next iteration
15:46:58 <haleyb> thanks for working on it ralonsoh
15:47:22 <mlavalle> ok, let's move on
15:47:28 <mlavalle> #topic On demand agenda
15:47:41 <mlavalle> anything else we should discuss today?
15:48:16 <mlavalle> ok team. Thanks for attending
15:48:29 <mlavalle> have fun without me next week :-)
15:48:34 <mlavalle> #endmeeting