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