14:02:20 <mlavalle> #startmeeting neutron_l3
14:02:21 <openstack> Meeting started Wed Mar 20 14:02:20 2019 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:24 <openstack> The meeting name has been set to 'neutron_l3'
14:02:32 <ralonsoh> hi
14:02:33 <haleyb> hi
14:03:21 <hjensas> o/ I'm guesting again. :)
14:03:51 <haleyb> hjensas: hi, let me make sure to add that item to the agenda
14:04:09 <mlavalle> #topic Announcement
14:04:27 <mlavalle> We are in RC-1 week
14:06:38 <mlavalle> We went over our RC-1 targets yesterday and it seems we are in good shape:
14:06:40 <mlavalle> https://launchpad.net/neutron/+milestone/stein-rc1
14:07:30 <mlavalle> and PTL election ended yesterday
14:08:16 <mlavalle> haven't seen results message. Has anybody?
14:08:22 <haleyb> who won? :)
14:09:07 <mlavalle> well, we will soon know who is the Nova PTL for the next cycle
14:09:22 <mlavalle> that is really what I'm wondering
14:09:47 <mlavalle> any other announcements
14:09:49 <mlavalle> ?
14:10:42 <mlavalle> oh yeah, I have another one
14:11:11 <mlavalle> Please don't forget that we have started an etherpad to collect topics for the PTG: https://etherpad.openstack.org/p/openstack-networking-train-ptg
14:11:32 <haleyb> mlavalle: i see the results, nova ptl is eric fried
14:11:51 <haleyb> https://governance.openstack.org/election/
14:12:41 <mlavalle> yeap. it was a clear win
14:12:44 <mlavalle> thanks!
14:13:55 <mlavalle> ok, let's move on
14:13:59 <mlavalle> #topic Bugs
14:15:14 <mlavalle> we have https://bugs.launchpad.net/neutron/+bug/1819160
14:15:16 <openstack> Launchpad bug 1819160 in neutron "Functional tests for dvr ha routers are broken" [High,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:16:02 <slaweq> hi, sorry I forgot about this meeting
14:16:20 <mlavalle> no problem
14:16:33 <mlavalle> we were looking at https://bugs.launchpad.net/neutron/+bug/1819160
14:16:34 <openstack> Launchpad bug 1819160 in neutron "Functional tests for dvr ha routers are broken" [High,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:17:08 <slaweq> yes, I described what I found in this bug
14:17:30 <slaweq> basically those tests are creating 2 independent routers always
14:17:40 <slaweq> and it should be one router on 2 nodes
14:17:47 <slaweq> one master and one standby
14:18:08 <slaweq> so basically those tests are usually passing because it's excuted fast enough
14:18:48 <slaweq> when for example https://github.com/openstack/neutron/blob/68fd13af40ce2752d2919ca569d3d3fe00ff6444/neutron/tests/functional/agent/l3/test_dvr_router.py#L1506 You will wait a bit longer it will fail
14:19:02 <slaweq> because both router1 and router2 will have state "master"
14:19:45 <mlavalle> so still in progress? liuyulong's comments confused me
14:19:55 <liuyulong> We also have some comments here.
14:20:15 <slaweq> it's for sure not fixed yet
14:21:11 <mlavalle> ok
14:21:18 <mlavalle> let's keep an eye on it
14:21:20 <slaweq> and I think we should change those tests that routers would be created in the way similar to https://github.com/openstack/neutron/blob/68fd13af40ce2752d2919ca569d3d3fe00ff6444/neutron/tests/functional/agent/l3/framework.py#L593
14:21:49 <slaweq> but for now I don't have time for this,
14:22:05 <slaweq> I even pushed some WIP patch https://review.openstack.org/#/c/642065/
14:22:13 <mlavalle> will you get back to it at some point?
14:22:15 <slaweq> but I don't know when I will be able to get back to it
14:22:39 <slaweq> mlavalle: probably not this and not next week
14:22:45 <slaweq> but I will try
14:22:56 <mlavalle> should we ask a volunteer to take over?
14:23:32 <ralonsoh> I can give a try
14:23:39 <slaweq> would be great if someone wants to take it :)
14:23:41 <slaweq> thx ralonsoh
14:23:43 <ralonsoh> (I slaweq wants)
14:23:45 <ralonsoh> if
14:23:53 * mlavalle was thinking of ralonsoh... heh heh heh
14:23:58 <slaweq> feel free to assign it to Yourself
14:24:11 <ralonsoh> slaweq, I'll talk to you later , thanks!
14:24:11 <mlavalle> thanks ralonsoh !
14:24:27 <liuyulong> slaweq, uuid of router is not the critical data. The router are connected by veth pair devices.
14:24:43 <liuyulong> Here are some log research: https://review.openstack.org/#/c/642295/6//COMMIT_MSG@11
14:24:44 <slaweq> liuyulong: sure, but they aren't connected
14:25:14 <slaweq> and having same uuid will be much better for future users of tests, e.g. in case of some another debugging
14:25:33 <liuyulong> There are two test ovs br-test-xxx bridge, and each has veth pair device on it.
14:26:18 <liuyulong> https://review.openstack.org/#/c/642220/2/neutron/tests/functional/agent/l3/test_dvr_router.py@1510
14:27:10 <slaweq> liuyulong: but as I said, if You would use remote_pdb in place which I pointed before, You will see that those routers will both become master after some time
14:27:27 <slaweq> and that isn't expected behaviour
14:27:35 <liuyulong> When the test running, you can run "watch -n 1 ovs-vsctl show" to see the test bridges and devices.
14:27:38 <slaweq> or maybe I missunderstand those tests
14:28:32 <liuyulong> slaweq, for the pdb issue, I guess, you may block some router processing actions.
14:28:47 <slaweq> liuyulong: no, nothing is blocked imo
14:29:05 <slaweq> liuyulong: test starts, routers are created and both are "standby"
14:29:21 <slaweq> then after some time keepalived process for each of routers switch router to master
14:29:26 <liuyulong> slaweq, that's ture, they are standby.
14:29:43 <slaweq> so IMO that means that those routers aren't connected to each other
14:30:07 <slaweq> anyway, I think we can discuss about it in bug report or later on irc
14:30:17 <liuyulong> OK
14:30:21 <slaweq> I don't want to "use" all meeting time for it :)
14:30:28 <mlavalle> and involve ralonsoh
14:30:32 <liuyulong> And thanks ralonsoh join this bug ship.
14:30:36 <slaweq> yeah :)
14:30:38 <ralonsoh> np
14:31:03 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1789434
14:31:05 <openstack> Launchpad bug 1789434 in neutron "neutron_tempest_plugin.scenario.test_migration.NetworkMigrationFromHA failing 100% times" [High,In progress] - Assigned to Miguel Lavalle (minsel)
14:31:26 <mlavalle> I will send a patch removing the unstable tag for those tests
14:31:35 <mlavalle> I will do that today
14:31:44 * mlavalle ran out of time last night
14:32:28 <mlavalle> this bug is expected to be fixed by https://review.openstack.org/#/c/636710/
14:32:43 <mlavalle> and that's all the bugs I had
14:32:52 <mlavalle> does anyone else have other bugs?
14:33:16 <liuyulong> I have
14:34:03 <liuyulong> https://bugs.launchpad.net/neutron/+bug/1818334
14:34:05 <openstack> Launchpad bug 1818334 in neutron "Functional test test_concurrent_create_port_forwarding_update_port is failing" [Medium,In progress] - Assigned to LIU Yulong (dragon889)
14:34:45 <liuyulong> The fix was sent here: https://review.openstack.org/644278. IMO, there was IP collision during the test.
14:35:38 <liuyulong> Sometimes the '_find_ip_address' can even return a IP address in-used by other ports.
14:36:18 <liuyulong> This is the root cause. But the fix is just a work around which only prevent such IP collision by randomly choice the IP addr.
14:36:52 <ralonsoh> I took a look at those tests and I didn't see it. But what I saw was a problem in the DB
14:37:19 <ralonsoh> the FIP assignation is not deleted
14:37:32 <liuyulong> https://review.openstack.org/#/c/644278/1//COMMIT_MSG@9 this is the test result locally.
14:37:46 <ralonsoh> and it's using the new private IP with the previously assigned FIP
14:39:20 <liuyulong> I'm not sure, but for this test, the floating IP is free？
14:39:45 <mlavalle> should we continue the conversation in the patch?
14:39:52 <liuyulong> OK
14:40:05 <ralonsoh> ok
14:40:32 <mlavalle> thanks liuyulong, ralonsoh
14:40:39 <mlavalle> any other bugs?
14:41:49 <mlavalle> ok, let's move on
14:42:27 <mlavalle> #topic Openflow DVR
14:43:23 <mlavalle> I don't see igordc and xubozhang here today
14:44:13 <mlavalle> but I want to mention that I will pay special attention to their patches and I encourgae others to do the same
14:44:40 <mlavalle> it would be good if if we can merge them early in Train
14:44:49 <mlavalle> ideally before Train-1
14:45:02 <mlavalle> that way we have time to play with them
14:46:27 <mlavalle> #topic On demand agenda
14:46:39 <mlavalle> anything else we should discuss today?
14:46:47 <haleyb> mlavalle: i added one item
14:47:08 <haleyb> i'd like to talk about nf_conntrack_helper
14:47:17 <mlavalle> yes I see it
14:47:18 <haleyb> http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003866.html
14:47:20 <mlavalle> go ahead
14:47:40 <haleyb> there was an initial patch that just enabled it by default in the router namespace
14:48:12 <haleyb> hjensas had another suggestion to add an extension that would enable it for a router
14:48:54 <mlavalle> yeah, it was originally brought up a couple of months abo by Julia and someone else
14:49:15 <haleyb> i'm still not sure of the downside of just always enabling it, since the qrouter isn't running services
14:49:20 <mlavalle> an l3 extension, right?
14:49:42 <haleyb> yes, and you'd specify the ports and helper
14:50:46 <haleyb> i've been meaning to ping someone internal that knows more about the helper than i, but think he's out this week
14:51:08 <haleyb> mlavalle: any thoughts on which you prefer?
14:51:29 <mlavalle> well, the extension makes it configurable, doesn't it?
14:51:33 <haleyb> i'm always under the impression that if we make it hard noone will use it/know how to use it
14:51:57 <haleyb> mlavalle: yes, it could allow a user to configure it for a single router
14:52:21 <mlavalle> I am open to explore that option
14:52:45 <mlavalle> maybe, when you get feedback from this other fellow, we can discuss it agin in this meeting
14:52:50 <mlavalle> would that help?
14:53:30 <haleyb> mlavalle: sure.  i'm guessing he'll say "you really shouldn't always enable this"
14:53:57 <haleyb> #action haleyb to get more info on enabling the nf-conntrack-helper by default
14:54:01 <mlavalle> if that's the case, the extension seems the way to go
14:54:05 <mlavalle> doesn't it?
14:54:16 <haleyb> mlavalle: yes
14:54:48 <mlavalle> so I'd say let's start moving in that direction
14:54:55 <mlavalle> and just confirm with this person
14:55:05 <mlavalle> are you ok with this, hjensas?
14:55:43 * mlavalle will also do some digging
14:55:43 <haleyb> mlavalle: ack
14:55:52 <mlavalle> cool
14:56:00 <mlavalle> anything else?
14:56:06 <haleyb> not from me
14:56:08 <hjensas> mlavalle: yes, I have started some work on the extension approach. So I will continue on that, and haleyb can ping me if it turns out we just want to enable by default.
14:56:22 <haleyb> hjensas: great, thanks!
14:56:25 <mlavalle> hjensas: thanks for working on this
14:56:38 <mlavalle> thanks for attending
14:56:44 <mlavalle> #endmeeting