Tuesday, 2025-11-18

opendevreviewMiguel Lavalle proposed openstack/neutron-specs master: Routed networks with multiple segments per host  https://review.opendev.org/c/openstack/neutron-specs/+/96633400:05
opendevreviewyatin proposed openstack/neutron-tempest-plugin master: Update jobs for unmaintained/2024.1  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/96747906:44
opendevreviewyatin proposed openstack/neutron unmaintained/2024.1: [CI][9-stream][stable only] Use last python3.9 supported tempest tag  https://review.opendev.org/c/openstack/neutron/+/96640006:47
ralonsohbcafarel, hello! If you have 1 min, I'll appreciate your reviews: https://review.opendev.org/q/topic:%22bug/2131024%2207:00
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] Initialize OVN agent in ``start`` method  https://review.opendev.org/c/openstack/neutron/+/96721907:39
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] Wait for the "Chassis" creation in the HCG tests  https://review.opendev.org/c/openstack/neutron/+/96678907:41
opendevreviewRodolfo Alonso proposed openstack/neutron stable/2025.1: [OVN] Initialize OVN agent in ``start`` method  https://review.opendev.org/c/openstack/neutron/+/96730207:42
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] The external networks GW chassis must the same as the GW LRP  https://review.opendev.org/c/openstack/neutron/+/96215507:42
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] Sync the LRP Gateway_Chassis with the network HCG  https://review.opendev.org/c/openstack/neutron/+/96438107:42
opendevreviewRodolfo Alonso proposed openstack/neutron master: Add a temporary grenade job migrating to OVN agent  https://review.opendev.org/c/openstack/neutron/+/95518807:50
opendevreviewyatin proposed openstack/neutron-tempest-plugin master: Update jobs for unmaintained/2024.1  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/96747908:25
*** elodilles_pto is now known as elodilles08:51
opendevreviewyatin proposed openstack/neutron-tempest-plugin master: Update jobs for unmaintained/2024.1  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/96747910:07
eolivarehey ralonsoh lajoskatona some tobiko ml2/ovs tests started failing last night: https://zuul.opendev.org/t/openstack/builds?job_name=devstack-tobiko-ovs&job_name=devstack-tobiko-ovs-neutron&pipeline=periodic&skip=010:43
ralonsoheolivare, let me check10:44
eolivareI think it's related to this patch: https://review.opendev.org/c/openstack/neutron/+/963386 - maybe the test has to be adapted, I'm not sure... let me explain what happens10:44
eolivareralonsoh, https://7a4385f7908bb667d94d-c0f8a1c31c5446efb34290a311cd3d95.ssl.cf1.rackcdn.com/openstack/49c140650f234818891e81b645154804/tobiko_results_03_faults_faults.html?sort=testId10:44
eolivarethis lines fails: https://github.com/redhat-openstack/tobiko/blob/master/tobiko/tests/faults/neutron/test_agents.py#L45510:45
eolivarethe test stops devstack@q-dhcp, then it restarts a VM and it expects that the VM is reachable (replies pings)10:46
ralonsoheolivare, let me check one thing10:47
ralonsoheolivare, https://review.opendev.org/c/openstack/neutron/+/96338610:48
eolivareIt fails because it doesn't reply pings. The test passed two days ago (no changes in the test): https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_0f0/openstack/0f01a7cff86245218a228b7f388b5057/tobiko_results_03_faults_faults.html?sort=result10:48
ralonsohso we stop the DHCP agent, right?10:48
eolivareyes10:48
eolivarerelevant logs are:10:48
eolivare2025-11-18 03:08:43.139 113081 DEBUG tobiko.tests.faults.neutron.test_agents - stop of the service 'devstack@q-dhcp' on host 'npc65d8c6c35e74' done.10:48
eolivare2025-11-18 03:08:45.419 113081 INFO tobiko.openstack.nova._client - stop server '14f56977-3bc5-489b-9f33-03692a06fb71' (status='ACTIVE').10:49
eolivare2025-11-18 03:08:50.886 113081 INFO tobiko.openstack.nova._client - Start server '14f56977-3bc5-489b-9f33-03692a06fb71' (status='SHUTOFF').10:49
ralonsohcan we sync via meet?10:50
eolivareand finally it tries `ping -4 -w 5 -W 5 -c 1 172.24.5.113` several times but it fails10:50
eolivareralonsoh, sure10:50
lajoskatonaeolivare, ralonsoh: Hi11:27
ralonsohlajoskatona, we found that now we are stopping the dnsmasq process11:27
ralonsohbefore the patch https://review.opendev.org/c/openstack/neutron/+/963386, the dnsmasq process was left running11:28
ralonsohI need to figure out what is the correct behaviour11:28
lajoskatonaralonsoh: ok, the dnsmasq processes should hang there? otherwise nobody will answer icmp requests.....11:29
ralonsohlajoskatona, sorry, what does it mean?11:29
ralonsohthe tobiko test is expecting dnsmasq to be running with the dhcp agent off11:29
ralonsohand it seems to be the behaviour for long time11:30
ralonsohI'm deploying a 2024.2 env to check that11:30
eolivarelajoskatona, ralonsoh https://bugs.launchpad.net/neutron/+bug/213180111:37
lajoskatonaeolivare: thanks11:37
eolivarewith the new behavior, if a cirros VM is restarted while the dhcp service is down, it will not be reachable - maybe a network restart would fix it - maybe advanced VM, such as ubuntu or fedora, would retry somehow, when dnsmasq and dhcp are recovered... I'd have to test it11:39
eolivareor maybe it's expected that a VM rebooting while dhcp+dnsmasq are down is not reachable anymore11:40
*** dmellado4 is now known as dmellado12:44
lajoskatonaeolivare: I check the merged patch where was the part which actually succesfully killed dnsmasq, strange that with eventlet it "just" worked, as service stop stopped the service but the processes like dnsmasq were left untouched12:46
ralonsohlajoskatona, yes, this is exactly what was happening13:35
ralonsohand now we stop the processmonitor AND the process itself13:35
ralonsohso we need to keep the dnsmasq running13:36
ralonsohto be honest, I wasn't expecting that13:36
lajoskatonaperfection is the rootcause of everything, and way to destruction :-)13:36
ralonsohI would prefer to discuss it in the neutron meeting13:36
lajoskatonaI was so happy to finally kill everything and look what happened :-)13:36
ralonsohlajoskatona, I really understand you13:37
ralonsohI'll create a topic today for the Neutron meeting13:37
haleyb#startmeeting networking14:01
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:01
opendevmeetThe meeting name has been set to 'networking'14:01
haleybPing list: bcafarel, elvira, frickler, mlavalle, mtomaska, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, haleyb, ralonsoh14:01
mlavalle\o14:01
elvirao/14:01
lajoskatonao/14:01
ralonsohhello14:01
mtomaskao/14:01
haleyb#announcements14:02
haleybWe are in week R-19 of Gazpacho14:02
rubasovo/14:02
haleybWe are now past the gazpacho-1 milestone14:02
haleybOur next milestone in this development cycle will be gazpacho-2, on January 8, 202614:03
haleyb#link https://releases.openstack.org/gazpacho/schedule.html14:03
bcafarelo/14:03
haleybWe did push release tags for neutron and other things14:04
haleybI think maybe ovsdbapp is the only one still in progress14:04
ralonsohis merged now14:05
haleybperfect14:05
ralonsohrelated to this ^14:06
ralonsohplease check https://review.opendev.org/c/openstack/neutron/+/96739514:06
ralonsohin order to keep the CI working once the requirements patch bumps the version14:06
haleybyup14:06
haleybwe've been doing good at fixing any leftover eventlet issues, thanks for everyone finding the bugs and working on them14:08
lajoskatonawe have a frsh one: https://bugs.launchpad.net/neutron/+bug/2131801 :-)14:09
haleybReminder: If you have a topic for the drivers meeting on Friday, please add it to the wiki @ https://wiki.openstack.org/wiki/Meetings/NeutronDrivers14:09
haleyb:(14:09
ralonsohwe can talk about this one in the eventlet section14:10
haleybAnd continue to use the priorities dashboard for important changes or things ready to merge14:10
haleyb#link https://tinyurl.com/59z278km14:10
haleybI have a few easy ones there that could use another +214:10
haleybthat was all the neutron announcements i had, any others?14:11
haleyb#topic bugs14:11
haleybmtomaska was the bug deputy last week, his report is at14:11
haleyb#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/DDNPSGVJY7PAHSTX7IYZS7ZD6MEE7GEZ/14:11
haleybsome have been picked-up but let's look at the others14:12
haleyb#link https://bugs.launchpad.net/neutron/+bug/213108714:12
haleybIs updating a port's fixed_ip list without specifying existing IP addresses valid?14:12
mtomaskaIn 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 that14:13
mtomaskabut I left it as an opinion for now. I am open for others opinions14:13
haleybi was looking at the api ref but it's not clear there (to me)14:14
haleyb#link https://docs.openstack.org/api-ref/network/v2/index.html#ports14:14
ralonsohthis is also related to the issue with the metadata port, adding multiple subnets at the same time14:15
ralonsohthe IPAM module computes the subnet IPs at once14:15
ralonsohso there is no API to just add one single IP14:15
ralonsohyou pass all the subnets/fixed_ips in one command14:15
slaweq_webbut is there other method to remove specific IP from the port?14:16
ralonsohnot that I'm aware14:16
ralonsohsame for removal: you need to pass all the IPs of this port (removing the one not needed)14:16
slaweq_webI 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 routes14:17
slaweq_webI think rubasov was doing that14:17
ralonsohthat will solve several problems we have now14:17
ralonsohof course, we'll need a big refactor in the IPAM module, that has not been touched in one decade14:17
slaweq_webas 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 too14:18
ralonsohIMO, that could be an interesting and practical feature14:18
slaweq_webso 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 request14:18
slaweq_webbut better API would be new one to add/remove fixed IPs to/from port14:19
rubasovyes, we have now an extension for atomic updates to extraroutes, if that's relevant, that addressed the problem of races between api clients though14:19
ralonsoha similar API for port IPs could also solve some race conditions14:19
ralonsohe.g.: https://bugs.launchpad.net/neutron/+bug/212550014:19
slaweq_webI can take a closer look at that bug but for now that's my opinion about it :)14:20
ralonsoh+1 to this14:20
mtomaskaOk so it goes deeper I see. I thought it was pretty straight forward :)14:20
haleybthe help message for 'port set' has a little better info at least14:21
haleybfor --no-fixed-ip it says "Specify both --fixed-ip and --no-fixed-ip to overwrite the current fixed IP addresses"14:21
haleybthat implies that --fixed-ip does not overwrite14:21
ralonsohno, but that the CLI14:21
ralonsohthen, internally, it sends the full update: reads the current IPs, unset them and then set the new one14:22
mtomaska^ yep14:22
haleybah, i did not look under the hood14:22
opendevreviewMengyang Zhang proposed openstack/neutron-specs master: Create spec for RFE:project-specific qos controls  https://review.opendev.org/c/openstack/neutron-specs/+/96594614:22
mtomaskaI linked the code that does that14:22
rubasovthis 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:22
haleybanyway, maybe someone can write these notes in the bug for whoever picks it up14:25
haleybif not i'll do it after meeting14:26
slaweq_webhaleyb: I will look at it deeper and will reply in the bug tomorrow14:26
opendevreviewMerged openstack/neutron stable/2025.2: [FT] Wait for the manager to be created  https://review.opendev.org/c/openstack/neutron/+/96733714:26
haleybslaweq_web: thanks!14:27
haleybnext bug14:27
haleyb#link https://bugs.launchpad.net/neutron/+bug/213097214:27
haleybShow response body on GET enforcement request14:27
haleybthis came in as a security issue, bug was un-embargoed14:27
haleybthe submittor had started a proof of concept patch to demonstrate14:29
haleybralonsoh: are you ok based on the latest comment there?14:29
opendevreviewMerged openstack/neutron stable/2025.1: [FT] Wait for the manager to be created  https://review.opendev.org/c/openstack/neutron/+/96733814:29
ralonsohyes, the patch works and the port information is not longer returned14:29
ralonsohnow we have a small talk about what to return14:30
ralonsohI think this should be raise webob.exc.HTTPNotFound(msg)14:30
ralonsohsame as in other methods, I'll comment in the patch14:30
slaweq_web++14:32
haleybralonsoh: ack, thanks14:32
haleybone more unassigned bug14:34
haleyb#link https://bugs.launchpad.net/neutron/+bug/213129014:34
haleybOctavia OVN - ovsdbapp.exceptions.TimeoutException: Commands DbCreateCommand14:34
mtomaskaAt first I thought this might be an issue with connecting to OVN services. But based on latest response, it is not14:34
haleybis it more just the ovn provider?14:36
haleybfroyo_: don't know if you're around but maybe you can look at that ^^ ?14:38
froyo_sure!14:38
haleybthanks14:38
froyo_I will take a look14:38
slaweq_webisn't it similar to https://bugs.launchpad.net/octavia/+bug/2080630 ?14:39
haleyblooks similar, but i'll let froyo_ determine14:41
haleyblast bug looks like an rfe, but will mention since i saw a comment from slaweq 14:41
froyo_^ that one is already managed I sent some patches and waiting their reply14:41
haleyb#link https://bugs.launchpad.net/neutron/+bug/213107214:41
haleyb[RFE] Publish network resource exists notification14:42
froyo_slaweq_web: I will put a comment on 2080630 to get some feedback14:42
ralonsohhaleyb, and where this info is stored? in the logs?14:43
haleybralonsoh: for that rfe? i don't know14:43
mtomaskaI think for that RFE bug we just need to wait for more details. It is incomplete14:44
mtomaskaand then we will know better what to do with it14:44
ralonsohyeah, a bit of context and definition would be required14:44
ralonsohI suggest to ping the author to add this topic in the drivers agenda14:44
mtomaskayep ^14:44
mtomaskaI can monitor that RFE and I will add it to agenda once it gets defined little better14:45
haleybyeah, i didn't know if anyone had seen those before (besides the links in the bug)14:45
haleybthat was all the bugs, any others to discuss?14:46
haleyb#topic specs14:46
haleyb#link https://review.opendev.org/q/project:openstack/neutron-specs+status:open14:46
haleybi do see some of these were updated recently, thanks for that, i will take a look later this week14:47
haleybhopefully others can too :)14:47
haleyb#topic community goals14:48
haleyblajoskatona: hi, any updates on neutronclient patches?14:48
lajoskatonanot much, I went back to nova to continue the floating IP patch14:49
lajoskatonathat's it for neutronclient14:49
haleyback14:49
haleybralonsoh: i'll let you give any eventlet update, there's been some fixes...14:49
ralonsohyes but the main issue now is the DHCP agent14:50
ralonsohso the problem since last patch14:50
ralonsohhttps://review.opendev.org/c/openstack/neutron/+/96338614:51
ralonsohis that we KILL EVERYTHING14:51
ralonsohincluding the dnsmasq processes14:51
ralonsohI'm spawning an old OVS system to confirm that14:51
ralonsohin that case, we should exit DHCP agent but leaving the dnsmasq processes14:52
lajoskatonaI check in my env how to kill the service but keep processes like dnsmasq alive14:52
ralonsohthis is what is tested in tobiko14:52
ralonsohand the neytron-dynamic-routing project14:52
ralonsohis still broken since we remove the evnetlet utils in Neutron14:53
ralonsohand I didn't have too much time to investigate the problem14:53
ralonsohI'll send a mail today to try to engage someone else there14:53
ralonsohthat's all14:53
haleybralonsoh: ack, thanks for the update14:54
haleyblajoskatona: so you'll look at how to keep dnsmasq running?14:54
lajoskatonayes, after the perfect kill I try to make it partial....14:54
haleyblajoskatona: ok, thanks14:55
lajoskatonaand keep in mind the conclusion for the patch which is for ovs-agent14:55
slaweqlajoskatona: "perfect kill" sounds like something from video game :P14:55
lajoskatonahttps://review.opendev.org/c/openstack/neutron/+/96710514:55
lajoskatonaslaweq: :-)14:56
haleybyes, or an alien/predator movie14:56
haleybok, last topic14:56
haleyb#topic on-demand14:56
haleybthere was one topic, but seems like a reference to an rfe?14:57
slaweqI have one quick question actually14:57
haleybslaweq: sure14:57
slaweqI 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
opendevreviewMerged openstack/neutron master: [OVN] Use ``uuid.UUID`` to build a OVN database row  https://review.opendev.org/c/openstack/neutron/+/96739514:57
haleybslaweq: i remember something changed a while back, maybe you got removed? i'll try and find the group/list14:58
slaweqthx haleyb 14:58
mlavalleI 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.html14:59
slaweqwe can talk about it in private too14:59
mlavallethat's all from me14:59
haleybok, we are at time, and the on-demand topic was related to a spec, so will review later15:01
lajoskatona+1, will look at the spec15:01
haleybthanks for coming everyone, and will see people friday for drivers meeting15:01
haleyb#endmeeting15:01
opendevmeetMeeting ended Tue Nov 18 15:01:37 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:01
opendevmeetMinutes:        https://meetings.opendev.org/meetings/networking/2025/networking.2025-11-18-14.01.html15:01
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/networking/2025/networking.2025-11-18-14.01.txt15:01
opendevmeetLog:            https://meetings.opendev.org/meetings/networking/2025/networking.2025-11-18-14.01.log.html15:01
lajoskatonao/15:01
mtomaskao/15:01
ralonsohbye15:01
ralonsohhi folks, if you have time, please check these 3 patches:15:05
ralonsoh* https://review.opendev.org/c/openstack/neutron/+/966789/15:05
ralonsoh* https://review.opendev.org/c/openstack/neutron/+/96215515:05
ralonsoh* https://review.opendev.org/c/openstack/neutron/+/964381/15:05
ralonsohthanks in advance15:05
opendevreviewMerged openstack/ovn-octavia-provider master: Member batch actions to increase performance  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/96523215:47
opendevreviewElvira García Ruiz proposed openstack/neutron master: [SGL] Ignore port groups that don't come from SGs  https://review.opendev.org/c/openstack/neutron/+/96758316:37
opendevreviewThéo Van Gyzel proposed openstack/neutron master: Fixed: network object was not updated after calling the enable driver while configure DHCP for a network  https://review.opendev.org/c/openstack/neutron/+/96232316:41
*** dmellado0 is now known as dmellado16:48
opendevreviewElvira García Ruiz proposed openstack/neutron master: [SGL] Ignore port groups that don't come from SGs  https://review.opendev.org/c/openstack/neutron/+/96758316:48
*** kleini- is now known as kleini17:17

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!