14:00:46 <haleyb> #startmeeting neutron_drivers
14:00:46 <opendevmeet> Meeting started Fri Sep 12 14:00:46 2025 UTC and is due to finish in 60 minutes.  The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:46 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:46 <opendevmeet> The meeting name has been set to 'neutron_drivers'
14:01:01 <ralonsoh> hello
14:01:08 <haleyb> Ping list: ykarel, mlavalle, mtomaska, slaweq, tobias-urdin, lajoskatona, haleyb, ralonsoh
14:01:09 <mlavalle> \o
14:01:13 <haleyb> i'm assuming we'll have quorum
14:01:37 <slaweq> hi, I am in the other meeting in the same time but will try to participate here as well
14:01:38 <mlavalle> I saw slaweq in slack earlier today
14:02:36 <haleyb> i can't remember if lajoskatona can attend
14:03:35 <haleyb> maybe the first question is do we have to decide what quorum is now as we have less on the drivers team
14:03:44 <haleyb> i.e. is 3 enough?
14:03:52 <ralonsoh> how many drivers do we have?
14:04:11 <ralonsoh> 6 if I'm not wrong
14:04:18 <haleyb> i'm looking
14:04:51 <slaweq> https://launchpad.net/~neutron-drivers/+members#active
14:05:04 <slaweq> according to this we have 7 but I think that amotoki is not really active anymore
14:05:24 <haleyb> nor is oleg, i need to remove them
14:05:27 <lajoskatona> o/
14:05:39 <haleyb> so that leaves 5
14:05:40 <lajoskatona> I am here actually quickly changing afternoon....
14:05:52 <haleyb> lajoskatona: o/
14:07:52 <haleyb> so do others agree that 3 is ok for quorum now? that is a majority of the 5.
14:08:08 <slaweq> fine for me
14:08:13 <lajoskatona> +1
14:08:26 <ralonsoh> +1
14:08:51 <haleyb> and we will have to work on adding people, a thought for ptg
14:09:16 <haleyb> anyways, i do see at least one item, there might be others in the "ready" list to discuss quickly
14:09:21 <haleyb> ralonsoh: you had the first one
14:09:28 <mlavalle> yes 3 is quorum
14:09:33 <ralonsoh> thanks
14:09:37 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2119647
14:09:44 <ralonsoh> [RFE] OVN DHCP relay
14:09:53 <ralonsoh> I've also added a spec: https://review.opendev.org/c/openstack/neutron-specs/+/956795
14:10:09 <ralonsoh> In a nutshell: OVN now allows to relay the DHCP requests
14:10:39 <ralonsoh> instead of handling them internally, it is possible to relay the DCHP packets to external DHCP servers
14:10:51 <ralonsoh> there is a new table DHCP_relay
14:11:24 <ralonsoh> you can define an IP address there. Then you set this register to a Logical_Router_Port belonging to the network
14:11:31 <ralonsoh> (that means you need to connect this network to a router)
14:11:51 <ralonsoh> and then, to the Logical_Switch, define in "options" the Logical_Router_Port
14:12:06 <ralonsoh> and that's all: you can have a DHCP running in a VM in another network
14:12:30 <ralonsoh> and this DHCP will reply to the DHCP requests messages from the VM running in this netwokr
14:12:33 <ralonsoh> that's all
14:13:17 <ralonsoh> (ah, of course, this feature is OVN only)
14:15:17 <ralonsoh> I have left you speechless!
14:15:18 <haleyb> i think i understand the spec, i did have one question.
14:15:36 <haleyb> the network owner fills-in the IP address, correct?
14:15:41 <ralonsoh> yes
14:15:56 <opendevreview> Merged openstack/neutron-fwaas master: Update master for stable/2025.2  https://review.opendev.org/c/openstack/neutron-fwaas/+/960512
14:15:57 <haleyb> i didn't know if the cloud owner would want to do such things
14:16:16 <haleyb> i.e. how does the network owner know what IP it should use?
14:16:22 <haleyb> or maybe i'm missing the use case
14:16:40 <ralonsoh> so because of the potential issues this feature can cause, we can define by default this feature as admin-only
14:16:45 <ralonsoh> that makes sense
14:16:59 <lajoskatona> +1 for admin-only
14:17:12 <ralonsoh> so only an admin (by default) can assign this dhcp_relay value to a netwoek
14:17:18 <ralonsoh> I'll update the spec today ^^
14:17:40 <haleyb> ok, and if it's required for normal operation, should a default be specified by the admin?
14:17:48 <opendevreview> Merged openstack/neutron-tempest-plugin master: Fix bug/2122606 to allow designate job  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/960659
14:18:33 <ralonsoh> admin can always change the default policies
14:18:41 <ralonsoh> ok you mean to have a default one
14:18:57 <ralonsoh> that will apply always to the networks, that cannot be changed by a non-admin
14:19:13 <ralonsoh> haleyb, is that what you mean?
14:19:36 <ralonsoh> I didn't think about having a possible default dhcp_relay value
14:19:38 <haleyb> right, i'm just thinking that if i go and create a network in this environment will dhcp work without that set?
14:19:59 <ralonsoh> by default, if not set, OVN will use the inner DHCP server
14:20:13 <ralonsoh> builtin DHCP server*
14:20:52 <lajoskatona> for backward compatibility the default builtin one is a good choice
14:20:57 <haleyb> sure
14:21:29 <ralonsoh> in any case, I would not implement the possibility for dhcp-relay by default
14:21:38 <haleyb> so maybe my first question should have been what the use case is? i'm assuming it's an operator that wants to know about all allocations?
14:21:38 <ralonsoh> that should be used for very specific purposes
14:21:56 <mlavalle> but we don
14:22:10 <mlavalle> don't have a preferred dhcp server, right?
14:22:36 <ralonsoh> haleyb, the use case was initially for baremetal servers in separate leafs
14:22:56 <ralonsoh> but for now this feature, that requires a router and a LRP, doesn't match these requirements
14:23:05 <ralonsoh> mlavalle, sorry, I don't understand the question
14:23:18 <ralonsoh> OVN has a built-in server, we always use it
14:23:19 <opendevreview> Stephen Finucane proposed openstack/neutron master: setup: Remove pbr's wsgi_scripts  https://review.opendev.org/c/openstack/neutron/+/960834
14:23:20 <opendevreview> Stephen Finucane proposed openstack/neutron master: Migrate setup configuration to pyproject.toml  https://review.opendev.org/c/openstack/neutron/+/960835
14:23:52 <ralonsoh> if we set a dhcp relay for a network, and this network is connected to a router (this is a must), then the DHCP messages will be relayed
14:24:23 <mlavalle> we don't make any assumptions as to what ultimately responds to the dhcp requests. It's something running in a VM
14:24:35 <ralonsoh> not at all
14:24:52 <opendevreview> Arnaud Morin proposed openstack/neutron master: Add option to skip loading agent Trunk extension  https://review.opendev.org/c/openstack/neutron/+/913979
14:25:00 <ralonsoh> could be anything, a DHCP agent, an DHCP server running in a VM, a DHCP server in an external IP address
14:25:03 <ralonsoh> anything
14:25:16 <mlavalle> that was my question, thanks
14:25:50 <opendevreview> Merged openstack/neutron-dynamic-routing stable/2025.2: Update .gitreview for stable/2025.2  https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/960493
14:25:50 <ralonsoh> this is like in ML2/OVS: the VM sends the DHCP requests, we run the DHCP agent but in some cases, with some "peculiar" configurations and ACLs, it was possible to respond from a VM with a DHCP server
14:26:11 <mlavalle> +1
14:27:48 <haleyb> are there any other questions?
14:28:08 <slaweq> I am ok with this proposal
14:28:21 <mlavalle> very clear use case
14:28:23 <lajoskatona> finr from me also, +1
14:28:23 <mlavalle> +1
14:28:32 <ralonsoh> thank you all
14:28:34 <haleyb> +1 from me
14:28:47 <mlavalle> we need to start by reviewing the spec, right?
14:29:05 <ralonsoh> I need to add the admin-only bit
14:29:13 <haleyb> ack, i'll mark approved but then yes, review the spec
14:29:20 <mlavalle> ok
14:29:26 <haleyb> #link https://review.opendev.org/c/openstack/neutron-specs/+/956795
14:29:44 <lajoskatona> I have to anyway go to reviews specs, recently I forgot that....
14:29:55 <ralonsoh> ahh, please approve the patch opening the 2026.1 folder: https://review.opendev.org/c/openstack/neutron-specs/+/958831
14:30:39 <lajoskatona> done
14:30:46 <ralonsoh> cool
14:31:12 <mlavalle> lol lajoskatona beat me to it
14:31:38 <haleyb> there was nothing else in agenda, but there was one more rfe that would be good to discuss
14:31:43 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2120732
14:31:51 <haleyb> [RFE] Add metadata caching for immutable values
14:32:25 <haleyb> i should have pinged sam before the meeting, but it seems straightforward, and more of a bug then rfe
14:32:25 <ralonsoh> I love the idea but I have some concerns with the implementation
14:32:51 <haleyb> oh, i now see you had looked the other day
14:32:55 <ralonsoh> what are "immutable values"? if you can answer it
14:33:05 <ralonsoh> https://review.opendev.org/c/openstack/neutron/+/957197/5/neutron/common/metadata.py#38
14:33:36 <ralonsoh> I mean, having a configurable metadata cache could be a huge performance improvement in some scenarios
14:33:55 <opendevreview> Merged openstack/neutron-specs master: Spec folder for 2026.1 cycle  https://review.opendev.org/c/openstack/neutron-specs/+/958831
14:33:58 <ralonsoh> but we must define well (or make it configurable too) what are inmutable values
14:34:05 <haleyb> i had initially asked about rate-limiting, but it does seem useful especially for this person
14:34:26 <ralonsoh> that will probably be a bottle neck, the rate limiter
14:34:53 <ralonsoh> they really need not to ping again and again the metadata server
14:34:56 <haleyb> in his case the rate limiter would help with the load, but not address the issue
14:35:37 <ralonsoh> so initially I'm in favor of this but we need a very clear picture of what is static and cab be cached
14:35:39 <haleyb> i.e. IoT devices that are dump
14:35:48 <haleyb> s/dumb
14:36:36 <lajoskatona> yes, and as these values are coming from nova, should we have a chat with nova as well?
14:36:47 <ralonsoh> ^^ PTG could be a good place
14:36:49 <mlavalle> was a spec proposed? if not, we can request a spec and clarify these concerns there
14:37:19 <mlavalle> or the PTG. good idea
14:37:21 <ralonsoh> +1 for a spec, I really like this idea
14:37:46 <haleyb> no, i didn't ask for one yet as it seemed simple, but would be good to get these questions answered
14:38:00 <mlavalle> let's do that
14:38:01 <haleyb> implementation should be simple according to existing change
14:38:47 <haleyb> ok, i'll ask for spec and have a quick discussion at ptg to make sure we're not missing something from nova side
14:38:57 <ralonsoh> +1
14:39:04 <ralonsoh> (nice topic for the PTG)
14:39:05 <lajoskatona> +1
14:39:17 <mlavalle> +1
14:39:26 <haleyb> great
14:39:49 <haleyb> i didn't see any other topics to discuss, but will wait a minute if anyone has one
14:40:00 <lajoskatona> I have one small (forgot to add to the agenda)
14:40:16 <lajoskatona> there was a mail from mnasser: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/425LYYRSQYWAK6APPQC6QFW35NFLJ6F7/
14:40:50 <lajoskatona> regarding taas and that the CLI code is historically in the taas repo and not in neutronclient like it is for other stadiums
14:41:14 <lajoskatona> I am not sure if we need and RFE for it, or just a bug enough
14:42:11 <mlavalle> I don't think so. It is bringing this project in line with the rest of the stadium
14:42:54 <lajoskatona> exactly
14:43:43 <haleyb> so the ask is to add taas commands to the network CLI?
14:44:16 <ralonsoh> ^^ I have the same question
14:44:43 <lajoskatona> In python-neutronclient under the OSC folder we have CLI code for other stadiums
14:45:01 <lajoskatona> https://opendev.org/openstack/python-neutronclient/src/branch/master/neutronclient/osc/v2
14:45:13 <haleyb> ah yes, a lot of them
14:45:17 <lajoskatona> so the goal is to move the current taas CLI code to this folder
14:45:25 <ralonsoh> yeah but I think the decision was to have the OSC plugin in the repos
14:45:29 <ralonsoh> https://github.com/openstack/tap-as-a-service/tree/master/neutron_taas/taas_client/osc
14:45:36 <ralonsoh> if I'm not wrong
14:45:48 <lajoskatona> thanks this is the current code
14:46:24 <ralonsoh> sorry, why do they need that in neutronclient?
14:47:16 <lajoskatona> mnasser's issue is that when they deploy the CLI (I suppose in container) they have to install taas and that pulls in neutron as well to the container
14:47:30 <ralonsoh> ahhh understood
14:47:46 <lajoskatona> but if they install neutronclient with all the dependencies no more hedache with the size
14:47:54 <ralonsoh> yeah, makes sense
14:49:17 <ralonsoh> just asking: these are OSC extensions, right?
14:49:24 <ralonsoh> why not moving them to OSC?
14:49:35 <lajoskatona> yes OSC
14:50:05 <lajoskatona> no idea, I suppose openstackclient tried to keep these things away from their umbrella and maintenance
14:50:40 <ralonsoh> yeah... ok, let me ask this question to OSC mantainers (stephenfin for example)
14:51:18 <ralonsoh> in any case, we can do this: we can move this code to neutronclient for now
14:51:22 <lajoskatona> good idea, perhaps the simpler would to move all the things in neutronclient to OSC finally
14:51:30 <lajoskatona> thanks
14:51:32 <stephenfin> ralonsoh: I was wondering the same thing myself recently :)
14:51:50 <haleyb> right, because we have 7 other directories of code in neutronclient
14:52:02 <ralonsoh> so that could be something for 2026.1: to move the OSC extensions to OSC
14:52:07 <stephenfin> neutronclient uses SDK for everything now, right? Or does it still use the deprecated neutronclient lib?
14:52:23 <ralonsoh> stephenfin, good question, for sure
14:52:35 <lajoskatona> no I beleive I cut all the code for the old python bindings
14:52:41 <ralonsoh> I can't confirm that but these are OSC extensions, should relay on SDK
14:52:57 <stephenfin> If it uses SDK for everything then I see no reason not to move it wholesale to OSC
14:53:09 <ralonsoh> nice to read that
14:53:14 <stephenfin> and probably make you folks full core there so I don't have to review everything
14:53:27 <ralonsoh> hehehe ok
14:53:36 <lajoskatona> we can start that as a goal for the coming cycle :-)
14:53:50 <ralonsoh> ^ +1
14:54:06 <haleyb> sure, and it gets us a good ptg topic too :)
14:54:44 <mlavalle> lol
14:55:04 <lajoskatona> :-)
14:56:10 <lajoskatona> than I think that's it for this topic, the goal is to move all things to OSC, have a discussion on the PTG
14:56:37 <haleyb> ok, sounds good, do you want to respond to mnaser on the ML?
14:57:04 <lajoskatona> yes I can
14:57:21 * haleyb is getting better at delegating :)
14:57:34 <lajoskatona> :D
14:57:36 <haleyb> alright we're at end of hour, any other topics
14:57:44 <haleyb> thanks for that one lajoskatona btw
14:58:15 <haleyb> ok, thanks for attending and have a good weekend!
14:58:18 <haleyb> #endmeeting