14:00:30 <slaweq> #startmeeting neutron_drivers
14:00:31 <openstack> Meeting started Fri Jun 26 14:00:30 2020 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:33 <slaweq> hi
14:00:35 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:38 <ralonsoh> hi
14:00:40 <lajoskatona> o/
14:00:40 <mlavalle> o/
14:01:07 <haleyb> o/
14:01:36 <slaweq> lets wait few more minutes for yamamoto and amotoki
14:01:44 <slaweq> njohnston: told me just that he will be a bit late
14:01:44 <yamamoto> jo
14:01:49 <slaweq> hi yamamoto
14:04:35 <slaweq> ok, I think we can start
14:04:41 <slaweq> #topic RFEs
14:04:48 <slaweq> we have 2 RFEs to discuss today
14:04:54 <slaweq> first one is:
14:04:58 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1882804
14:04:58 <openstack> Launchpad bug 1882804 in neutron "RFE: allow replacing the QoS policy of bound port" [Undecided,New] - Assigned to Lajos Katona (lajos-katona)
14:05:30 <lajoskatona> This one was proposed by Gibi
14:05:38 <lajoskatona> during the PTG perhaps
14:06:01 <slaweq> yes, and it's follow up after the PTG
14:06:59 <lajoskatona> As I see the proposed usecase is limited and discuss only the case when new QoS policy (with min bw) is set to the port that is bound.
14:07:34 <lajoskatona> exactly, so no radial change in how things work now
14:08:28 <slaweq> I know we talked about it and we agreed with Nova that this should be the way to go
14:08:45 <lajoskatona> What is a cost that if it will work port update can go to placement and fetch allocations for the Resource Provider, and do change if the QoS policy bandwidth is different from the original bandwidth
14:08:55 <slaweq> so neutron will tell placement about new resource usage
14:09:00 <lajoskatona> yes
14:10:35 <slaweq> lajoskatona: one question - are our drivers already prepared to update such min bandwidth for port or this also has to be implemented?
14:11:29 <ralonsoh> I think both are different topics, scheduling enforcement and backend enforcement
14:12:12 <lajoskatona> slaweq: yes Ralonsoh is right a I see
14:12:35 <ralonsoh> currently we don't allow min-bw changes, is that correct?
14:12:36 <lajoskatona> we can do this from qos service plugin as I checked
14:13:06 <lajoskatona> ralonsoh: that is again a different usecase, first I messed it up as well
14:13:30 <lajoskatona> that is changing the policy of a Qos policy that is attached to a port
14:14:03 <lajoskatona> this RFE is about updating the port's QoS policy with a new on that has different min_bw value
14:14:30 <ralonsoh> right
14:14:32 <lajoskatona> to tell the truth I am not sure if the 2 can be covered with one step
14:14:59 <lajoskatona> so checked only the one described in the RFE
14:15:59 <slaweq> ok, so this rfe is only about scheduling/tracking available resources part - I'm fine with that
14:16:27 <slaweq> and I'm ok with approving this rfe
14:16:33 <njohnston> o/
14:17:19 <haleyb> +1
14:18:29 <njohnston> +1 that sounds reasonable (just finished reading the scrollback)
14:18:59 <mlavalle> +1
14:21:03 <yamamoto> +1
14:21:44 <slaweq> ok, I will mark this rfe as approved
14:21:55 <slaweq> lajoskatona: are You going to work on this in Victoria?
14:22:13 <lajoskatona> slaweq: Yes I planned it
14:22:37 <slaweq> ok, that's great
14:22:39 <slaweq> thx lajos
14:22:45 <slaweq> *lajoskatona :)
14:23:22 <slaweq> ok, next rfe
14:23:26 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1828494
14:23:26 <openstack> Launchpad bug 1828494 in neutron "[RFE][L3] l3-agent should have its capacity" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889)
14:23:34 <slaweq> this one was discussed few times already
14:23:40 <lajoskatona> Thanks for discussion
14:23:55 <slaweq> but recently liuyulong changed it to use "max_routers" parameter for L3 agent
14:24:27 <slaweq> and add new scheduler driver which will not schedule to the agent more routers than agent's max_routers value
14:24:57 <slaweq> so I wanted to ask You what do You think about it :)
14:28:08 <ralonsoh> so is "just" to add a new filter/weight to the l3 agent scheduling, right?
14:28:49 <slaweq> ralonsoh: I think so
14:29:18 <ralonsoh> we can model, in placement API, the BW of the physical resources
14:29:30 <ralonsoh> should this use this model too?
14:29:31 <slaweq> but now when I think about it I'm not sure how neutron will tell user that there was no available L3 agents to schedule router
14:30:23 <slaweq> ralonsoh: this was proposed initially IIRC but liuyulong didn't want to use placement there, that's why we proposed this easier parameter which is max_routers
14:30:55 <slaweq> there is spec proposed also https://review.opendev.org/#/c/658451/ but it isn't updated yet
14:31:06 <ralonsoh> ahhh I see
14:31:42 <mlavalle> so what we are discussing is the "routers_max" option?
14:32:19 <slaweq> mlavalle: my understanding is that RFE is now about using "routers_max" config option in L3 agent
14:32:34 <slaweq> and add new scheduler driver which will respect this value
14:32:48 <slaweq> details can be discussed in the spec's review
14:33:03 <ralonsoh> (that changes completely the current spec)
14:33:04 <slaweq> like e.g. what to do if there is no available L3 agents to schedule new router
14:33:17 <ralonsoh> this parameter and the way of counting this is easier
14:33:44 <ralonsoh> and you don't need to model those "external_interfaces" in the config
14:33:46 <slaweq> ralonsoh: I agree - it's much easier IMO now
14:35:23 <mlavalle> I would be ok approving this RFE on that assumption and moving to the detailed discussion in the spec
14:35:38 <slaweq> mlavalle: that'
14:35:48 <slaweq> that's exactly what I wanted to propose :)
14:38:18 <slaweq> haleyb: yamamoto njohnston: any thoughts?
14:38:41 <haleyb> i'm fine with it assuming an update as well
14:39:22 <yamamoto> i like the simplicity (compared to the original bandwidth thing)
14:39:22 <njohnston> I agree; I thionk an operator is going to want some guidance on how to sensibly calculate what they should set this setting to but that is a question for the spec review
14:39:40 <yamamoto> if it serves his purpose, i'm fine with it
14:41:01 <slaweq> ok, so I will mark this rfe as approved with using this max_routers parameter instead of bandwidth
14:41:15 <slaweq> and we will discuss more details in spec review
14:41:34 <slaweq> that's all from me for today
14:42:04 <slaweq> anything else You want to discuss today?
14:43:48 <yamamoto> nothing from me
14:45:10 <slaweq> ok, so I will give You 15 minutes back
14:45:16 <slaweq> have a great weekend o/
14:45:21 <slaweq> see You on Monday
14:45:24 <slaweq> #endmeeting