14:01:01 <slaweq> #startmeeting neutron_drivers 14:01:02 <openstack> Meeting started Fri Mar 26 14:01:01 2021 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:05 <openstack> The meeting name has been set to 'neutron_drivers' 14:01:06 <slaweq> hi 14:01:06 <mlavalle> o/ 14:01:17 <lajoskatona> Hi 14:01:36 <rubasov> hi 14:02:42 <haleyb> hi 14:02:43 <slaweq> amotoki told me that he will be available today 14:02:58 <slaweq> so we are still waiting for ralonsoh, njohnston and yamamoto 14:03:05 <ralonsoh> sorry 14:03:36 <slaweq> I pinged njohnston on neutron channel, maybe he will join soon 14:03:48 <slaweq> we have quorum now so I think we can start 14:04:00 <slaweq> #topic RFEs 14:04:10 <slaweq> first one 14:04:14 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1920065 14:04:15 <openstack> Launchpad bug 1920065 in neutron "Automatic rescheduling of BGP speakers on DrAgents" [Wishlist,Triaged] - Assigned to Renat Nurgaliyev (rnurgaliyev) 14:08:41 <ralonsoh> (sorry, I don't have enough knowledge on this topic) 14:09:19 <slaweq> for me this sounds like reasonable new config option, very similar like we have e.g. for dhcp agents already https://github.com/openstack/neutron/blob/a9fc746249cd34cb7cc594c0b4d74d8ddf65bd46/neutron/conf/agent/database/agentschedulers_db.py#L26 14:11:39 <haleyb> i would agree, gives the operator flexibility 14:11:45 <lajoskatona> perhaps frickler has some opinion 14:11:58 <mlavalle> yeah, it seems reasonable and as slaweq says, we already do it for dhcp. Why not in this case? 14:13:17 <mlavalle> in fact, IMO, it is more a plain vanilla bug than a RFE 14:14:33 <slaweq> there is new config option proposed, and it will change behaviour, so that's why I wanted to treat it as RFE 14:15:02 <slaweq> so if ralonsoh have nothing agains, I will mark it as approved 14:15:08 <ralonsoh> ok 14:15:16 <slaweq> thx 14:15:22 <slaweq> so that one was fast :) 14:15:26 <slaweq> second one 14:15:32 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1921126 14:15:33 <openstack> Launchpad bug 1921126 in neutron "[RFE] Allow explicit management of default routes" [Wishlist,New] - Assigned to Bence Romsics (bence-romsics) 14:15:41 <slaweq> rubasov: that's Yours :) 14:15:46 <rubasov> hi again 14:16:10 * slaweq will vote -1 due to yesterday's match ;) 14:16:17 <slaweq> ^^ just kidding :) 14:16:42 <rubasov> one note: this makes sense to me on top of the multiple external gateways and ecmp work 14:16:49 <rubasov> slaweq: :-D 14:17:30 <rubasov> technicalli I hope I managed to phrase it orthogonally, but the use case is for ecmp enabled default routes 14:18:24 <slaweq> so it's "follow-up" after https://bugs.launchpad.net/neutron/+bug/1905295 and https://bugs.launchpad.net/neutron/+bug/1880532, right? 14:18:26 <openstack> Launchpad bug 1905295 in neutron "[RFE] Allow multiple external gateways on a router" [Wishlist,New] - Assigned to Bence Romsics (bence-romsics) 14:18:27 <openstack> Launchpad bug 1880532 in neutron "[RFE]L3 Router should support ECMP" [Wishlist,New] - Assigned to XiaoYu Zhu (honglan0914) 14:18:52 <rubasov> in its use, definitely 14:19:01 <slaweq> ok 14:19:04 <rubasov> maybe the development can be done in parallel 14:20:45 <ralonsoh> well, maybe on top of https://review.opendev.org/c/openstack/neutron/+/743661/ 14:20:54 <ralonsoh> anyway, the spec makes sense 14:21:15 <ralonsoh> a good addition to previous RFEs 14:21:17 <mlavalle> yes, it makes sense to me as well 14:21:25 <rubasov> ralonsoh: yep, that sounds right 14:21:50 <mlavalle> and you were very careful to take care of the backwrards compatibility, which is always a concern 14:22:58 <rubasov> lajoskatona commented some extra ideas to make the switch to explicit mode even more seamless 14:23:35 <rubasov> https://review.opendev.org/c/openstack/neutron-specs/+/781475/1/specs/xena/explicit-default-routes.rst#59 14:24:06 <slaweq> according to lajoskatona's comment, couldn't it be even simpler without that extra switch at all? 14:24:18 <lajoskatona> As I see that would be usefull for operators to make it easier to use 14:24:32 <slaweq> for compatibility, default route would be always installed as extraroute by neutron 14:24:54 <slaweq> and user would be able to specify other default routes as extraroutes 14:25:17 <slaweq> maybe I'm totally wrong, I'm just thinking loud now :) 14:25:31 <rubasov> slaweq: do you mean without the implicit/explicit bit? 14:25:37 <slaweq> rubasov: yes 14:26:10 <rubasov> wouldn't that change our current behavior? since we don't report the default route today as an extraroute 14:28:30 <slaweq> yes, maybe it's better to have additional switch 14:29:21 <rubasov> I can imagine unexpected problems if we make the default route an extraroute in all cases 14:29:43 <rubasov> for example somebody has some automation that deletes all extraroutes 14:30:11 <rubasov> that person would be surprised when it deletes his default route too 14:30:24 <slaweq> yes, right 14:30:36 <slaweq> so let's have new flag for that 14:34:33 <slaweq> ok 14:34:45 <slaweq> so +1 from me for that rfe 14:34:48 <ralonsoh> +1 14:35:01 <haleyb> +1 14:35:03 <mlavalle> +1 14:35:31 <slaweq> so, approved 14:35:34 <slaweq> thx rubasov for proposal 14:35:49 <rubasov> thank you all for your time 14:35:53 <slaweq> and I'm looking forward for implementation in next cycle :) 14:36:07 <rubasov> it is coming 14:36:11 <slaweq> that's all what I had for today 14:36:20 <slaweq> do You want to talk about anything else? 14:37:52 <slaweq> ok, I take it as "nothing" :) 14:37:53 <mlavalle> not from me 14:38:02 <slaweq> thx for attending the meeting and have a great weekend 14:38:04 <slaweq> o/ 14:38:05 <ralonsoh> have a nice weekend 14:38:07 <slaweq> #endmeeting