Monday, 2025-12-01

ralonsohHi folks, some quick review patches from Takashi and Brian08:21
ralonsohhttps://review.opendev.org/c/openstack/networking-sfc/+/96778308:21
ralonsohhttps://review.opendev.org/c/openstack/neutron-lib/+/96873208:21
ralonsohand this one from me:08:21
ralonsohhttps://review.opendev.org/c/openstack/neutron/+/96876908:21
opendevreviewRodolfo Alonso proposed openstack/neutron master: iPXE over IPv6 supported since OVN v23.06.0  https://review.opendev.org/c/openstack/neutron/+/96881108:28
ralonsohah, another 2 easy patches:08:28
ralonsoh* https://review.opendev.org/c/openstack/neutron/+/96880508:28
ralonsoh* https://review.opendev.org/c/openstack/neutron/+/96879708:28
blanson[m]Hello, we're hitting a weird bug that I can't seem to find on launchpad using caracal neutron with ovs. Sometimes (sometimes every week, sometimes every two weeks), we running into a stack trace in the main thread, because the rpc_loop function of the ovs_agent (https://github.com/openstack/neutron/blob/unmaintained/2024.1/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L2746) ends up calling uninstall_flow08:45
blanson[m]from ofswitch, which in turn calls a parser in os_ken (https://github.com/openstack/os-ken/blob/unmaintained/2024.1/os_ken/ofproto/ofproto_v1_3_parser.py), but doesn't pass kwargs and so this (https://github.com/openstack/os-ken/blob/unmaintained/2024.1/os_ken/ofproto/ofproto_v1_3_parser.py#L891-L894) raises because of a ValueError ? (not enough values to unpack (expected 2, got 0)) 08:45
blanson[m]Does that ring a bell to anyone ?08:45
lajoskatonablanson[m]: Hi, thanks, seems like we have it in zuul logs also: (https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_322/openstack/3223793519aa492583ed031e81fc0674/controller/logs/screen-q-agt.txt )08:53
ralonsohblanson[m], it would be better if you provide traces of the error, including logs from the OVS agent (better in debug mode)08:53
ralonsohand, if possible, a reproducer or a root cause of the issue08:53
blanson[m]not sure I should paste these directly into irc, I shall make a proper bug report then 08:54
lajoskatonablanson[m]: could you please open a bug with the details on launchpad?08:54
ralonsohblanson[m], yes, much better in launchpad08:54
lajoskatonablanson[m]: that will be perfect, thanks08:54
blanson[m]https://bugs.launchpad.net/neutron/+bug/2133487 here you go 09:07
blanson[m]we have plenty of logs so if you need more details just ask :) We'll debug it on our side aswell cause it's essentially crashing the ovs_agent everytime it happens and it needs a restart otherwise networking on the compute node is broken in so many ways09:08
lajoskatonablanson[m]: thanks09:10
ralonsohblanson[m], hi, if you are going to debug this issue locally, please try to add some extra logs in the os-ken library09:19
ralonsohin particular for kwargs in https://github.com/openstack/os-ken/blob/unmaintained/2024.1/os_ken/ofproto/ofproto_v1_3_parser.py#L891-L89409:19
ralonsohbefore and after the normalization method09:20
blanson[m]yh I was thinking of putting logs everywhere to get all the values passed around. I'll update the LP with the results aswell 09:21
ralonsohcool09:21
skraynevhello. could someone help to understand why policy was changed here: https://review.opendev.org/c/openstack/neutron/+/765847 I am wondering only about get_floatingip_port_forwarding . Previously it was allowed for member, but in this patch (and in current master branch) it requires reader role. and with member is not possible to get data11:15
skraynev@ralonsoh could you please help to solve this puzzle? ^^^ should it be only reader ? or member role also has to be added? 11:34
ralonsohlet me check11:35
ralonsohskraynev, that was changed in https://review.opendev.org/q/Ibff4c4f5b6d020fd598831a8a6e8ec0e2f55900511:50
skraynev@ralonsoh yeah. but here is still ADMIN_OR_PARENT_OWNER_READER , without member on get_floatingip_port_forwarding. other endpoints require member, but here is reader11:51
ralonsohlet me check11:52
ralonsohskraynev, can you describe the use case? So you have a member user and you try to read what FIPs?11:55
skraynevcorrect. I have user with role member, but without reader. and want to GET FIP port forwarding11:56
skraynevaccording policy it looks like I could not do it without role reader 11:57
ralonsohwho created these port forwarding resources?11:58
ralonsohskraynev, I can't reproduce the issue: I'm using admin/demo and demo/demo (a devstack deployment)12:02
ralonsoheven with a port, FIP and PF created by the admin user, I can list all with the demo user12:02
ralonsoh(in the same project)12:02
ralonsohskraynev, can you open a LP bug with a reproducer? creating a new user, who creates the port, the FIP, etc12:03
skraynev@ralonsoh I forgot to mention, that I just generate polcies based on the fresh policy. Looks like on your installation bug is not reproduced, because deprecated rule is used by default: https://github.com/openstack/neutron/blob/7fa7737947092c77cb2c210fd18c5adbb81e5223/neutron/conf/policies/floatingip_port_forwarding.py#L63-L6812:09
skraynevif to drop it from code - the new policy (with reader only) should be applied12:10
ralonsohright, I have this12:13
ralonsoh"get_floatingip_port_forwarding": "(rule:admin_only) or (role:reader and rule:ext_parent_owner)"12:13
ralonsohusing oslopolicy-policy-generator12:13
ralonsohskraynev, so I have role:reader but I can't reproduce your bug12:23
ralonsohI'm still able to list the PF12:23
skraynev@ralonsoh  does "demo" user have only "member" role? 12:24
ralonsohI have this:12:27
ralonsoh$ openstack role assignment list --user demo --names12:27
ralonsoh+-------------+--------------+-------+--------------+--------+--------+-----------+12:27
ralonsoh| Role        | User         | Group | Project      | Domain | System | Inherited |12:27
ralonsoh+-------------+--------------+-------+--------------+--------+--------+-----------+12:27
ralonsoh| anotherrole | demo@Default |       | demo@Default |        |        | False     |12:27
ralonsoh| member      | demo@Default |       | demo@Default |        |        | False     |12:27
ralonsoh+-------------+--------------+-------+--------------+--------+--------+-----------+12:27
ralonsohI can try deleting anotherrole12:27
ralonsohThe same: now "demo" has only "member" (one unique role)12:28
skraynevcould you please. if it will not change behaviour, I will go to deeply check my installation and try to reproduce on devstack12:28
ralonsohand the FIP was created by the admin user and the PF12:28
skraynevbtw, do you have existing policy yaml file ? or use defaults? I think, maybe oslo-policy use deprecated version, but prints new version. 12:31
skraynev@ralonsoh have you seen my last question about existing policy file? I have disconnect, so may be missed answer.13:08
ralonsohand now you look disconnected again...13:31
ykarel#startmeeting neutron_ci15:01
opendevmeetMeeting started Mon Dec  1 15:01:14 2025 UTC and is due to finish in 60 minutes.  The chair is ykarel. Information about MeetBot at http://wiki.debian.org/MeetBot.15:01
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:01
opendevmeetThe meeting name has been set to 'neutron_ci'15:01
ykarelPing list: bcafarel, lajoskatona, slawek, mlavalle, mtomaska, ralonsoh, ykarel, jlibosva, elvira15:01
ralonsohhello15:01
bcafarelo/15:01
ralonsohirc, right?15:01
ykarelYeap it's IRC today15:01
ykarel#topic Actions from previous meetings15:04
ykarellajoskatona to open bug for bagpipe failures and check15:04
ykarel#link https://bugs.launchpad.net/neutron/+bug/213235515:04
ykarelthe fix was merged15:04
ykarelthx lajoskatona 15:04
ykarelralonsoh to check functional timeout failure logs and accordingly bump timeout or track as a bug15:05
lajoskatonao/15:05
ykarel#link https://review.opendev.org/c/openstack/neutron/+/96821015:05
ykarelthx ralonsoh 15:05
ralonsohyw15:05
ykarel#topic Stable branches15:05
ykarelall looks good in stable as per periodic15:05
ykarelalso couple of patches merged in stable last week15:06
bcafarelyep15:06
ykarel#topic Stadium projects15:06
ykareldynamic-routing still broken https://zuul.openstack.org/buildset/116018d1fc3248a1a10f86688cb34e9415:06
ykarelKnown one https://bugs.launchpad.net/neutron/+bug/213063115:07
ykarellajoskatona, anything to add?15:07
lajoskatonanothing from me, only the bagpipe thing I had time last week15:07
ykarelok thx15:08
ykarel#topic Rechecks15:08
ykarelwe still have a few rechecks 15:08
ykarelbare rechecks wise 1/7 bare recheck15:09
ykarel1 was on some testing patch15:09
ykarelso let's keep avoiding bare rechecks15:09
ykarelnow let's check the failures15:09
ykarel#topic fullstack/functional15:09
ykareltest_add_manager_overwrites_existing_manager15:10
ykarel    https://b906e8bbacbb1d55ef2e-e8840ed1f498e2b83edb07bf05759e4c.ssl.cf5.rackcdn.com/openstack/e18b234e487d49e9853ec535778d8888/testr_results.html15:10
ykarelLooks need to reopen https://bugs.launchpad.net/neutron/+bug/213102415:10
ralonsohI'll check it15:11
ykarelthx15:11
ykarel#action ralonsoh to check lp#213102415:11
ykareltest_create_bridges15:11
ykarelhttps://45b67cabc958c12316a8-de1ec222256e01db8c1f1f4d7a4b9170.ssl.cf2.rackcdn.com/openstack/a451afbef2b44cc8ae8251874b98ef4c/testr_results.html15:11
ykarelLooks need to reopen https://bugs.launchpad.net/neutron/+bug/211490915:12
ykarelas we still seeing it15:12
ralonsohok, I'll check it again too15:12
ralonsohI think I pushed 2 patches recently15:12
ykarel#action ralonsoh to check lp#211490915:12
ykarelthx ralonsoh 15:12
ykarel#topic Periodic15:12
ykarelhttps://zuul.openstack.org/builds?job_name=ironic-tempest-ovn-uefi-ipmi-pxe&project=openstack%2Fneutron&skip=015:13
ykarelnew ovmf package fixed the issue, so all good now15:13
ykarel#topic Grafana15:13
ykarelhttps://grafana.opendev.org/d/f913631585/neutron-failure-rate15:13
ykarellet's have a quick check here too15:13
ykarellooks all good15:15
lajoskatona+115:16
ralonsohI think so15:16
ykarel#topic On Demand15:16
ykarelanything else you want to discuss15:16
ralonsohnothing from me15:16
lajoskatonanothing from my side15:16
bcafarelall good for me15:17
ykarelok thx15:18
ykarelin that case let's close early and have everyone almost 40 minutes back15:18
ykarel#endmeeting15:18
opendevmeetMeeting ended Mon Dec  1 15:18:36 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:18
opendevmeetMinutes:        https://meetings.opendev.org/meetings/neutron_ci/2025/neutron_ci.2025-12-01-15.01.html15:18
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/neutron_ci/2025/neutron_ci.2025-12-01-15.01.txt15:18
opendevmeetLog:            https://meetings.opendev.org/meetings/neutron_ci/2025/neutron_ci.2025-12-01-15.01.log.html15:18
ralonsohbye!15:18
lajoskatonao/15:20
opendevreviewRodolfo Alonso proposed openstack/neutron master: [FT] Wait for the manager to be created (2)  https://review.opendev.org/c/openstack/neutron/+/96910715:53
*** haleyb|out is now known as haleyb15:54
opendevreviewSlawek Kaplonski proposed openstack/neutron stable/2025.2: Don't prevent setting CIDRs as allowed_address_pair for port  https://review.opendev.org/c/openstack/neutron/+/96912617:20
opendevreviewSlawek Kaplonski proposed openstack/neutron stable/2025.1: Don't prevent setting CIDRs as allowed_address_pair for port  https://review.opendev.org/c/openstack/neutron/+/96912717:21
opendevreviewSlawek Kaplonski proposed openstack/neutron stable/2024.2: Don't prevent setting CIDRs as allowed_address_pair for port  https://review.opendev.org/c/openstack/neutron/+/96912817:21
cardoeSo are changes like https://review.opendev.org/c/openstack/neutron/+/968508 okay to make? I'm trying to test my l2vni and my code needs real NetworkContext and PortContext... the port one is a bit bigger but I just want to make sure that's something you guys would want.17:35
rm_workWe’re seeing a really strange issue with dnsmasq crashing (with a double-free error) when neutron replaces the additional hosts file (it is apparently designed to swap out the file inode to be threadsafe?) but I have a theory dnsmasq does not like this… just wondering if anyone else has seen similar issues.17:35
rm_workhttps://github.com/openstack/neutron/blob/stable/2024.2/neutron/agent/linux/dhcp.py#L120317:35
cardoerm_work: I believe we've seen that on the Ironic side as well. There's a newer dnsmasq that might fix it. I know JayF 18:08
cardoewas tracking the issue.18:08
JayFrm_work: yeah, make sure you're using the absolute latest dnsmasq release18:11
opendevreviewMerged openstack/neutron master: [OVN] Add 'provider:physical_network' field if there is physnet  https://review.opendev.org/c/openstack/neutron/+/96876919:35
opendevreviewMerged openstack/neutron master: Allow plugins to add periodics to maintenance worker  https://review.opendev.org/c/openstack/neutron/+/93981719:49
opendevreviewMerged openstack/neutron master: [docs] Add OVS/OVN min requirement table  https://review.opendev.org/c/openstack/neutron/+/96781619:49
opendevreviewMerged openstack/neutron-lib master: Replace deprecated warn_on_missing_entrypoint  https://review.opendev.org/c/openstack/neutron-lib/+/96873219:55
opendevreviewBrian Haley proposed openstack/neutron unmaintained/2024.1: Don't prevent setting CIDRs as allowed_address_pair for port  https://review.opendev.org/c/openstack/neutron/+/96915521:03
opendevreviewMerged openstack/neutron unmaintained/2024.1: Replace response body in after hook for 404 error  https://review.opendev.org/c/openstack/neutron/+/96833621:51
opendevreviewBrian Haley proposed openstack/neutron master: Change some common test code to use project_id  https://review.opendev.org/c/openstack/neutron/+/96808322:06
opendevreviewBrian Haley proposed openstack/neutron master: Change some unit test code to use project_id  https://review.opendev.org/c/openstack/neutron/+/96808422:07
opendevreviewBrian Haley proposed openstack/neutron master: Change some functional test code to use project_id  https://review.opendev.org/c/openstack/neutron/+/96808522:08
rm_workJayF: ah you’ve seen it? Is there an issue or something?22:08
opendevreviewBrian Haley proposed openstack/neutron master: Change test code to use project_id in dictionaries  https://review.opendev.org/c/openstack/neutron/+/96841422:08
JayFsaying I've "seen" that bug doesn't do it justice. I've been tracking it for years. It's finally fixed and in a release though so if you're on latest dnsmasq, you found a new one that rhymes22:08
opendevreviewBrian Haley proposed openstack/neutron master: Change some unit test code to use project_id  https://review.opendev.org/c/openstack/neutron/+/96808422:09
rm_workWe are literally .1 releases from newest on dnsmasq but can try it22:09
JayFhttps://bugs.launchpad.net/ironic/+bug/202675722:09
opendevreviewBrian Haley proposed openstack/neutron master: Change some functional test code to use project_id  https://review.opendev.org/c/openstack/neutron/+/96808522:09
opendevreviewBrian Haley proposed openstack/neutron master: Change test code to use project_id in dictionaries  https://review.opendev.org/c/openstack/neutron/+/96841422:09
JayFrm_work: ^ that bug has all the information in it I have22:09
JayFrm_work: anything else has been forgotten in my grey matter :D 22:09
rm_workOk I was looking for the bug on the neutron board, so that’s why I didn’t find it I guess22:09
JayFit's still "new" in neutron, looks like they never did a bug intake on it22:10
JayFnot that it was actionable by them, really22:10
rm_workWhelp.22:12
rm_workThis has been messing with us for months I think22:13
rm_workBeen trying to figure out our DHCP issues22:13
JayFwell go upgrade your local friendly dnsmasq22:13
JayFand consider investing in implementing another dhcp implementation for neutron's agent, potentially22:13
JayFwe (GR-OSS) looked at kea but abandoned the project when we realized all the good APIs were locked behind a paywall22:14
rm_workSo… at Yahoo, we (specifically one guy not me) wrote a drop in replacement that worked amazingly22:15
rm_workBut they didn’t open source it and I have been trying to get them to do it but don’t have good contacts there anymore22:15
JayFthat was an isc-dhcp-server implementation which we thought about upstreaming but didn't because isc-dhcp-server is no longer supported22:15
rm_workThe Python-trio one?22:15
JayF(ISC DHCP has so long unsupported that *I* was the one who was looking at upstreaming this during my small window that)22:16
JayFthe one in place when I was at the big purp was a driver that talked to isc-dhcp-server aka original dhcpd22:16
rm_workI kinda thought you had left already heh22:16
JayFif it's python-trio, I know who wrote the "new" one you're talking about22:16
JayFand upstream likely doesn't want it22:16
rm_workI believe it was Zach lol22:16
rm_workIt really did work fantastically22:17
JayFif it was written in the usual style of his stuff, adapting it to proper openstack style would be a heavy lift22:17
rm_workLikely true22:17
rm_workBut damn it worked well :/22:17
JayFsure, lots of things are unmaintainable and OK as long as they never need the maintenance lol22:17
rm_workWell, appreciate your response, we had been kinda tearing our hair out a little22:19
rm_workGranted our next step was to try an upgrade anyway but at least now we know why it was broken22:20
JayFthere was a short window of dnsmasq with a lot of memory-crashy issues22:21
JayFright around a refactor to eliminate those kinda issues :D 22:21
JayFas those things go, of course22:21
rm_worklol whelp22:23
rm_workSo Ubuntu has no version above 2.9.0 apparently22:24
JayFthat ticket has all the details about sru and how they fixed it, I'm not an ubuntu dude but I know the bug didn't express in our CI with the sru version they asked me to test22:24
rm_workGuess we’re just gonna build it22:29
haleybthere is version 2.91-1 in plucky and questing, 2.90-2 in noble22:54
haleyb$ rmadison dnsmasq22:58

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