15:00:21 <mlavalle> #startmeeting neutron_l3
15:00:22 <openstack> Meeting started Thu Jun 14 15:00:21 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:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:26 <openstack> The meeting name has been set to 'neutron_l3'
15:00:29 <mlavalle> Hi there!
15:00:46 <haleyb> hi!
15:01:14 <Swami> hi
15:01:32 <mlavalle> hey haleyb, Swami
15:01:37 <janzian> o/
15:01:43 <mlavalle> hi janzian
15:02:22 <mlavalle> #topic Announcements
15:02:55 <mlavalle> Last week we released Rocky-2:
15:03:02 <mlavalle> #link  https://review.openstack.org/#/c/572666
15:03:29 <mlavalle> along with neutron-pythonclient: https://review.openstack.org/#/c/573681/
15:03:54 <mlavalle> and earlier this week we release neutron-lib 1.16.0
15:04:00 <mlavalle> #link  https://review.openstack.org/#/c/573826/
15:04:28 <mlavalle> Next milestone is Rocky-3, July 23 - 27
15:04:41 <mlavalle> That is a little lesss than 6 weeks from today
15:05:26 <mlavalle> Cll for presentations for Berlin is open until July 15th
15:05:32 <mlavalle> Call^^^^
15:05:52 <mlavalle> If you intend to give a presentation in Berlin, keep that deadline in mind
15:06:06 <mlavalle> Any other announcements from the team?
15:06:12 <haleyb> so we need to tag stable branches as well, if they have changes ?
15:06:39 <mlavalle> that's what we agreed last time we talked about it, yeah
15:06:56 <mlavalle> and to tell you the truth, I just forgot about it
15:06:56 <haleyb> i keep forgetting to update contributor docs, but that doesn't get the work done anyways :)
15:07:26 <haleyb> i will do it since i'm the face of the stable team these days
15:07:58 <mlavalle> haleyb: will you continue doing it going forward?
15:08:43 <Xubo-Zhang> hi all, is meeting at 8 or 9am PST?
15:08:44 <haleyb> mlavalle: sure
15:09:04 <mlavalle> Xubo-Zhang: Yes
15:09:38 <Xubo-Zhang> hi Miguel
15:09:43 <mlavalle> haleyb: let's talk about it in the next neutron meeting. That way we make sure amotoki is aware
15:10:02 <mlavalle> #topic Bugs
15:10:16 <mlavalle> Swami: do you want to start?
15:10:46 <Swami> sure
15:11:22 <Swami> mlavalle: you mentioned about the gate error log week before meeting.
15:11:40 <Swami> mlavalle: I wanted to discuss that first before I move on to the bugs.
15:11:46 <mlavalle> go ahead
15:12:55 <Swami> Yes I looked a the log, it seems that there is a timing issue where the 'fg' port is getting created and when there is an update to the 'fg' port that is being issued. We do have a ways to handles it and when the exception occurs it would correct itself, when the floatingIP fails.
15:13:27 <Swami> So the Error log that we were seeing in the gate was due to this self correction.
15:13:40 <Swami> I did not see anything else odd in the logs.
15:13:50 <mlavalle> so, we don't need to worry about it?
15:14:06 <Swami> Yes it is a known behavior and we don't need to worry about it.
15:14:15 <mlavalle> Cool!
15:15:01 <Swami> mlavalle: In relation to that I figured out there is one another issue that can happen, where if some process or someone accidentally deletes the 'fg' port, then I do see an issue were it can't recover by itself.
15:15:29 <Swami> mlavalle: We were seeing a similar problem downstream, but I will push in a bug and a patch to address that issue.
15:15:57 <Swami> Now coming back to existing bugs
15:16:00 <mlavalle> Thanks!
15:16:31 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1773999
15:16:32 <openstack> Launchpad bug 1773999 in neutron "Allowed Address Pairs doesn’t work after neutron-port update" [Undecided,In progress] - Assigned to Brian Haley (brian-haley)
15:17:07 <Swami> The revert patch was submitted for this bug and was reviewed. But it still fails in gate. I have added a recheck to it.
15:17:31 <Swami> #link https://review.openstack.org/#/c/572168/
15:18:30 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1776566
15:18:31 <openstack> Launchpad bug 1776566 in neutron "DVR: FloatingIP create throws an error if the L3 agent is not running in the given host" [Low,In progress] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
15:18:48 <Swami> #link https://review.openstack.org/#/c/574917/
15:18:54 <Swami> There is a patch up for review.
15:19:05 <Swami> haleyb: thanks for your  review. I have addressed your review comments.
15:19:27 <haleyb> Swami: thanks, i'll take a look
15:19:30 <Swami> But I do see a failure in the unit test with py35. I may have to rewrite the test case.
15:19:36 <mlavalle> yeah
15:19:37 <Swami> I will address it today.
15:19:52 <Swami> py27 was passing.
15:20:18 <mlavalle> that happens some times
15:20:20 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1774459
15:20:21 <openstack> Launchpad bug 1774459 in neutron "RFE: Update permanent ARP entries for allowed_address_pair IPs in DVR Routers" [Wishlist,Confirmed]
15:20:40 <Swami> haleyb: mlavalle: I have filed this RFE bug based on our discussion.
15:20:50 <Swami> haleyb: I looked at your  comment on this bug.
15:21:00 <mlavalle> and I brought it up during the last drivers meeting
15:21:43 <Swami> haleyb: we can use the approach of the keepalived_state_change, but I am worried, that since the keepalived is running only in the VM, this may or may not work for our purpose.
15:21:47 <mlavalle> haleyb made a suggestion
15:22:19 <Swami> haleyb: But I will take a look at it and see if it is possible to reuse keepalived_state_change
15:22:32 <Swami> mlavalle: yes I read his suggestion
15:22:42 <haleyb> Swami: keepalived runs in the namespace
15:23:20 <Swami> haleyb: yes, in our usecase it runs in the VM
15:23:24 <Swami> for the VRRP.
15:23:58 <mlavalle> when you say "our", who are we talking about?
15:24:02 <Swami> For the case of the l3-ha, the keepalived runs within the namespace and so the ipmonitor was usefull to track it.
15:24:28 <Swami> mlavalle: in the case of 'vrrp'
15:24:38 <mlavalle> ok
15:25:21 <Swami> haleyb: mlavalle: I will look into it and update the RFE based on my learnings and you can comment on it.
15:25:50 <mlavalle> Swami: should we treat this as a regular bug and remove the RFE tag?
15:26:31 <Swami> mlavalle: not sure, either way would work for me. If treating it as a bug is simpler, we can go that route. Since we all know the problem.
15:27:39 <mlavalle> yeah, let's keep it here. removing the rfe tag and giving it high priority, so we track it in this meeting
15:27:57 <Swami> mlavalle: ok that would work.
15:28:12 <Swami> The next is
15:28:16 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1762454
15:28:17 <openstack> Launchpad bug 1762454 in neutron "FWaaS: Invalid port error on associating ports (distributed router) to firewall group" [Medium,Triaged] - Assigned to Sridar Kandaswamy (skandasw)
15:28:55 <Swami> I triaged this one and also some to Sridhar about the issue. I have not seen any patch for this but will ping sridhar on this issue.
15:29:31 <mlavalle> shoud this be fixed from the FWaaS side?
15:30:32 <Swami> mlavalle: yes, while applying the firewall rules, today they only apply to ports with device_owner='router_interface'. They should probably be applying to ports without checking the 'device_owner'. That would solve the problem.
15:31:27 <Swami> Moreover for DVR we don't recommend applying the firewall rules to the router-ports because of the stateless router behavior in DVR. For DVR we recommend applying the firewall rules to the VM ports.
15:31:44 <mlavalle> Swami: if you don't get a hold of Sridhar by Wednesday next week, please ping me and I can bring it up in the FWaaS meeting on Thursday
15:31:53 <Swami> mlavalle: sure
15:32:22 <Swami> There are couple of stable/pike patches that needs attention.
15:32:35 <Swami> https://review.openstack.org/#/c/558585/
15:32:55 <Swami> https://review.openstack.org/#/c/559282/
15:33:20 <mlavalle> The second one is approved
15:33:36 <haleyb> waiting on the first...
15:33:42 <mlavalle> do we need to push it again?
15:33:48 <mlavalle> ah ok
15:34:02 <haleyb> i never saw the first one, will look
15:34:03 <Swami> mlavalle: yes it is dependent
15:34:06 <Swami> #link https://review.openstack.org/#/c/573785/
15:34:49 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1774463
15:34:51 <openstack> Launchpad bug 1774463 in neutron "RFE: Add support for IPv6 on DVR Routers for the Fast-path exit " [Undecided,Confirmed]
15:35:02 <Swami> mlavalle: haleyb: I also added this RFE to the list.
15:35:29 <Swami> haleyb: can you point me to the patch that you mentioned for the ipv6 work on the fip namespace.
15:36:22 <Swami> mlavalle: that's all I have from my side.
15:36:26 <Swami> mlavalle: back to you
15:37:08 <mlavalle> I have this one: https://bugs.launchpad.net/neutron/+bug/1776255
15:37:09 <openstack> Launchpad bug 1776255 in neutron "DVR scheduling checks wrong port binding profile for host in live-migration" [High,In progress] - Assigned to Kailun Qin (kailun.qin)
15:37:51 <mlavalle> haleyb and Swami have visibility of it. Fix is here:
15:37:57 <mlavalle> #link https://review.openstack.org/#/c/574370/
15:38:06 <mlavalle> just need to keep an eye on it
15:38:49 <mlavalle> The other one that I have for today is https://bugs.launchpad.net/neutron/+bug/1757482
15:38:51 <openstack> Launchpad bug 1757482 in neutron "IP address for a router interface allowed outside the allocation range of subnet" [High,In progress] - Assigned to Miguel Lavalle (minsel)
15:39:08 <Swami> mlavalle: yes I reviewed it. It fails gate.
15:39:18 <Swami> mlavalle: sure I will keep an eye on it.
15:39:45 <mlavalle> I proposed a fix for it https://review.openstack.org/#/c/575444
15:40:10 <mlavalle> earlier today. But reading the bug again I realized I didn't address all of it
15:41:03 <mlavalle> so I will re-work it today and tomorrow to make it more comprenhensive
15:41:22 <mlavalle> but I think I am in the right path, do you agree haleyb ?
15:41:37 <haleyb> mlavalle: yes, i think that part looked correct
15:41:46 <mlavalle> btw, thanks for the comment
15:42:01 <mlavalle> I will keep the entire fix in the same patch
15:42:08 <haleyb> sounds good
15:42:25 <mlavalle> so I won't change to partial-bug tag
15:43:04 <mlavalle> ok, any other bugs we should disucss today?
15:43:36 <Xubo-Zhang> yes, can we talk about dvr-bridge?
15:43:49 <mlavalle> Xubo-Zhang: that's not a bug ;-)
15:43:56 <Xubo-Zhang> oh
15:44:02 <mlavalle> let us finish this topic first
15:44:20 <Xubo-Zhang> ok
15:44:24 <mlavalle> ok, let's move on
15:44:31 <haleyb> no more bugs from me
15:44:45 <mlavalle> #topic dvr-bridge
15:44:55 <mlavalle> Xubo-Zhang: you are on
15:45:19 <Xubo-Zhang> dvr-bridge passed CI
15:45:44 <Xubo-Zhang> so is there anyone reviewing it?
15:46:29 <Xubo-Zhang> btw, how do i paste url here?
15:46:52 <Xubo-Zhang> review.openstack.org/#/c/472289
15:46:58 <Swami> Xubo-Zhang: Copy paste with a #link tag
15:47:20 <Xubo-Zhang> #link 15:42:09 Xubo-Zhang | review.openstack.org/#/c/472289                                                                                              \u2502 fnordahl      ++
15:47:23 <mlavalle> #link https://review.openstack.org/#/c/472289/
15:47:51 <Xubo-Zhang> i am new here as you can see :-)
15:48:03 <mlavalle> Thanks for the heads up. We'll take a look at it
15:48:10 <Xubo-Zhang> we want to make it to the rocky
15:48:27 <Xubo-Zhang> so what are next steps?
15:48:37 <mlavalle> we will review it
15:48:40 <Xubo-Zhang> ok
15:48:44 <Swami> Xubo-Zhang: Is there is quick start guide or a doc wiki for this work.
15:48:49 <mlavalle> I am not sure it will make it in Rocky
15:49:05 <Xubo-Zhang> cool. i will be on vacation from tomorrow til 7/4
15:49:17 <Xubo-Zhang> we still have an issue
15:49:23 <mlavalle> it is a massive patch
15:49:34 <Xubo-Zhang> yes
15:50:13 <mlavalle> so it will be hard for it to be merged by Rocky-3, especially with you gone for the next 2 weeks
15:50:33 <mlavalle> what is the issue?
15:51:37 <Xubo-Zhang> the issue is the dvr-bridge's flows seem all have the same cookie
15:52:03 <Xubo-Zhang> so when an interface was deleted, all flows was deleted
15:52:19 <Xubo-Zhang> we are working on that
15:52:43 <Xubo-Zhang> any idea how to fix that?
15:52:48 <mlavalle> are you planning to address it before you leave for vacation?
15:53:23 <mlavalle> Just assign a different cookie to the flows, I guess
15:53:55 <Xubo-Zhang> we are still working on that, I think David will continue looking into it
15:54:27 <mlavalle> ok, cool
15:54:35 <Swami> Xubo-Zhang: Do you have any quick start guide or wiki doc for this implementation details and to explain the flows
15:54:59 <Xubo-Zhang> what needs to be done to make it to Rocky?
15:54:59 <mlavalle> yeah, that would be very helpful, given the size of the change
15:55:44 <Xubo-Zhang> ok
15:55:48 <manjeets> documentation will surely help to understand and validate it !
15:56:05 <Xubo-Zhang> where do i post the docs?
15:56:29 <Swami> Post the docs as link in the patch commit message.
15:56:38 <Swami> That would help the reviewers
15:56:51 <Swami> Also post it here if you already have the docs
15:56:52 <mlavalle> it could be an etherpad: https://etherpad.openstack.org/
15:56:57 <manjeets> would it make sense to have official documentation in neutron/docs for it ?
15:57:15 <mlavalle> or as manjeets, a patch with docs
15:57:44 <Xubo-Zhang> ok
15:57:57 <mlavalle> you can propose a patch that goes in the Neutron tree: https://github.com/openstack/neutron/tree/master/doc
15:58:06 <manjeets> ++
15:58:39 <mlavalle> More precisely, add a file here: https://github.com/openstack/neutron/tree/master/doc/source/contributor/internals
15:59:01 <mlavalle> That way it leaves in the Neutron tree
15:59:18 <mlavalle> ok, running out of time
15:59:33 <mlavalle> thanks for the update Xubo-Zhang and enjoy your vacation
15:59:40 <Xubo-Zhang> thanks!
15:59:42 <Xubo-Zhang> bye
16:00:22 <mlavalle> still here?
16:00:27 <mlavalle> #endmeeting