Friday, 2025-11-21

ykarelralonsoh, ack04:48
ykarelhmm so it fails even with 1 concurrency04:54
opendevreviewRodolfo Alonso proposed openstack/ovsdbapp master: DNM == Test functional job on top of patch 967844  https://review.opendev.org/c/openstack/ovsdbapp/+/96784305:30
opendevreviewyatin proposed openstack/ovsdbapp master: Revert "Rework venv to support arbitrary schemas"  https://review.opendev.org/c/openstack/ovsdbapp/+/96784405:53
opendevreviewRodolfo Alonso proposed openstack/ovsdbapp master: DNM == Test functional job on top of patch 967844  https://review.opendev.org/c/openstack/ovsdbapp/+/96784305:54
ykarelralonsoh, ^ works with full revert06:30
opendevreviewRodolfo Alonso proposed openstack/ovsdbapp master: DNM == Test functional job, concurrency=1  https://review.opendev.org/c/openstack/ovsdbapp/+/96784206:54
ralonsohykarel, so the problem is this patch06:54
ykarelyeap06:55
ralonsohok, good to know. For now, we need to revert it and release again ovsdbapp06:55
ralonsohonce Terry is back, I'll ping him06:55
ykarelyeap agree06:55
ralonsohykarel, what patch are you reverting?06:55
ralonsohbecause https://review.opendev.org/c/openstack/ovsdbapp/+/967844 has two06:56
ykarelralonsoh, both needed06:56
ralonsohahhh ok06:56
ykarelas second one was dependent on the first06:56
ykarelthat's why your original attempt to test the revert failed06:57
ralonsohyeah, I see it now. Thanks!06:57
opendevreviewSergey Kraynev proposed openstack/neutron master: Replace response body in after hook for 404 error  https://review.opendev.org/c/openstack/neutron/+/96649806:58
ralonsohok, I'm fast approving this and creating a release patch06:59
opendevreviewRodolfo Alonso proposed openstack/ovsdbapp master: DNM == Test functional job on top of patch 967844  https://review.opendev.org/c/openstack/ovsdbapp/+/96784307:03
opendevreviewyatin proposed openstack/neutron master: Revert "[eventlet-removal] Handle stop DHCP agent"  https://review.opendev.org/c/openstack/neutron/+/96780808:01
ykarelralonsoh, rebased and updated commit message with relevant bugs^08:02
ralonsohthanks08:02
opendevreviewMerged openstack/ovsdbapp master: Revert "Rework venv to support arbitrary schemas"  https://review.opendev.org/c/openstack/ovsdbapp/+/96784408:59
ralonsohhaleyb, please check https://review.opendev.org/c/openstack/releases/+/96796709:05
opendevreviewMerged openstack/neutron stable/2024.2: [FT] Wait for the manager to be created  https://review.opendev.org/c/openstack/neutron/+/96733910:19
opendevreviewMerged openstack/ovn-bgp-agent stable/2024.2: Ensure that bridge exist and UP before adding tables  https://review.opendev.org/c/openstack/ovn-bgp-agent/+/94715210:37
opendevreviewLajos Katona proposed openstack/neutron master: [eventlet-removal] Handle systemctl stop for DHCP agent  https://review.opendev.org/c/openstack/neutron/+/96790210:43
*** tkajinam is now known as Guest3183611:05
ykarelslaweq, lajoskatona please do check the revert https://review.opendev.org/c/openstack/neutron/+/96780811:23
opendevreviewMerged openstack/neutron master: [OVN] Initialize OVN agent in ``start`` method  https://review.opendev.org/c/openstack/neutron/+/96721911:24
lajoskatonaykarel: sure, I updated my patch on top of it11:58
opendevreviewaarefiev proposed openstack/os-ken master: BGP: allow create multiple speakers  https://review.opendev.org/c/openstack/os-ken/+/96768813:17
opendevreviewMerged openstack/ovn-bgp-agent stable/2025.1: Ensure that bridge exist and UP before adding tables  https://review.opendev.org/c/openstack/ovn-bgp-agent/+/94715113:31
cardoeAm I in the wrong channel for the drivers meeting?14:03
mlavallehaleyb, are we meeting today?14:03
haleybmlavalle: yes, i think i got the time wrong again14:04
cardoemlavalle: I wanted to talk to you about segment binding... specifically your spec and https://review.opendev.org/c/openstack/neutron/+/840418 wrt to https://bugs.launchpad.net/networking-generic-switch/+bug/211445114:04
haleyblet me start the meeting14:05
haleyb#startmeeting neutron_drivers14:05
opendevmeetMeeting started Fri Nov 21 14:05:55 2025 UTC and is due to finish in 60 minutes.  The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot.14:05
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:05
opendevmeetThe meeting name has been set to 'neutron_drivers'14:05
haleybPing list: ykarel, mlavalle, mtomaska, slaweq, tobias-urdin, lajoskatona, haleyb, ralonsoh14:05
mlavalle\o14:06
cardoeo/14:06
haleybi know rodolfo was online earlier but don't see him now14:06
mtomaskao/14:06
slaweqo/14:06
ralonsohhi (late)14:06
TheJuliao/14:07
ralonsohsorry, is the drivers meeting ongoing now?14:07
haleybralonsoh: yes, i was late as well, just started14:07
ralonsohcool14:07
haleybwe had a few things on the list14:08
haleybfirst one was from dsan14:08
haleyb#link bugs.launchpad.net/neutron/+bug/212383614:08
haleybthere is also a patch14:08
haleybi'm not sure they are here, can move to second item14:09
dsano/14:09
cardoelol ran in as the doors closed14:10
haleybdsan: hi, i had commented in the bug and think others had looked at the change14:10
slaweqI just looked at it now14:10
slaweqand it looks ok for me14:10
ralonsohsame for me, being this option configurable and disabled by default14:11
ralonsohjust a question: is it possible to have something else apart from unit tests?14:11
ralonsohsomething that spawns dnsmasq with this option and other agent making this query?14:12
haleybmy only comment (in the bug) is should the dhcp-agent be using this as well as liveness check, and restart any dnsmasq that doesn't respond?14:12
haleybbut if others are fine with it...14:12
ralonsohhaleyb, we never consider that14:13
ralonsohbut I think that could be a follow up RFE14:13
slaweqhaleyb: IMO this could be potential follow up improvement14:13
haleybsure, that would work. it's not something you can put on a dashboard but could help14:14
haleybralonsoh: regarding your testing ask, that would be good - dsan is that doable?14:15
slaweqI'm not sure what you want to test there? Wouldn't it be testing of dnsmasq itself actually?14:16
slaweqdo we need that really?14:16
ralonsohyes, that will test dnsmasq14:16
dsanmeaning like adding a dns check ?14:17
ralonsohyes14:17
dsanguess it's doable14:17
dsanthere's not much input validation as is14:18
haleybso more a functional test14:18
dsani was wondering if and how to do that14:18
dsaninside dnsmasq it's only string manipulation14:19
dsannot really if it's a valid txt record14:19
dsanright now if we feed a wrong config value14:20
dsandnsmasq won't start and output an error14:20
dsannot sure if it's acceptable14:20
dsanor if a preflick check is needed14:20
slaweqIMO it is acceptable14:21
dsanok14:21
haleybi'm thinking just the positive check would be necessary, i.e. start dnsmasq and use dig to get the txt message and verify it's what it should be?14:22
dsanthen I look into adding a little dns test14:22
haleybralonsoh: is that what you were thinking?14:22
ralonsohyes14:22
haleybgreat, so we should vote, +1 from me14:23
mlavalle+114:23
slaweq+114:23
ralonsoh+114:23
haleybok, i'll mark it approved, and thanks for working on it dsan 14:23
haleybralonsoh: the next topic was yours14:24
ralonsohthanks14:24
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/197094414:24
ralonsohSo the goal is to replace the keepalived-state-change script for something not so heavy (in RAM terms)14:25
ralonsohwe already discussed that in the PTG14:25
ralonsohinitially we were using keepalived notify_scripts14:25
ralonsohbut we move to the python script in https://review.opendev.org/c/openstack/neutron/+/125384 because the errors present when multiple quick transitions happened14:26
ralonsohhowever this error was still present in next released14:26
ralonsohthis is why I proposed https://review.opendev.org/q/I70037da9cdd0f8448e0af8dd96b4e3f5de5728ad (6 years ago)14:26
opendevreviewMerged openstack/neutron master: Revert "[eventlet-removal] Handle stop DHCP agent"  https://review.opendev.org/c/openstack/neutron/+/96780814:27
ralonsohso the point is going back to the notify_scripts, but this time making it configurable (for a period of time)14:27
ralonsohso a user will be able to choose between python script or notify_scripts14:27
ralonsohif we switch to notfy_scripts by default and that works, we can remove the python script implementation14:28
ralonsohPOC: https://review.opendev.org/c/openstack/neutron/+/96590914:28
ralonsoh2 questions:14:28
ralonsoh1) Do you agree with this strategy14:28
ralonsoh2) I'm not going to implement it, someone have time for this? Someone interested in the ML2/OVS backend14:28
haleybI agree we should fix the memory issue, but also cannot implement it14:30
slaweqI like this new approach, I think it should be better14:31
ralonsohso if we vote for it, haleyb will you send a mail to ask for volunteers?14:32
haleybso you remember who noticed the memory issue? not to task them but just so they can be involved14:32
ralonsohzigo ^14:32
haleybralonsoh: yes, i could send something to the ML14:32
haleybhe might be offline14:34
* zigo is looking this up14:34
ralonsohfrom PTG etherpad: (zigo) Some numbers from our public cloud related to that: in a random network node in production, we have 673 instances of this process. That's 65 GB of RAM14:35
zigoralonsoh: It's be nicer if the neutron/agent/l3/keepalived-state-change.sh file was located in /usr/bin and  had "neutron-" at the begining of its name.14:35
zigoAlso, you're not removing the older script, are you?14:35
ralonsohthis is another alternative14:35
ralonsohwe are discussing using notify_scripts (form keepalived) again14:36
ralonsohthat will be much easier14:36
ralonsoh(ok, you are already talking about https://review.opendev.org/c/openstack/neutron/+/965909/1/neutron/agent/l3/keepalived-state-change.sh)14:37
lajoskatonao/14:37
zigoYeah, I was.14:37
ralonsohso yes, that could be changed. The final location of the file depends on the toml file, that moves this file where needed14:37
zigoI'm just not a fan of having executed files in private directories. Also, the distro policies say you shouldn't use ".sh" as extension: from a user standpoint, the implementation language has no value, and therefore the extension shouldn't be used.14:38
zigoIf you don't do all of this, I'll have to cary a Debian specific patch, which is very annoying.14:39
zigo(these are just pieces of advices on the implementation... nothing blocking though)14:39
haleybzigo: well, we are also looking for someone to do the work14:40
zigoAbout using keepalived own implementation: I have no idea if it made progress over the last 10 years or not.14:40
zigoThough it worries me that its call was removed in 2014, and we don't know why.14:40
lajoskatonazigo: but the basic idea to replace python with shell script is acceptable from distro maintaner perspective and can be accepted?14:40
zigoYeah, I like the idea.14:40
lajoskatonaak14:41
lajoskatonaack14:41
haleybor have the choice? i think that's what ralonsoh said above? i.e. a config option14:41
zigoAn implementation in a better language could be cool too (C / Rust anymore ? :P )14:41
ralonsohinitially we can implement both and make it configurable14:42
zigoMaybe on a side proect to depend on?14:42
ralonsohbut there is not need for this14:42
ralonsohkeepalived notify_script is expecting a simple script, for example a bash script14:42
ralonsohnothing complex (actually we need to write a file and send a socket message)14:43
zigoWell, I still don't like the fact that it doesn't scale. Reducing the memory footprint is cool, but what if I get 6000 instances instead of 600 ?14:43
zigoI'd say it's a good and fast approach to fix things quick.14:43
ralonsohsorry, I dont' understand14:44
zigo(well, to tell the truth: if I had 6000 HA router on a network node, I'd have other issues too ... :P)14:44
ralonsohif you have 6000 instances you will still need 6K instances of keepalived, not any python script to monitor the state change14:44
lajoskatonawhat if we say that here's a reference implementation in shel, this is the interface in the documentation how it should behave do it yourself if you need something more14:44
slaweqlajoskatona: you mean to make that notify script configurable?14:45
slaweqand give operators way to bring their own one14:46
zigoralonsoh: The point I'm making is that the current situation where we spawn a long-lived daemon forever isn't ideal, because (not depending on how much memory it takes) it's going to always grow...14:46
slaweqif yes, I like that idea14:46
lajoskatonaslaweq: yes,something like that14:46
ralonsohzigo, what daemon?14:46
zigoThe current script no?14:46
ralonsohno14:46
ralonsohnotify_scripts doens't work like this14:46
zigoIs it spawned, then dies?14:46
ralonsohyes14:47
zigoOk, then I shut up. :P14:47
ralonsohkeepalived will call it when active/backuop event happens14:47
ralonsohand the execution should take milliseconds14:47
zigoThen maybe, my idea of writing it in something less heavy than bash isn't that stupid.14:48
zigoralonsoh: You'll be surprised how heavy bash is.14:48
zigoIf you do something in Bash, I'll write an MR to do it at least in dash... :P14:48
zigoIt will spawn at least 3 times faster.14:48
zigoAnyways, yeah, all my support for this !14:49
ralonsohas commented before, we need someone to take the lead on this implementation14:49
ralonsohI won't be able to continue14:49
slaweqI think that we can use "sh" maybe instead of bash but I wouldn't go with something like dash there14:49
ralonsohso if you are able to do this or someone else you know, that wil be perfect14:49
zigoslaweq: /bin/sh in Debian is dash, which is why I'm writing this.14:50
lajoskatonayes we have to select something that first works in the CI :-)14:50
zigodash == iso shell, no bashism involved.14:50
slaweqok, I didn't know that14:50
ralonsohok, let's keep the implementatikon for the patch14:50
haleybok, we still have one more item on agenda so should finish up14:50
ralonsohwe should vote for this idea14:50
haleybstill need someone to own it14:50
zigoralonsoh: Your previous bash implementation was really fine, IMO.14:50
zigoAt least as a first approach.14:50
ralonsohthat is discarded now14:51
zigo:/14:51
haleybi vote to go forward with this, pending an owner14:51
slaweq+114:51
ralonsoh+114:51
lajoskatona+1, I check with my management  (I have anyway long discussions with them in the recent weeks....)14:52
zigoI'm +1 on anything that fixes the current situation, whatever implementation that is.14:52
mlavalle+114:52
opendevreviewBodo Petermann proposed openstack/neutron master: Allow plugins to add periodics to maintenance worker  https://review.opendev.org/c/openstack/neutron/+/93981714:52
haleybok, so i guess we can change the existing bug to have rfe tags, and i can send an email to list asking for an owner14:52
lajoskatona+114:53
haleybok, last topic was from cardoe 14:53
haleyband sorry for not having a lot of time14:53
cardoeWell happy to do what I can.14:53
cardoeI can throw a meetpad link but Ironic boxes will likely take longer than 5 minutes to boot all the way up14:54
ralonsohit's ok, no problem14:55
TheJuliaThe ask was for some sort of demo to advance the basic understanding... so maybe why not and just keep going in a separate forum ?14:55
ralonsohwe can close the drivers meeting and join the meetpad14:55
cardoehttps://meetpad.opendev.org/neutron-vxlan-demo14:55
lajoskatonaI am on mobile-net in a car currently, but I try....14:55
haleybalright i will end this meeting then, i don't have a conflict for 30 minutes14:56
haleyb#endmeeting14:56
opendevmeetMeeting ended Fri Nov 21 14:56:58 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:56
opendevmeetMinutes:        https://meetings.opendev.org/meetings/neutron_drivers/2025/neutron_drivers.2025-11-21-14.05.html14:56
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2025/neutron_drivers.2025-11-21-14.05.txt14:56
opendevmeetLog:            https://meetings.opendev.org/meetings/neutron_drivers/2025/neutron_drivers.2025-11-21-14.05.log.html14:56
opendevreviewMerged openstack/neutron master: [OVN] The external networks GW chassis must the same as the GW LRP  https://review.opendev.org/c/openstack/neutron/+/96215515:11
opendevreviewJakub Libosvar proposed openstack/ovsdbapp master: Add Neutron functional test to the gate queue  https://review.opendev.org/c/openstack/ovsdbapp/+/96803115:23
haleyband i think i killed that meeting16:01
cardoeThanks everyone for taking the time with us today.16:26
cardoeTheJulia: I didn't kill the call did I?16:33
opendevreviewJakub Libosvar proposed openstack/neutron master: bgp: Add event to create BGP chassis resources  https://review.opendev.org/c/openstack/neutron/+/96185416:57
TheJuliacardoe: no, you didn't. it was all good17:15
noonedeadpunkhey folks - any chance to get this reviewed? https://review.opendev.org/c/openstack/neutron/+/96298517:35
noonedeadpunkthis one actually fixes the issue which ralonsoh attempted to fix as well17:36
noonedeadpunkbut also would be finally to fix auto-allocations docs: https://review.opendev.org/c/openstack/neutron/+/936643 17:37
noonedeadpunk*would be nice17:38
opendevreviewMerged openstack/neutron master: [SGL] Ignore port groups that don't come from SGs  https://review.opendev.org/c/openstack/neutron/+/96758318:07
opendevreviewMerged openstack/neutron master: [doc] Update plugins needed for auto-allocation  https://review.opendev.org/c/openstack/neutron/+/93664319:00
opendevreviewMerged openstack/neutron master: [OVN] Sync the LRP Gateway_Chassis with the network HCG  https://review.opendev.org/c/openstack/neutron/+/96438120:48
opendevreviewRodolfo Alonso proposed openstack/neutron master: Maintenance method to update the LRP from GC to HCG  https://review.opendev.org/c/openstack/neutron/+/94790621:07
opendevreviewRodolfo Alonso proposed openstack/neutron master: Use HA_Chassis_Group in the OVN L3 scheduler  https://review.opendev.org/c/openstack/neutron/+/94731721:08
opendevreviewRodolfo Alonso proposed openstack/neutron master: Remove check support for NB ``Gateway_Chassis`` table  https://review.opendev.org/c/openstack/neutron/+/96535121:08
opendevreviewRodolfo Alonso proposed openstack/neutron master: WIP == Remove ``_add_gateway_chassis`` auxiliary method  https://review.opendev.org/c/openstack/neutron/+/96535421:08
opendevreviewBrian Haley proposed openstack/neutron master: Add ovn-agent to metadata caching doc  https://review.opendev.org/c/openstack/neutron/+/96808021:18
opendevreviewBrian Haley proposed openstack/neutron master: Change some common test code to use project_id  https://review.opendev.org/c/openstack/neutron/+/96808321:31
opendevreviewBrian Haley proposed openstack/neutron master: Change some unit test code to use project_id  https://review.opendev.org/c/openstack/neutron/+/96808421:31
opendevreviewBrian Haley proposed openstack/neutron master: Change some functional test code to use project_id  https://review.opendev.org/c/openstack/neutron/+/96808521:31
opendevreviewMerged openstack/neutron-vpnaas master: Fix report_status function in ovn setups  https://review.opendev.org/c/openstack/neutron-vpnaas/+/96349321:52

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