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