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