15:02:13 #startmeeting neutron_l3 15:02:14 Meeting started Thu Sep 20 15:02:13 2018 UTC and is due to finish in 60 minutes. The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:18 The meeting name has been set to 'neutron_l3' 15:02:26 hi 15:02:36 hi 15:02:39 Hi Swami 15:03:11 #topic Announcements 15:03:21 hi 15:04:15 Our next milestone is Stein-1, the week of October 22nd 15:05:02 also the Berlin Summit will take place on November 13 - 15 15:05:12 I hope to see some of you there 15:05:14 hi 15:05:52 Hi 15:06:50 any other annoucements we should share with the team? 15:06:51 mlavalle: thanks for the online meeting that was very helpfull. 15:07:14 Swami: yeah, that one went particularly well 15:07:21 I think we really made progress 15:07:34 mlavalle: yes 15:07:53 I'm glad that was the case and thanks for your availability.... and for pinging us 15:08:28 ok, let's move on 15:09:03 #topic Bugs 15:09:23 Swami: please take it away 15:09:32 mlavalle: sure 15:10:05 #link https://bugs.launchpad.net/neutron/+bug/1793527 15:10:05 Launchpad bug 1793527 in neutron "[dvr_no_external][ha][dataplane down]centralized floating IP nat rules not install in every HA node" [Undecided,In progress] - Assigned to LIU Yulong (dragon889) 15:10:28 There are couple of bugs filed against HA and dvr_no_external agent mode. 15:10:33 This is one of them. 15:10:42 I just noticed it. But it has a patch up for review. 15:11:01 #link https://review.openstack.org/604094 15:11:31 I will take a look at the patch. 15:11:44 The next one in the list is 15:12:04 #link https://bugs.launchpad.net/neutron/+bug/1793529 15:12:04 Launchpad bug 1793529 in neutron "[dvr][ha][dataplane down] router_gateway port binding host goes wrong after the 'master' host down/up" [Undecided,New] 15:12:49 This is also related to dvr_no_external when the failover happens it seems the router_gateway port binding is not right. I will take a look at it. I just noticed this bug. 15:13:18 #link https://bugs.launchpad.net/neutron/+bug/1790084 15:13:18 Launchpad bug 1790084 in neutron "ERROR pyroute2.netns.nslink" [Undecided,New] 15:14:33 This is also related to dvr_no_external, where they were seeing the ERROR in logs where it was trying to remove the namespaces. I haven't had a chance to triage it. 15:14:50 Probably with a single setup we can triage all these three bugs, above. I will check it out. 15:15:16 #link https://bugs.launchpad.net/neutron/+bug/1786272 15:15:16 Launchpad bug 1786272 in neutron "Connection between two virtual routers does not work with DVR" [Medium,In progress] - Assigned to Slawek Kaplonski (slaweq) 15:15:16 i've seen that in logs, but didn't think it mattered much, maybe it does 15:15:50 haleyb: Let me check that out. 15:16:01 The next one is #link https://bugs.launchpad.net/neutron/+bug/1786272 15:16:41 I have been making progress with this patch. The last one that I am working on this patch is the Delete scenario when a VM port goes down, it should bring down its own router and the related routers. 15:16:58 slaweq: I will post an update to this patch. 15:17:12 sure Swami, thx a lot for help with this 15:17:25 slaweq: I think I have a solution, but I will test it and post it. 15:17:30 I updated some functional/unit tests for it recently 15:17:44 slaweq: yes I noticed it. 15:18:13 #link https://bugs.launchpad.net/neutron/+bug/1717302 15:18:13 Launchpad bug 1717302 in neutron "Tempest floatingip scenario tests failing on DVR Multinode setup with HA" [High,Confirmed] - Assigned to Miguel Lavalle (minsel) 15:18:24 I did see some activity on this bug in the last couple of days. 15:18:44 slaweq: so is it the wrong keepalived version that was causing this problem. 15:18:54 it looks so 15:19:12 I know that we had issues with this specific keepalived version also in functional tests recently 15:19:29 and I think that reporter of this bug also confirmed that in last comment 15:19:38 slaweq: that was a good catch. I would not have found that. 15:20:15 I still didn't have time to check exactly what is wrong with this keepalived but newer and older versions looks that are working fine 15:20:41 slaweq: ok 15:20:56 I am also investigating further this bug 15:21:14 here's what I am doing 15:21:18 mlavalle: Good, I also saw your comment yesterday on the 'localbind' 15:21:42 I am running the tests originally reported by Swami as failing in my local envrinment 15:21:57 literally as we speak 15:22:26 FloatingIpSameNetwork variations are passing 15:22:26 mlavalle: good 15:22:45 I will also test the spearte networks cases 15:22:57 mlavalle: good. 15:23:22 mlavalle: That's all I have for bugs today 15:23:27 if they pass in my local environment, I will propose a patch to neutron-tempest-plugin enabling those test cases again. It will be a DNM patch 15:23:28 mlavalle: back to you. 15:24:01 and will also propose a Neutro DNM patch dependent on ^^^^ 15:24:20 to see how it behaves in the check queue 15:24:30 mlavalle: sounds good 15:24:32 and be able to do further debugging 15:24:46 makes sense Swami, slaweq? 15:24:58 mlavalle: sure that would work 15:25:05 yes mlavalle 15:25:15 btw, all the variations of FloatingIpSameNetwork pass locally 15:25:32 ok, next one is 15:25:57 mlavalle: what fix you applied for your local testing. 15:26:04 * manjeets_ 's internet was creepy this morning 15:26:33 Swami: none 15:26:47 running the tests as they are from the tempest plugin 15:27:10 and my dev environment is DVR-HA close to master (lagging two weeks) 15:27:23 I built it the week before the PTG 15:27:47 mlavalle: ok 15:28:37 I was bugs deputy for one day yesterday, while boden was away 15:28:51 mlavalle: that's all I had for dicussion today. back to you. 15:28:58 This bug came in yesterday: https://bugs.launchpad.net/neutron/+bug/1793102 15:28:58 Launchpad bug 1793102 in neutron "ha_vrrp_health_check_interval causes constantly VRRP transitions" [Undecided,New] 15:29:50 I already configured my system with ha_vrrp_health_check_interval = 5 15:30:11 and restarted the L3 agents in the 3 nodes (allinone, compute1 and network) 15:30:24 That was last night 15:30:54 after the meeting is over, I will check my syslog to see if I find the instability the submitter reports 15:31:31 let's see if it manifested itself during the night 15:33:07 I also want to mention https://bugs.launchpad.net/neutron/+bug/1793207 15:33:07 Launchpad bug 1793207 in neutron "external_gateway_info enable_snat attribute should be owner-modifiable" [Low,In progress] - Assigned to Brian Haley (brian-haley) 15:33:39 haleyb and I are in agreement that the current policy is overly strict and that the router owner should be able to change the value 15:33:54 we just want to make sure we are not missing something 15:34:23 right, hopefully someone remembers why they chose admin-only, but it's been years 15:34:28 I even wrote an email to Salvatore Orlando, who originally implemented it this way. He hasn't responded yet 15:34:51 but I sent the email just last night 15:35:08 do folks in this meeting have an opinion on this? 15:35:09 mlavalle: I don't know the history behind this. 15:36:07 the only thing i could find in the blueprints was around "some providers might want to restrict this" 15:36:28 maybe referring to the case where they set the default to False and don't want it enabled? 15:36:48 and the only reason I could think for this was that maybe enabling it implies the use of outside bandwidth 15:37:04 and admins might want control over it 15:37:14 mlavalle: So probably we should handle all the use cases and have LOGs that would inform the user about the consequences, if they accidentally change the enable_snat. (for example if they have VPN configured or Cenralized fip configured) 15:37:37 maybe sending email to operators ML would be good idea too? 15:37:59 slaweq: that's a good suggestion I think 15:39:19 ok, let's move on 15:39:27 any other bugs we should discuss today? 15:39:32 https://bugs.launchpad.net/neutron/+bug/1793094 15:39:32 Launchpad bug 1793094 in neutron "Router: add port doesn't take IP from allocation pool" [Undecided,Triaged] 15:40:05 it seemed related to the other issue we fixed recently, but boden tried with latest queens and saw it, needs invesigation 15:41:05 i will take it 15:41:13 thanks haleyb 15:42:08 ok 15:42:12 let's move on 15:42:23 #On demand agenda 15:42:39 #topic On demand agenda 15:42:50 any other topics we should sicuss today? 15:43:15 discuss 15:43:29 hi Miguel 15:43:47 can you assign the blueprint openflow-based-dvr to me? 15:43:47 hi xubozhang 15:43:59 xubozhang: of course 15:44:05 hang on please 15:44:10 let me do it now 15:44:20 * mlavalle assigning blueprint ..... 15:44:48 just FYI 15:45:02 I recently respin work on patch to remove external_bridge_name config option 15:45:21 and I sent email about that to ML: http://lists.openstack.org/pipermail/openstack-dev/2018-September/134839.html 15:45:57 I will try to push some patches to projects which still uses it, maybe if You have some experience with some of them, You can help with that :) 15:46:15 slaweq: thanks for the effort! 15:46:28 xubozhang: are you Xubo Zhang (xbzhang99) in Launchpad? 15:46:44 yes 15:47:04 xubozhang: assigned 15:47:11 thanks 15:47:33 please note that haleyb has kindly accepted to be the approver for this blueprint 15:47:42 ok 15:48:00 yes. there were some recent review comments by myself and slawek 15:48:17 yes we are taking care of them 15:48:34 thanks! 15:49:27 all right 15:49:33 anything else for today? 15:50:15 all right team.... enjoy the rest of your day 15:50:19 #endmeeting