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