Friday, 2026-01-16

opendevreviewMerged openstack/neutron master: Docs Changes in CLI FQDN of Neutron BGP Speaker Create  https://review.opendev.org/c/openstack/neutron/+/97307303:53
opendevreviewRodolfo Alonso proposed openstack/neutron master: Test ovsdbapp change 973564  https://review.opendev.org/c/openstack/neutron/+/97358006:59
opendevreviewRodolfo Alonso proposed openstack/ovsdbapp master: Add Neutron functional test to the gate queue  https://review.opendev.org/c/openstack/ovsdbapp/+/96803107:17
opendevreviewRodolfo Alonso proposed openstack/neutron master: Fix ``LogicalRouterPortEvent`` when a LR is deleted  https://review.opendev.org/c/openstack/neutron/+/97358407:52
ralonsohslaweq, please, check ^^ (I would also need to backport in D/S)07:52
*** amorin_ is now known as amorin08:22
ykarelralonsoh, wrt https://review.opendev.org/c/openstack/neutron/+/97203909:32
ralonsohykarel, nice! now we need the nova patch, then the os-vif one and finally the upper patch there09:33
ykarelso in 2027.1 nova by default will create_tap?09:33
ralonsohhttps://review.opendev.org/c/openstack/neutron/+/95691009:33
ralonsohyes09:33
ralonsohat least for the kernel OVS ports (only)09:33
ykarelok somehow i misunderstood meeting discussion to enable the flag in neutron, but if nova will move to create_tap by default then makes sense09:34
ykareli am doing some local tests, then will update https://review.opendev.org/c/openstack/neutron/+/95691009:35
ralonsohcool09:35
ykarelfor os-vif we would also be requiring release/u-c update09:35
ralonsohat least in nova, yes09:35
ykarelralonsoh, and also these new config applies to both ml2/ovs and ovn ?09:37
ykarelbecause reading nova patch it says both09:38
ralonsohykarel, yes, the OVS plug applies to both backends. It would be needed a follow-up patch for ML2/OVN vif details09:38
ralonsohsorry, ML2/OVS09:39
ykarelok commented in nova patch09:39
ralonsohykarel, I'll push a patch today for Neutron09:40
ralonsohin any case, we are not testing it right now09:40
ralonsohso it will be a tech debt09:40
ykarelack09:42
opendevreviewRodolfo Alonso proposed openstack/neutron master: Fix ``LogicalRouterPortEvent`` when a LR is deleted  https://review.opendev.org/c/openstack/neutron/+/97358410:13
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] Check if the LSP is present when setting the port UP  https://review.opendev.org/c/openstack/neutron/+/97359910:56
opendevreviewMerged openstack/tap-as-a-service master: Remove unused and unmaintained script  https://review.opendev.org/c/openstack/tap-as-a-service/+/97340111:09
opendevreviewMerged openstack/neutron master: Add flag "ovs_create_tap" in the port VIF details  https://review.opendev.org/c/openstack/neutron/+/97203911:22
ralonsohsean-k-mooney, ^^ it is merged11:25
opendevreviewMerged openstack/neutron master: Make sure OVN PG is present before adding a SG rule  https://review.opendev.org/c/openstack/neutron/+/94621611:37
sean-k-mooneyralonsoh: cool, in that case i can enable it on the nova side in one of our migration jobs although we will need to merge the os-vif chagne and do a release and bump it in uc before  it would get tested end to end on master11:40
ralonsohright, we'll need a new os-vif release11:41
sean-k-mooneyill tweak the os-vif release note for yatins comment in a few minutes but i think that patch is more or less ready at this point11:41
sean-k-mooneyis "[OVN] Check if the LSP is present when setting the port UP" related to this as well?11:43
sean-k-mooneyi mean it soulld like a sepate bug but i wonder if that impacts live migration as well11:43
ralonsohsean-k-mooney, no, it is not11:44
ralonsohwhy you ask it?11:44
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] Check LRP presence in ``check_redirect_type_router_gateway_ports``  https://review.opendev.org/c/openstack/neutron/+/97360211:45
sean-k-mooneyjust saw the patch in the irc logs is all11:45
ralonsohsean-k-mooney, I'm just sending some fixes for bugs I've recently discovered11:45
ralonsohno no, not related11:45
sean-k-mooneyby the way ml2/ovs does not stricly need this since it does not depend on the of-port-id to work11:47
sean-k-mooneywith that said there is no downside to havign os-vif create the tap for ml2/ovs as well11:48
ralonsohsean-k-mooney, by default, because we are not sending the flag in the vif details, os-vif won't use that for ML2/OVS ports right now11:49
sean-k-mooneyand if we do that we also have a choice of how we defautlt to this in the future. i.e. nova could jsut alwasy pass the flag and not requrie netuon to set it or you can hard code the flag in the  ml2 driver11:49
ralonsohok11:49
sean-k-mooneycorrect it will not11:49
sean-k-mooneybut the bug we are fixign wont happen with ml2/ovs11:49
sean-k-mooneyon teh other hadn its nice if we keep the two consitent11:50
ralonsohin any case, I would need to propose a patch for ml2/ovs and then test it11:50
ralonsohI've talked to Yatin this morning about this11:50
sean-k-mooneyso reallly this si a judgement call and go with whatever you prefer11:50
ralonsohI think it makes sense and if Nova will deprecate the parameter passed by Neutron, that means both backends will be affected11:51
ralonsohso it will be better if we test it now that we can handle the Neutron flag11:51
sean-k-mooneyralonsoh: im getting solar installed today by the way so i had to shutdown the system i was usign to do developement and testing of this11:51
sean-k-mooneyhave you done any testing to see if this actully does impove the conectivy downtiem?11:52
ralonsohsolar??11:52
sean-k-mooneyyes im finally gettign arount ot haveing solar pannels installed 11:52
ralonsohcool!11:52
sean-k-mooneythat does mean my server that normally urns my devstack itnsase is currently in my liveign room unplugged. but i was wondering if you or ykarel looked at the time that the openflow rules were installed by ovn vs when the vif plugged evnets were being sent to confirm this is workign as intedned11:54
sean-k-mooneyobviouly we would need https://review.opendev.org/c/openstack/neutron/+/956910 to also wait for the lsp on the chassis11:55
ralonsohsean-k-mooney, I would need to deploy a second compute node11:58
ralonsohI need to check (again) how to do it with devstack11:58
sean-k-mooneyno worries. 11:58
sean-k-mooneyi will try an take a look at that next week. its not partically hard but my live migration env was on the system that not powered up currently11:59
sean-k-mooneywe can also look at the ci logs im just not sure if they will show that info12:00
sean-k-mooneywe do capture the ovs logs and i think the ovn logs in the ci so maybe12:00
ralonsohsean-k-mooney, we capture the OVN DB logs and events12:00
ralonsohbut not the OF rules12:01
ralonsohwhat are you looking for?12:01
ralonsohsean-k-mooney, in any case, there is an ongoing core OVN feature (there is a FDP bug) to track the OF rule installation, related to a port binding12:03
ralonsohthat would be the next step to ensure the OF rules are effectively present in the backend12:03
ralonsohand Neutron would read this in order to send the vif-plugged event12:03
sean-k-mooneyack12:05
sean-k-mooneyralonsoh: i just want to reve the logs to see if this si actully fixign the problem or at least makign it better then it was before.12:05
sean-k-mooneylogically it should12:05
sean-k-mooneybut we have tought we fixed this a few times inthe past so just makeign sure we have not missed somethign obvious in hindsight12:06
sean-k-mooneyin the ovs logs we should see the addtion of the tap and the assignem fo the of port id i belive12:06
sean-k-mooneyill take a look and let you know what i fined12:06
ralonsohyes, that's for sure12:06
ralonsohand we have them in the U/S CI12:06
sean-k-mooneyi belive ovs logs a warnign if the netdev does not exist when you create the ovs port so with this chagne we should nolonger see that durign a migration12:08
opendevreviewEduardo Olivares proposed openstack/neutron master: WIP: new job tempest-multinode-with-bgp  https://review.opendev.org/c/openstack/neutron/+/97360812:39
opendevreviewEduardo Olivares proposed openstack/neutron master: WIP: new job tempest-multinode-with-bgp  https://review.opendev.org/c/openstack/neutron/+/96218812:40
opendevreviewEduardo Olivares proposed openstack/neutron master: WIP: new job tempest-multinode-with-bgp  https://review.opendev.org/c/openstack/neutron/+/96218812:44
opendevreviewLajos Katona proposed openstack/neutron master: WIP: [eventlet]: Make ovs-agent stop again  https://review.opendev.org/c/openstack/neutron/+/96710512:46
opendevreviewEduardo Olivares proposed openstack/neutron master: WIP: new job tempest-multinode-with-bgp  https://review.opendev.org/c/openstack/neutron/+/96218812:47
opendevreviewMerged openstack/os-vif master: Stabilize functional test  https://review.opendev.org/c/openstack/os-vif/+/97345513:15
opendevreviewBodo Petermann proposed openstack/os-vif master: Fixed bridge name when per_port_bridge is used  https://review.opendev.org/c/openstack/os-vif/+/96641013:17
haleybi'll start meeting in one second...14:00
haleyb#startmeeting neutron_drivers14:01
opendevmeetMeeting started Fri Jan 16 14:01:13 2026 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 'neutron_drivers'14:01
haleybPing list: ykarel, mlavalle, mtomaska, slaweq, tobias-urdin, lajoskatona, haleyb, ralonsoh14:01
ralonsohhello14:01
mtomaskao/14:01
haleybhi everyone, happy Friday14:01
slaweqo/14:01
haleybi saw only one item on the agenda from ralonsoh 14:02
ralonsohyes, one sec14:02
ralonsohI found that while reviewing https://review.opendev.org/c/openstack/devstack/+/97296314:03
ralonsohwe have several issues in devstack14:03
ralonsoh1) we have several prefixes neutron- and q-14:03
ralonsohwe should choose one and keep it14:04
ralonsohIMO, because all the CI job definitions are using q-, we should choose q-14:04
ralonsoh2) the Neutron API and the dinamically loaded processes14:04
ralonsohthis is related to the fix Sean proposed14:05
ralonsohwe usually declare q-svc in the CI jobs (or the devstack confs)14:05
ralonsohbut now we deploy several processes: ovn-maintenance, periodic, rpc14:05
ralonsohIMO, we should move neutron-api (WSGI server) to q-api (q-svc was the eventlet server)14:06
haleybi was going to say neutron- since we're not quantum any more, it's a little confusing, but that's my opinion14:06
ralonsohand do the same for all services too that are loaded dimanically14:06
lajoskatonao/14:07
ralonsohhaleyb, yes, that was my initial opinion but we have a ton of defined CI jobs right now14:07
mtomaskathat is where that 'q' comes from :) ... now I know14:07
ralonsohmoving all of them to neutron- would be a pain14:07
ralonsoheven more difficult for the grenade jobsd14:07
ralonsoh(that include the migration of the services)14:08
slaweqq- was always used in "old" devstack neutron module14:08
slaweqwhich at some point was named "neutron-legacy"14:08
slaweqand "neutron-" was going to be used in new one14:08
ralonsohyou reverted that patch14:08
ralonsohnow we have a mix of them (actually only neutron API related services are using neutron-)14:09
slaweqbut few cycles back we decided to get back to "neutron-legacy" fully and make it "non-legacy" anymore14:09
lajoskatonaI was confused for weeks when that was made about what is legacy and what is not :-)14:09
slaweqbut I then kept both prefixes to be valid14:09
haleybralonsoh: i guess i'm thinking of the log file names, which can be neutron- even if setting is q-/Q_14:09
slaweqso now we have only one "lib/neutron" in devstack again14:09
slaweqbut it works with both prefixes (at least it should)14:09
ralonsoh^ yes14:09
slaweqIMHO even if 'neutron-' sounds better, 'q-' is still fine and we can stick with it I think14:10
ralonsohas commented, all services use q- (agents: ovn agent, dhcp, l3, ovs, sriov)14:10
ralonsohand only API use neutron-14:10
slaweqmaybe we could do something kind of logic in devstack that if user used service named "neutron-<something'' internally we would replace that "neutron-" to "q-" and use that shorter prefix everywhere in devstack logic14:11
ralonsohno one is declaring neutron-xxx14:11
slaweqralonsoh for many services you can use both prefixes and both should works the same14:11
ralonsohonly q-14:11
ralonsohwe already do this: we accept both prefixes14:12
slaweqat least all those defined in the neutron devstack plugin which aren't really services but enables some features in neutron14:12
ralonsohand actually we discard q-svc (that is used everywhere) to spawn the neutron-api, neutron-ovn-maintenance, neutron-periodic, etc14:12
opendevreviewElvira García Ruiz proposed openstack/neutron-tempest-plugin master: Add both direction tap-as-a-service scenario test  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/97362614:14
ralonsohso this is why I propose to move (without breaking anything) to q- only14:14
ralonsohI would like also the CI jobs to define explicitly all the API services, but I think that would fine for now just to let devstack to configure them14:15
opendevreviewElvira García Ruiz proposed openstack/neutron-tempest-plugin master: Add both direction tap-as-a-service scenario test  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/97362614:15
ralonsoh(rpc depends on the workers configure, ovn-maintenance depends on running on ml2/ovn)14:15
lajoskatonaI like any way that makes the names in sync even neutron-* or q-*, so +1 from me14:15
slaweqI agree with lajoskatona any way which will make it finally consistent across devstack and ci jobs is fine for me14:16
slaweqand if q- is easier to do due to the ci jobs - lets go with q- then :)14:17
ralonsohok, I'll start proposing patches to move to one single prefix only, to avoid this dichotomy 14:17
lajoskatonathanks ralonsoh14:17
mlavallefine with me14:17
ralonsohthat's all I had, thank you all14:18
haleybRIP neutron- it was good knowing you :(14:18
mlavallelol14:18
mtomaska:)14:19
haleybwere there any other topics?14:19
mtomaskaJust to close my last week topic 14:20
mtomaskahttps://bugs.launchpad.net/neutron/+bug/2135228/comments/514:20
opendevreviewMerged openstack/os-ken master: Fix Timeout context  https://review.opendev.org/c/openstack/os-ken/+/97339814:20
mtomaskaI deferred local port mirror for the purpose of ddebugging. Ovs-tcpdump is efficient for that14:20
mtomaskawe might resume that RFE if we decide to have local DPI functionality14:21
lajoskatonaso no need for local port in tap-as-a-service?14:21
mtomaskanot a the moment, and not for the debug purposes. But as I mentioned in my comment, I might resume that RFE in the future if we decide that we need local port mirror for local DPI services14:22
lajoskatonamtomaska: thanks for checking14:22
mtomaskabut at the moment there is no ask from the end customers for that functionality14:22
haleybok, thanks for the update mtomaska 14:26
haleybany other topics?14:26
haleybalright, thanks for attending everyone and have a nice weekend!14:27
haleyb#endmeeting14:27
opendevmeetMeeting ended Fri Jan 16 14:27:15 2026 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:27
opendevmeetMinutes:        https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-01-16-14.01.html14:27
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-01-16-14.01.txt14:27
opendevmeetLog:            https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-01-16-14.01.log.html14:27
ralonsohbye14:27
mtomaskabye14:27
slaweqo/14:27
mlavalle\o14:27
lajoskatonao/14:28
opendevreviewBrian Haley proposed openstack/neutron stable/2025.2: Make sure OVN PG is present before adding a SG rule  https://review.opendev.org/c/openstack/neutron/+/97363014:29
opendevreviewBrian Haley proposed openstack/neutron stable/2025.1: Make sure OVN PG is present before adding a SG rule  https://review.opendev.org/c/openstack/neutron/+/97363114:29
opendevreviewBrian Haley proposed openstack/neutron stable/2024.2: Make sure OVN PG is present before adding a SG rule  https://review.opendev.org/c/openstack/neutron/+/97363214:30
opendevreviewBrian Haley proposed openstack/neutron unmaintained/2024.1: Make sure OVN PG is present before adding a SG rule  https://review.opendev.org/c/openstack/neutron/+/97363314:30
elviraHi! o/ I saw Software Factory is failing in all neutron-tempest-plugin proposed patches because of a manila-tempest-plugin python version mismatch. Does anyone know if this has already been filed?15:11
elviraExample from https://logserver.rdoproject.org/ea8/rdoproject.org/ea8b04f14c144f34bad0cc06e1b60416/ci-framework-data/logs/0200a04d-19a5-4871-897b-a37ba5e0ce03/base/os/tempest/tempest-extras/tempest-extras-build.log > ERROR: Package 'manila-tempest-plugin' requires a different Python: 3.9.25 not in '>=3.10'15:11
haleybelvira: looks like it's been failing since end of november, at least https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/966450 shows the -115:20
haleyband i'm guessing the fix is in the manila plugin? although this merged https://review.opendev.org/c/openstack/manila-tempest-plugin/+/96613015:21
haleyboh, although maybe it is in n-t-p setup.cfg15:22
opendevreviewBrian Haley proposed openstack/neutron-tempest-plugin master: Update python version in setup.cfg  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/97364015:25
haleybelvira: ^^ might fix it15:25
elviranice!! I will check, thanks haleyb!15:27
haleybralonsoh: https://review.opendev.org/c/openstack/neutron/+/972734 is ready to go, zuul change merged15:28
haleybelvira: we missed a number of py313 related things this cycle, too many to keep track of15:29
ralonsohhaleyb, let me check15:29
ralonsohhaleyb, I still need to open the LP bug to document what to do in a python upgrade15:30
haleybralonsoh: ack, i've been side-tracked by other things to update the doc this week15:30
ralonsohhaleyb, please check https://review.opendev.org/c/openstack/tap-as-a-service/+/97320315:33
ralonsohthat was also depending on the zuul-jobs patch15:33
opendevreviewRodolfo Alonso proposed openstack/neutron master: Bump os-ken to 4.1.0  https://review.opendev.org/c/openstack/neutron/+/97254015:34
opendevreviewRodolfo Alonso proposed openstack/neutron master: Fix ``LogicalRouterPortEvent`` when a LR is deleted  https://review.opendev.org/c/openstack/neutron/+/97358415:38
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] Check if the LSP is present when setting the port UP  https://review.opendev.org/c/openstack/neutron/+/97359915:38
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] Check LRP presence in ``check_redirect_type_router_gateway_ports``  https://review.opendev.org/c/openstack/neutron/+/97360215:38
haleybralonsoh: done, and i have https://review.opendev.org/c/openstack/neutron/+/971628 for neutron-lib requirements bump, think slaweq wanted that bump as well15:43
ralonsohlet me check15:45
elvirahaleyb: I don't fully understand how https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/973640  would fix the issue. The problem is in the base image being used, right? As long as that job is based in Centos 9 we will use python3.9 as default (maybe I'm understanding it wrong)15:56
haleybelvira: oh, i didn't know if the fact that manila had a lower bound of 3.10 and neutron was only 3.9 was the issue?15:57
haleybi don't see the software factory there either15:57
haleybmaybe because it didn't change any actual code15:58
haleybwould need a test patch perhaps15:58
opendevreviewyatin proposed openstack/neutron master: [OVN] Wait for Port_Binding additional chassis in live-migration  https://review.opendev.org/c/openstack/neutron/+/95691015:59
haleybelvira: let me rebase another patch on-top and see what software factory thinks16:01
opendevreviewBrian Haley proposed openstack/neutron-tempest-plugin master: Pass tenant_id argument to create_router_by_client  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/97344416:02
haleybelvira: ^^ will see what happens16:03
averdaguerHello, I just connected now and I missed a lot of history regarding openstack-meta-content-provider, but a few things16:04
elvirayup, thanks16:04
averdaguerThis error started on end of December due to tempest-manilla adding new commit to drop support on python3.9. The problem is that on all jobs (that I'm aware of) that builds container (openstack-meta-content-provider/tcib jobs...)16:05
opendevreviewyatin proposed openstack/neutron master: [DNM] Check migration ovn with fixes  https://review.opendev.org/c/openstack/neutron/+/97282016:05
averdaguerThey are running on centos9, and IIUC during the pre-run job, python3 is installed (since we're using centos9 the default is python3.9)16:06
ykarelaverdaguer, elvira https://github.com/openstack-k8s-operators/tcib/pull/356 should clear that issue with softwarefactory job16:08
ykarelbut that will take time to reach16:08
ykarelso we can skip building tempest-extras in those jobs16:08
averdaguer^ I think as a workarround would be good16:08
elviraykarel: if I understand correctly we will need to make that removal for neutron-tempest-plugin too if we merge https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/973640, right?16:14
ykarelpushed https://github.com/openstack-k8s-operators/ci-framework/pull/360716:19
ykarelelvira, with neutron-tempest there could be other issues16:20
ykarelalso i think we can't drop py3.9 there yet16:20
ykarelas that is branchless16:20
ykarelbut good to check first generic tempest guidelines for all plugins16:20
ykarelhaleyb, ^ commented there16:21
elvirathanks ykarel, checking the patch16:23
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Don't delete from OVN DB ACLs not managed by Neutron  https://review.opendev.org/c/openstack/neutron/+/97364816:28
opendevreviewJakub Libosvar proposed openstack/neutron master: bgp: Improve BGP IDL lock  https://review.opendev.org/c/openstack/neutron/+/97254717:24
opendevreviewMerged openstack/neutron master: Update jobs to use the periodic zuul job templates  https://review.opendev.org/c/openstack/neutron/+/97273417:26
opendevreviewMerged openstack/tap-as-a-service master: Migrate upper functional job to Python 3.13  https://review.opendev.org/c/openstack/tap-as-a-service/+/97320317:32
opendevreviewMerged openstack/tap-as-a-service master: Remove `neutron-tempest-plugin-tap-as-a-service-wsgi` definition  https://review.opendev.org/c/openstack/tap-as-a-service/+/97320517:32
-opendevstatus- NOTICE: Gerrit on review.opendev.org will be offline briefly in order to restart on a newer JVM and to clear out caches18:34
opendevreviewJakub Libosvar proposed openstack/neutron master: Test FT LP bug 2137467  https://review.opendev.org/c/openstack/neutron/+/97243519:04
opendevreviewMerged openstack/neutron master: bgp: OVN agent BGP extension  https://review.opendev.org/c/openstack/neutron/+/96089521:37
*** haleyb is now known as haleyb|out22:58
opendevreviewMerged openstack/neutron-lib master: Use py313 for all neutron-lib jobs  https://review.opendev.org/c/openstack/neutron-lib/+/97273523:42

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