14:01:04 <haleyb> #startmeeting networking
14:01:05 <opendevmeet> Meeting started Tue Nov 18 14:01:04 2025 UTC and is due to finish in 60 minutes.  The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:05 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:05 <opendevmeet> The meeting name has been set to 'networking'
14:01:14 <haleyb> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, haleyb, ralonsoh
14:01:15 <mlavalle> \o
14:01:17 <elvira> o/
14:01:17 <lajoskatona> o/
14:01:23 <ralonsoh> hello
14:01:23 <mtomaska> o/
14:02:21 <haleyb> #announcements
14:02:44 <haleyb> We are in week R-19 of Gazpacho
14:02:48 <rubasov> o/
14:02:59 <haleyb> We are now past the gazpacho-1 milestone
14:03:13 <haleyb> Our next milestone in this development cycle will be gazpacho-2, on January 8, 2026
14:03:43 <haleyb> #link https://releases.openstack.org/gazpacho/schedule.html
14:03:47 <bcafarel> o/
14:04:21 <haleyb> We did push release tags for neutron and other things
14:04:49 <haleyb> I think maybe ovsdbapp is the only one still in progress
14:05:37 <ralonsoh> is merged now
14:05:58 <haleyb> perfect
14:06:17 <ralonsoh> related to this ^
14:06:20 <ralonsoh> please check https://review.opendev.org/c/openstack/neutron/+/967395
14:06:40 <ralonsoh> in order to keep the CI working once the requirements patch bumps the version
14:06:56 <haleyb> yup
14:08:15 <haleyb> we've been doing good at fixing any leftover eventlet issues, thanks for everyone finding the bugs and working on them
14:09:13 <lajoskatona> we have a frsh one: https://bugs.launchpad.net/neutron/+bug/2131801 :-)
14:09:16 <haleyb> Reminder: If you have a topic for the drivers meeting on Friday, please add it to the wiki @ https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
14:09:19 <haleyb> :(
14:10:03 <ralonsoh> we can talk about this one in the eventlet section
14:10:17 <haleyb> And continue to use the priorities dashboard for important changes or things ready to merge
14:10:27 <haleyb> #link https://tinyurl.com/59z278km
14:10:46 <haleyb> I have a few easy ones there that could use another +2
14:11:00 <haleyb> that was all the neutron announcements i had, any others?
14:11:30 <haleyb> #topic bugs
14:11:40 <haleyb> mtomaska was the bug deputy last week, his report is at
14:11:46 <haleyb> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/DDNPSGVJY7PAHSTX7IYZS7ZD6MEE7GEZ/
14:12:24 <haleyb> some have been picked-up but let's look at the others
14:12:30 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2131087
14:12:37 <haleyb> Is updating a port's fixed_ip list without specifying existing IP addresses valid?
14:13:25 <mtomaska> In my opinion it should be and looks like code already does it. If we agree then we should just add some unit tests to reinforce that
14:13:43 <mtomaska> but I left it as an opinion for now. I am open for others opinions
14:14:33 <haleyb> i was looking at the api ref but it's not clear there (to me)
14:14:45 <haleyb> #link https://docs.openstack.org/api-ref/network/v2/index.html#ports
14:15:19 <ralonsoh> this is also related to the issue with the metadata port, adding multiple subnets at the same time
14:15:37 <ralonsoh> the IPAM module computes the subnet IPs at once
14:15:48 <ralonsoh> so there is no API to just add one single IP
14:15:59 <ralonsoh> you pass all the subnets/fixed_ips in one command
14:16:12 <slaweq_web> but is there other method to remove specific IP from the port?
14:16:23 <ralonsoh> not that I'm aware
14:16:41 <ralonsoh> same for removal: you need to pass all the IPs of this port (removing the one not needed)
14:17:04 <slaweq_web> I think that if we want this API to be atomic we should do it in similar way as we did some time ago with (IIRC) router's static routes
14:17:13 <slaweq_web> I think rubasov was doing that
14:17:23 <ralonsoh> that will solve several problems we have now
14:17:55 <ralonsoh> of course, we'll need a big refactor in the IPAM module, that has not been touched in one decade
14:18:03 <slaweq_web> as original API required to always pass all exisitng and new routes and that was causing problems, but on the other hand it make it possible to remove routes too
14:18:41 <ralonsoh> IMO, that could be an interesting and practical feature
14:18:46 <slaweq_web> so I think that with current API which we have, if there is no other way to remove IP from the port, we should always set only those IPs which are send in request
14:19:12 <slaweq_web> but better API would be new one to add/remove fixed IPs to/from port
14:19:13 <rubasov> yes, we have now an extension for atomic updates to extraroutes, if that's relevant, that addressed the problem of races between api clients though
14:19:39 <ralonsoh> a similar API for port IPs could also solve some race conditions
14:19:56 <ralonsoh> e.g.: https://bugs.launchpad.net/neutron/+bug/2125500
14:20:06 <slaweq_web> I can take a closer look at that bug but for now that's my opinion about it :)
14:20:39 <ralonsoh> +1 to this
14:20:50 <mtomaska> Ok so it goes deeper I see. I thought it was pretty straight forward :)
14:21:00 <haleyb> the help message for 'port set' has a little better info at least
14:21:17 <haleyb> for --no-fixed-ip it says "Specify both --fixed-ip and --no-fixed-ip to overwrite the current fixed IP addresses"
14:21:26 <haleyb> that implies that --fixed-ip does not overwrite
14:21:51 <ralonsoh> no, but that the CLI
14:22:11 <ralonsoh> then, internally, it sends the full update: reads the current IPs, unset them and then set the new one
14:22:27 <mtomaska> ^ yep
14:22:28 <haleyb> ah, i did not look under the hood
14:22:32 <opendevreview> Mengyang Zhang proposed openstack/neutron-specs master: Create spec for RFE:project-specific qos controls  https://review.opendev.org/c/openstack/neutron-specs/+/965946
14:22:38 <mtomaska> I linked the code that does that
14:22:39 <rubasov> this is the api for the atomic extraroute stuff: https://docs.openstack.org/api-ref/network/v2/index.html#add-extra-routes-to-router (and the 'remove' part)
14:25:29 <haleyb> anyway, maybe someone can write these notes in the bug for whoever picks it up
14:26:07 <haleyb> if not i'll do it after meeting
14:26:52 <slaweq_web> haleyb: I will look at it deeper and will reply in the bug tomorrow
14:26:56 <opendevreview> Merged openstack/neutron stable/2025.2: [FT] Wait for the manager to be created  https://review.opendev.org/c/openstack/neutron/+/967337
14:27:10 <haleyb> slaweq_web: thanks!
14:27:13 <haleyb> next bug
14:27:23 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2130972
14:27:24 <haleyb> Show response body on GET enforcement request
14:27:42 <haleyb> this came in as a security issue, bug was un-embargoed
14:29:11 <haleyb> the submittor had started a proof of concept patch to demonstrate
14:29:34 <haleyb> ralonsoh: are you ok based on the latest comment there?
14:29:37 <opendevreview> Merged openstack/neutron stable/2025.1: [FT] Wait for the manager to be created  https://review.opendev.org/c/openstack/neutron/+/967338
14:29:53 <ralonsoh> yes, the patch works and the port information is not longer returned
14:30:08 <ralonsoh> now we have a small talk about what to return
14:30:27 <ralonsoh> I think this should be raise webob.exc.HTTPNotFound(msg)
14:30:36 <ralonsoh> same as in other methods, I'll comment in the patch
14:32:03 <slaweq_web> ++
14:32:24 <haleyb> ralonsoh: ack, thanks
14:34:08 <haleyb> one more unassigned bug
14:34:11 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2131290
14:34:24 <haleyb> Octavia OVN - ovsdbapp.exceptions.TimeoutException: Commands DbCreateCommand
14:34:49 <mtomaska> At first I thought this might be an issue with connecting to OVN services. But based on latest response, it is not
14:36:51 <haleyb> is it more just the ovn provider?
14:38:02 <haleyb> froyo_: don't know if you're around but maybe you can look at that ^^ ?
14:38:12 <froyo_> sure!
14:38:29 <haleyb> thanks
14:38:30 <froyo_> I will take a look
14:39:17 <slaweq_web> isn't it similar to https://bugs.launchpad.net/octavia/+bug/2080630 ?
14:41:19 <haleyb> looks similar, but i'll let froyo_ determine
14:41:48 <haleyb> last bug looks like an rfe, but will mention since i saw a comment from slaweq
14:41:51 <froyo_> ^ that one is already managed I sent some patches and waiting their reply
14:41:51 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2131072
14:42:04 <haleyb> [RFE] Publish network resource exists notification
14:42:52 <froyo_> slaweq_web: I will put a comment on 2080630 to get some feedback
14:43:40 <ralonsoh> haleyb, and where this info is stored? in the logs?
14:43:58 <haleyb> ralonsoh: for that rfe? i don't know
14:44:07 <mtomaska> I think for that RFE bug we just need to wait for more details. It is incomplete
14:44:21 <mtomaska> and then we will know better what to do with it
14:44:28 <ralonsoh> yeah, a bit of context and definition would be required
14:44:40 <ralonsoh> I suggest to ping the author to add this topic in the drivers agenda
14:44:48 <mtomaska> yep ^
14:45:25 <mtomaska> I can monitor that RFE and I will add it to agenda once it gets defined little better
14:45:27 <haleyb> yeah, i didn't know if anyone had seen those before (besides the links in the bug)
14:46:00 <haleyb> that was all the bugs, any others to discuss?
14:46:33 <haleyb> #topic specs
14:46:38 <haleyb> #link https://review.opendev.org/q/project:openstack/neutron-specs+status:open
14:47:22 <haleyb> i do see some of these were updated recently, thanks for that, i will take a look later this week
14:47:51 <haleyb> hopefully others can too :)
14:48:14 <haleyb> #topic community goals
14:48:28 <haleyb> lajoskatona: hi, any updates on neutronclient patches?
14:49:11 <lajoskatona> not much, I went back to nova to continue the floating IP patch
14:49:22 <lajoskatona> that's it for neutronclient
14:49:31 <haleyb> ack
14:49:55 <haleyb> ralonsoh: i'll let you give any eventlet update, there's been some fixes...
14:50:50 <ralonsoh> yes but the main issue now is the DHCP agent
14:50:55 <ralonsoh> so the problem since last patch
14:51:03 <ralonsoh> https://review.opendev.org/c/openstack/neutron/+/963386
14:51:12 <ralonsoh> is that we KILL EVERYTHING
14:51:21 <ralonsoh> including the dnsmasq processes
14:51:35 <ralonsoh> I'm spawning an old OVS system to confirm that
14:52:05 <ralonsoh> in that case, we should exit DHCP agent but leaving the dnsmasq processes
14:52:10 <lajoskatona> I check in my env how to kill the service but keep processes like dnsmasq alive
14:52:13 <ralonsoh> this is what is tested in tobiko
14:52:49 <ralonsoh> and the neytron-dynamic-routing project
14:53:11 <ralonsoh> is still broken since we remove the evnetlet utils in Neutron
14:53:21 <ralonsoh> and I didn't have too much time to investigate the problem
14:53:38 <ralonsoh> I'll send a mail today to try to engage someone else there
14:53:58 <ralonsoh> that's all
14:54:22 <haleyb> ralonsoh: ack, thanks for the update
14:54:34 <haleyb> lajoskatona: so you'll look at how to keep dnsmasq running?
14:54:56 <lajoskatona> yes, after the perfect kill I try to make it partial....
14:55:19 <haleyb> lajoskatona: ok, thanks
14:55:28 <lajoskatona> and keep in mind the conclusion for the patch which is for ovs-agent
14:55:35 <slaweq> lajoskatona: "perfect kill" sounds like something from video game :P
14:55:44 <lajoskatona> https://review.opendev.org/c/openstack/neutron/+/967105
14:56:03 <lajoskatona> slaweq: :-)
14:56:06 <haleyb> yes, or an alien/predator movie
14:56:28 <haleyb> ok, last topic
14:56:32 <haleyb> #topic on-demand
14:57:03 <haleyb> there was one topic, but seems like a reference to an rfe?
14:57:03 <slaweq> I have one quick question actually
14:57:15 <haleyb> slaweq: sure
14:57:30 <slaweq> I noticed today that I probably don't have access to the security vulnerabilities bugs anymore - did something changes with who can access them? Do you know maybe?
14:57:42 <opendevreview> Merged openstack/neutron master: [OVN] Use ``uuid.UUID`` to build a OVN database row  https://review.opendev.org/c/openstack/neutron/+/967395
14:58:34 <haleyb> slaweq: i remember something changed a while back, maybe you got removed? i'll try and find the group/list
14:58:58 <slaweq> thx haleyb
14:59:03 <mlavalle> I want to bring this spec to the team's attention https://review.opendev.org/c/openstack/neutron-specs/+/966334. This is the formatted version https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_f9d/openstack/f9d679643b7b4f2bae614f47a7c0b373/docs/specs/2026.1/multiple-segments-per-host-routed-net-ovn.html
14:59:07 <slaweq> we can talk about it in private too
14:59:38 <mlavalle> that's all from me
15:01:17 <haleyb> ok, we are at time, and the on-demand topic was related to a spec, so will review later
15:01:29 <lajoskatona> +1, will look at the spec
15:01:32 <haleyb> thanks for coming everyone, and will see people friday for drivers meeting
15:01:37 <haleyb> #endmeeting