14:01:06 <lajoskatona> #startmeeting neutron_drivers 14:01:06 <opendevmeet> Meeting started Fri Dec 3 14:01:06 2021 UTC and is due to finish in 60 minutes. The chair is lajoskatona. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:06 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:06 <opendevmeet> The meeting name has been set to 'neutron_drivers' 14:01:11 <lajoskatona> Hi 14:01:14 <ralonsoh> hi 14:01:23 <njohnston> o/ 14:01:31 <obondarev> hi 14:01:33 <slaweq> hi 14:01:49 <lajoskatona> mlavalle can't join today 14:02:23 <amotoki> hi 14:02:23 <lajoskatona> so I think we can start 14:02:28 <rubasov> hi 14:02:36 <mlavalle> yeah, I want to pay attention to this training I'm attending 14:02:43 <lajoskatona> The topic for today: #link https://bugs.launchpad.net/neutron/+bug/1952867 14:03:05 <lajoskatona> mlavalle: thanks for telling 14:03:57 <lajoskatona> This is a bug from liuyulong, and I asked him if he can join us today, but perhaps it is too late 14:04:22 <obondarev> there is a discussion here: https://review.opendev.org/c/openstack/neutron/+/820006 14:04:41 <obondarev> I tried to explain my position in the last comment 14:04:54 <lajoskatona> obondarev: thanks 14:05:39 <ralonsoh> I had the same concerns (written in the LP bug) 14:06:55 <obondarev> I think we need to agree where is the best place to address that use case 14:07:12 <obondarev> if it's neutron or not 14:07:25 <ralonsoh> what do you mean? 14:07:46 <obondarev> host configuration may address this I believe 14:08:13 <obondarev> "I'm wondering if that could be addressed by creating a tagged interface eth0@4000 on the node and adding it to a separate logical bridge "br-ext". Thus bridge_mappings can stay as is {"external": br-ext, "user": br-vlan}?" 14:08:32 <ralonsoh> ah right 14:08:44 <ralonsoh> the problem is that could not work with DPDK or HW offload 14:09:03 <obondarev> yeah, true 14:09:34 <obondarev> can we do the same with pure OVS? 14:09:49 <obondarev> with user space ports and bridges 14:09:54 <ralonsoh> we need to handle carefully the traffic in the phys bridge 14:10:09 <ralonsoh> tagging correctly the traffic 14:10:34 <ralonsoh> of course, the current OF rule set we have in phys-br is not valid 14:10:47 <ralonsoh> but it could work 14:10:54 <slaweq> this may also be error prone if e.g. there will be 2 different flat networks and both physical networks will use same bridge in bridge mapping 14:11:01 <ralonsoh> right 14:11:06 <ralonsoh> that;s configuration 14:11:09 <ralonsoh> we can't allow this 14:11:16 <ralonsoh> same as overlapping VLAN ranges 14:11:43 <slaweq> for the problem with vlans which liuyulong__ mentioned in gerrit - IMO that's what are vlan network types for, no? 14:11:55 <ralonsoh> yeah... he's right 14:12:02 <slaweq> and physical network for me always meant "really physical" network 14:12:06 <lajoskatona> and now we create placement resources based on bridge mapping for QoS, not sure if placement can handle such change 14:12:14 <ralonsoh> not the current code 14:12:29 <ralonsoh> because we asume 1:1 phys bridges - network 14:12:37 <slaweq> such change IMO would make a lot of mess in many places 14:12:46 <obondarev> + 14:13:16 <slaweq> and would be not correct from the "model point of view" 14:13:20 <slaweq> I hope You know what I mean 14:13:45 <ralonsoh> yes: 1 physnet, 1 bridge, 1 NIC 14:13:55 <lajoskatona> yeah or we have to limit this new mapping to a few features only, and add a lot of conditions to handle 14:14:01 <slaweq> ralonsoh++ 14:14:36 <rubasov> I also have the understanding that we see a configuration there that ignored the original meaning of a "physnet" and now would like to change the implementation to keep the configuration intact 14:15:27 <rubasov> of course configuration change can be real pain, but I'm not sure if it's best worked around from the implementation 14:16:19 <opendevreview> Tamas Gergely Peter proposed openstack/neutron master: Check whether vxlan group and local addresses are IPv4 or IPv6 and https://review.opendev.org/c/openstack/neutron/+/820376 14:16:34 <lajoskatona> rubasov: +1 14:16:46 <ralonsoh> correct 14:20:39 <lajoskatona> ok so I think we can say that it's better not to change how bridge-mapping is now and keep 1 nic - 1 bridge - 1 physnet relataion as it is today 14:20:47 <amotoki> IIUC this proposal tries to introduce anotherr abstraction model in neutron: some ID ranges for "extrenal" and another non-overlapping ID range for "user". 14:20:49 <amotoki> I think it is not a role of neutron. If kernel supports such kind of abstraction of bridges, neutorn can handle such as individual bridges, but it is not the real... 14:21:14 <amotoki> I totally agree with "1 nic - 1 bridge - 1 physnet " 14:21:28 <slaweq> yeah, I'm also for keeping current model 14:21:32 <slaweq> so -1 for that RFE 14:21:35 <ralonsoh> -1 14:22:09 <amotoki> -1 too 14:22:27 <lajoskatona> ok, than I will add link to the logs to launchpad 14:22:34 <lajoskatona> thanks for the discussion 14:23:23 <lajoskatona> I am not sure if we have enough votes, let's count it, sorry.... 14:23:58 <amotoki> I see many important points in this discussions :-) hopefully liu understands the current situation 14:24:04 <lajoskatona> I think we have 5 -1-s 14:24:24 <lajoskatona> yeah I think we covered the topic well 14:24:57 <lajoskatona> We have one topic from ralonsoh in On-Demand agenda 14:25:00 <lajoskatona> #topic On Demand Agenda 14:25:07 <ralonsoh> thanks 14:25:07 <lajoskatona> (ralonsoh): https://review.opendev.org/c/openstack/python-openstackclient/+/819627/1: To deprecate "force" behaviour in OSC "quota" commands. 14:25:14 <lajoskatona> This is currently the default behaviour in Neutron; what is proposed in this patch is to move Neutron to, by default, 14:25:35 <ralonsoh> this is related to https://bugs.launchpad.net/neutron/+bug/1936408, but not part of the bug 14:25:45 <ralonsoh> when I pushed the patch for OSC 14:25:59 <ralonsoh> a core reviewer proposed to unify the behaviour 14:26:11 <ralonsoh> that means: Neutron to adopt by default the limit check 14:26:15 <ralonsoh> same as Nova 14:26:39 <slaweq> I didn't read logs from our previous discussion but I think I was already for unifying it at some point :) 14:26:47 <ralonsoh> right! 14:27:01 <ralonsoh> of course, that needs a period of migration 14:27:08 <slaweq> or if not, then now I think it's definitely good idea to make it behave the same way for Nova and Neutron 14:27:17 <ralonsoh> if we accept this, we need to inform during some releases that this behaviour will change 14:27:30 <obondarev_> + 14:27:32 <ralonsoh> so, what do you think? 14:27:45 <obondarev_> + for unification 14:28:04 <ralonsoh> if accepted, I'll open a new LP bug and push a patch with a big warning 14:28:39 <lajoskatona> just for reference the log from last discussion: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-08-27-14.00.log.html#l-61 14:28:56 <amotoki> we have two places to unify the behaviors on quotas: OSC and back-end services. These are separate layers. 14:29:02 <ralonsoh> right 14:29:04 <amotoki> I think we can introduce the unified behavior in OSC first 14:29:22 <ralonsoh> we have this capability now in OSC 14:29:27 <ralonsoh> we can pass --force 14:29:37 <ralonsoh> of course, in Neutron will do nothing (for now) 14:29:44 <amotoki> I think OSC can have three modes: --force, --check-limit (--no-foce), --use-service-default 14:30:03 <amotoki> the last option honors th ecurrent service default behaviors for backward compat. 14:30:28 <ralonsoh> I didn't see the last one in OSC, I'll check it 14:30:42 <amotoki> ralonsoh: this is just my thought right now 14:31:18 <amotoki> when we consider existing users, we need to provide a migration path 14:32:05 <ralonsoh> right, this is why I proposed a warning and documenting that 14:32:28 <ralonsoh> they'll need to add the --force parameter to keep the currently functionality 14:33:10 <ralonsoh> and we can include this parameter now in the OSC and discard it in Neutron (now) 14:33:19 <ralonsoh> and then change the behaviour 14:34:42 <slaweq> ralonsoh who will need to add --force now? 14:34:54 <ralonsoh> all customers, to be prepared 14:35:10 <ralonsoh> now this parameter is not needed in neutron 14:35:21 <slaweq> ok 14:35:23 <ralonsoh> but we'll accept it just to prepare the migration 14:35:41 <slaweq> I wasn't sure I understand who is "they" :) 14:39:17 <slaweq> I'm ok to go with that warning and docs and change default behavior in the future 14:39:53 <ralonsoh> +1 (I can vote because the proposal is not mine, is stephenfin's proposal) 14:40:05 <amotoki> I think the first step is to introduce a way to specify a consistent behavior in OSC 14:40:25 <amotoki> as of now, nova default is to check limits and neutron default is to force to set limits. 14:40:28 <lajoskatona> yeah +1 to make Nova and Neutron behave similarly 14:40:46 <ralonsoh> amotoki, right, and we have both options now in the Neutron server 14:41:00 <amotoki> having both --force and --no-force (--check-limit) in OSC allows us to do so 14:41:04 <ralonsoh> we'll document this change to be done in next releases 14:41:06 <ralonsoh> no no 14:41:13 <ralonsoh> just nothing or --force 14:41:20 <ralonsoh> those two options, same as in Nova 14:41:27 <amotoki> ralonsoh: ah, i see 14:41:33 <ralonsoh> then we'll remove --check-limit 14:41:41 <ralonsoh> (it will make no sense then) 14:42:05 <amotoki> but if --force is not specified, the current behavior on neutron quotas is same as --force 14:42:17 <ralonsoh> right 14:42:34 <ralonsoh> this is why we need to write a warning about this 14:42:53 <ralonsoh> if you pass a "quota set" parameter to Neutron without --force (or --check-limit now) 14:43:02 <ralonsoh> then a warning message will be writen 14:43:07 <amotoki> so my next question is whether we (OSC) should provide a way to use the current behavior 14:43:44 <ralonsoh> IMO, in Neutron we should accept now "nothing", --force and --check-limit 14:43:56 <ralonsoh> and write a warning in nothing is passed 14:44:09 <amotoki> how about at OSC level? 14:44:13 <ralonsoh> nothing 14:44:15 <slaweq> and --force should be "default" behaviour for now, right? 14:44:16 <ralonsoh> just as is now 14:44:19 <slaweq> as it's now 14:44:24 <ralonsoh> no no 14:44:31 <ralonsoh> OSC just pass the parameters 14:44:33 <ralonsoh> nothing else 14:44:42 <ralonsoh> do not introduce any logic inside OSC 14:44:49 <ralonsoh> this should be the Neutron quota driver 14:45:16 <ralonsoh> 1) we'll filter out --force (now) and keep the current behaviour 14:45:29 <ralonsoh> 2) in 2-3 releases, we'll change the behaviour 14:45:38 <ralonsoh> do you mind if I write a LP bug? 14:45:45 <ralonsoh> just to save your time 14:45:53 <ralonsoh> I'll write all steps there 14:46:08 <amotoki> ralonsoh: sounds fine 14:46:12 <slaweq> +1 for LP bug with plan of work in releases 14:46:14 <obondarev_> thanks ralonsoh 14:46:27 <amotoki> line-by-line discussion is sometimes confusing :p 14:46:27 <njohnston> +1 14:46:31 <slaweq> and +1 from me for doing that change really :) 14:46:32 <ralonsoh> thanks all! 14:46:43 <lajoskatona> +1, and thanks for summarizing it in LP 14:47:45 <amotoki> yeah, unifying the behavior is the right future without any doubt :) 14:48:01 <lajoskatona> ok we can close the meeting if there is no more comments or topics to discuss 14:48:42 <amotoki> ralonsoh: do you mean bug 1936408 by "write a LP bug" above? 14:48:49 <amotoki> or a new LP bug? 14:48:56 <ralonsoh> a new one, this is not related 14:49:12 <amotoki> ralonsoh: thanks. sounds reasonable 14:50:25 <lajoskatona> Thanks for attending, and for the discussions. 14:50:30 <slaweq> thx 14:50:35 <ralonsoh> have a nice weekend! 14:50:36 <amotoki> thanks all 14:50:36 <lajoskatona> #endmeeting