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