14:01:28 <mlavalle> #startmeeting neutron_l3
14:01:29 <openstack> Meeting started Wed Feb 27 14:01:28 2019 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:32 <openstack> The meeting name has been set to 'neutron_l3'
14:01:38 <davidsha> o/
14:01:46 <haleyb> hi
14:02:00 <liuyulong> hi
14:02:07 <igordc> hi
14:02:33 <slaweq> hi
14:03:15 <mlavalle> #chair liuyulong, haleyb
14:03:16 <openstack> Current chairs: haleyb liuyulong mlavalle
14:03:39 <mlavalle> #topic Announcements
14:04:20 <mlavalle> Our Stein-3 milestone is next week
14:04:54 <mlavalle> Yesterday we reviewed our blueprints for the milestone
14:05:01 <mlavalle> and overall we are in good shape
14:06:27 <mlavalle> Today is the last day to register at early bird rate to the Summit / PTG in Denver on May. Your promotion codes as contributors are only good until tonight, 23:59 US West coast time
14:06:46 <mlavalle> Hoping to see all of you there :-)
14:07:07 <mlavalle> Any other announcements?
14:07:11 * haleyb will not be going this time, trip conflict
14:07:45 * mlavalle and slaweq will drink haleyb's beers
14:08:07 <slaweq> no problem for me :D
14:08:08 <haleyb> enjoy them! :)
14:08:31 <mlavalle> #topic Bugs
14:08:56 <mlavalle> First in the list is https://bugs.launchpad.net/neutron/+bug/1816698
14:08:58 <openstack> Launchpad bug 1816698 in neutron "DVR-HA: Removing a router from an agent, does not clear the namespaces on the agent" [High,In progress] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
14:09:46 <mlavalle> Swami has proposed a patch for it https://review.openstack.org/#/c/638566/
14:10:37 <mlavalle> and haleyb has been reviewing it. any comments?
14:12:09 <mlavalle> well I encourage the team to look at the patch
14:12:12 <haleyb> i'll review again
14:12:48 * mlavalle just rechecked it
14:13:11 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1795870
14:13:12 <openstack> Launchpad bug 1795870 in neutron "Trunk scenario test test_trunk_subport_lifecycle fails from time to time" [High,In progress] - Assigned to Miguel Lavalle (minsel)
14:14:12 <mlavalle> For this one I have a couple of patches under review
14:14:42 <mlavalle> For the second one I obviusly did something wrong: https://review.openstack.org/639375
14:15:11 <mlavalle> ahh Iknow waht it was
14:15:21 <mlavalle> forgot to update requirements
14:15:33 <mlavalle> I'll push another revision soon
14:16:08 <mlavalle> haleyb: this patch is linked with https://review.openstack.org/#/c/636710
14:16:20 <mlavalle> where the rootwrap fileter is
14:16:37 <mlavalle> I wanted the updating of the process command to be its own patch
14:17:32 <mlavalle> any comments?
14:18:07 <mlavalle> ok, moving on
14:18:26 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1789434
14:18:27 <openstack> Launchpad bug 1789434 in neutron "neutron_tempest_plugin.scenario.test_migration.NetworkMigrationFromHA failing 100% times" [High,Confirmed] - Assigned to Manjeet Singh Bhatia (manjeet-s-bhatia)
14:19:19 <mlavalle> Should this be a duplicate of the previous bug, slaweq?
14:19:34 <slaweq> mlavalle: yes, I think so
14:19:47 <mlavalle> ok, I'll mark it duplicate
14:19:49 <slaweq> I was testing this locally with Your patches to rootwrap filters and it worked
14:19:55 <slaweq> at least for me
14:20:02 <slaweq> so I hope it will be fixed with Your patch
14:20:50 <mlavalle> Finally https://bugs.launchpad.net/neutron/+bug/1774459
14:20:51 <openstack> Launchpad bug 1774459 in neutron "Update permanent ARP entries for allowed_address_pair IPs in DVR Routers" [High,Confirmed] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
14:21:28 <mlavalle> no progress on this one since early January
14:21:54 <mlavalle> I'll send swami an email at the end of the meeting to see what's his plan, if any
14:22:11 <mlavalle> Any other bugs we should discuss today?
14:22:16 <liuyulong> I have
14:22:27 <slaweq> I have one too
14:22:32 <slaweq> but go on liuyulong :)
14:22:47 <liuyulong> https://bugs.launchpad.net/neutron/+bug/1811352
14:22:48 <openstack> Launchpad bug 1811352 in neutron "[RFE] Include neutron CLI floatingip port-forwarding support" [Wishlist,New]
14:23:05 <liuyulong> Seems no one now takes this one
14:23:35 <liuyulong> So, I will submit our local implement for this.
14:24:24 <mlavalle> Great!
14:24:27 <mlavalle> Thanks!
14:24:38 <liuyulong> mlavalle, we have openflow dvr topic during this meeting?
14:24:48 <mlavalle> liuyulong: I think so
14:25:00 <mlavalle> slaweq: go ahead
14:25:12 <liuyulong> OK, so I will remain my next bug during that topic.
14:25:19 <slaweq> https://bugs.launchpad.net/tempest/+bug/1817696
14:25:21 <openstack> Launchpad bug 1817696 in tempest "Network tests from api.network.admin.test_l3_agent_scheduler may fail in multimode environment" [Undecided,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:25:23 <slaweq> it's tempest bug
14:25:34 <slaweq> but related stictly to l3 scheduler tests
14:26:19 <slaweq> so basically problem is that in multinode scenario when there is more than one L3 agent, test can fail if router is not HA and it tries to add it to other L3 agent than it is already added
14:26:33 <slaweq> so I changed this test a bit https://review.openstack.org/#/c/639316/
14:26:41 <slaweq> it worked for me and in gate so far
14:26:48 <slaweq> but I wanted to ask You as L3 experts
14:27:10 <slaweq> is it possible that when I remove router from L3 agent it will be automatically scheduled on some agent?
14:27:31 <slaweq> even if there will be no any other action related to this router, like adding interface or something like that
14:27:49 <slaweq> because if it may happen then this proposed solution may be wrong too :/
14:28:42 <slaweq> so please review it and tell me in comments if that solution makes sense or not :)
14:28:46 <slaweq> that's all from me
14:29:05 <mlavalle> ok, will do. Thanks for fixing this
14:29:25 <mlavalle> but at first glance looks like a sensible approach
14:29:38 <slaweq> thx mlavalle
14:30:02 <mlavalle> #topic Openflow DVR
14:30:17 <mlavalle> igordc, xubozhang: any uopdates this week?
14:31:01 <xubozhang> yes, igor is doing refactoring of l3 agent
14:31:56 <xubozhang> i am working on unit tests
14:32:14 <igordc> I've propsoed a new wip refactor here: https://review.openstack.org/#/c/639605/
14:32:43 <igordc> it looks scary but it's actually not as scary as the original one
14:33:38 <igordc> most of the scariness stems from renaming RouterInfo to LinuxRouterInfo.. I'm open  to keeping the name and renaming its parent to BaseRouterInfo, per Yang Youseok's patch
14:34:13 <igordc> (which btw fits very well with the refactor too, I'm talking about https://review.openstack.org/#/c/620349/)
14:34:30 <liuyulong> Wow..any chance you can split to small patch sets?
14:35:02 <igordc> liuyulong, it's actually a very difficult one to do so due to its nature
14:35:17 <igordc> liuyulong, it's creating a lot of noise due to the refactored stuff
14:35:41 <davidsha> liuyulong: It seems to be a lot of small changes with 1 or 2 big files.
14:35:42 <igordc> but I'll do my best
14:36:32 <mlavalle> thanks for the hard work igordc
14:36:37 <igordc> the basic idea there is that we're no longer dual-purposing RouterInfo like in the original refactor and thus it becomes simpler (for example, no more classmethod workarounds).. I am introducing the Backend class
14:36:51 * liuyulong add himself to the reviewers list
14:38:19 <mlavalle> I will take a look at the patch. My first reaction, though, is that given the size of the change and how close we are to end of Stein, this is likely to slip to Train
14:38:33 <igordc> having a separation between RouterInfo and Backend will also fit well with having config options agent_mode and agent_backend, respectively
14:38:34 <mlavalle> and the fact that it is still wip
14:39:20 <igordc> mlavalle, right, I expect it to be fully ready by the deadline but obviously additional time is needed to get it well reviewed
14:39:43 <mlavalle> igordc: thanks
14:40:18 <igordc> mlavalle, and that's also the case of the overall openflow dvr
14:40:33 <mlavalle> igordc: yeap, understood
14:40:46 <mlavalle> Thanks very much for pushing on this :-)
14:41:42 <mlavalle> liuyulong: you wanted to comment on a bug....
14:41:47 <liuyulong> https://bugs.launchpad.net/neutron/+bug/1817872
14:41:48 <openstack> Launchpad bug 1817872 in neutron "[RFE] neutron resource health check" [Undecided,New]
14:42:01 <liuyulong> Today, I filed this RFE which aim to check resource status, something related to the T cycle community goal "Service-side health checks".
14:42:45 <liuyulong> So I wonder if you guys could consider add some related utils function for this.
14:44:41 <mlavalle> IMO, it would probably be easier if you add a dependent patch to their series with the utility functions you want
14:44:59 <liuyulong> IMO, the feature authors have full knowledge to understand global workflow of openflow dvr.
14:45:42 <mlavalle> well, I'll let them speak for themselves
14:47:06 <liuyulong> Cloud users, especially operators, may have pain on trouble shooting of such flow based feature.
14:47:22 <igordc> liuyulong, "openflow dvr" as in what xubozhang/me are proposing?
14:47:25 <mlavalle> I see your point
14:47:38 <mlavalle> igordc: yes
14:47:48 <liuyulong> Yes
14:48:24 <igordc> this wouldn't be the only thing missing in the openflow dvr implementation
14:48:58 <igordc> it's first version, that we want to get merged, won't support some other things that linux dvr does
14:49:56 <igordc> but still definitely achievable, I'll have to read about this RFE more carefully after a coffee
14:50:10 <mlavalle> igordc: thanks
14:50:50 <liuyulong> Yes, agree, I do not mean to block such amazing feature, but just want to give cloud users better experience.
14:50:53 <mlavalle> liuyulong: since you are going to review their patches, maybe you can leve some hints in comments as to where you see help is needed
14:51:22 <igordc> liuyulong, openflow dvr will be opt-in though
14:51:47 <liuyulong> mlavalle, I will, I can't wait to experience such function.
14:52:52 <liuyulong> igordc, it is, but if you want such feature to be widely used, then such status-check will be a pluses
14:53:14 <xubozhang> yulong, we will make sure the existing l3 functionality still works, of-dvr is an opt-in
14:53:39 <haleyb> just being devil's advocate, we should also remember OVN is here already too, and there is some overlap there with pure flow-based DVR
14:54:49 * haleyb is assuming people know about OVN
14:55:02 <mlavalle> LOL, we do
14:55:08 <liuyulong> haleyb, you rock
14:55:32 <mlavalle> ok, let's move on
14:55:34 <haleyb> forgot the :)
14:55:51 <mlavalle> #topic On demand agenda
14:56:01 <mlavalle> anything else we should discuss today?
14:56:40 <mlavalle> ok thanks for attending
14:56:47 <davidsha> Thanks!
14:56:50 <mlavalle> enjoy the rest of your week
14:56:55 <mlavalle> #endmeeting