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