Tuesday, 2026-10-06

opendevreviewKyuyeong Lee proposed openstack/neutron stable/2026.1: [OVN] Use poll(2) instead of select(2) for the OVSDB poller  https://review.opendev.org/c/openstack/neutron/+/100889100:51
opendevreviewKyuyeong Lee proposed openstack/neutron stable/2026.1: [OVN] Use poll(2) instead of select(2) for the OVSDB poller  https://review.opendev.org/c/openstack/neutron/+/100889100:58
opendevreviewMerged openstack/neutron master: [OVN] Retrieve only the SG stateful flag in the logapi driver  https://review.opendev.org/c/openstack/neutron/+/100841902:03
opendevreviewOpenStack Proposal Bot proposed openstack/neutron master: Imported Translations from Zanata  https://review.opendev.org/c/openstack/neutron/+/100890203:43
opendevreviewKyuyeong Lee proposed openstack/neutron stable/2026.2: [OVN] Retrieve only the SG stateful flag in the logapi driver  https://review.opendev.org/c/openstack/neutron/+/100891104:27
opendevreviewKyuyeong Lee proposed openstack/neutron stable/2026.1: [OVN] Retrieve only the SG stateful flag in the logapi driver  https://review.opendev.org/c/openstack/neutron/+/100891204:27
opendevreviewMerged openstack/neutron stable/2026.1: Use idl.has_lock instead of idl.is_lock_contended for OVSDB lock checks  https://review.opendev.org/c/openstack/neutron/+/100875905:44
ralonsohlajoskatona, hi! if you have 1 min, please check https://review.opendev.org/c/openstack/neutron-lib/+/100691607:21
ralonsohthanks!07:21
ralonsohand a backport, no conflicts: https://review.opendev.org/c/openstack/neutron/+/100875807:21
lajoskatonaralonsoh: slaweq was faster :-)07:28
slaweq:)07:29
opendevreviewEduardo Olivares proposed openstack/neutron master: [OVN] Allow router interface ICMP on stateful security groups  https://review.opendev.org/c/openstack/neutron/+/100848807:37
*** amorin_ is now known as amorin07:45
ralonsohlajoskatona, slaweq thanks folks!07:45
Mike--Question related to ovn load balancer health checks for backends. They run on the chassis/node that hosts the backend. If that chassis/host dies the backend stays up potentially forever if the host never comes back. Is this a known limitation?07:54
ralonsohfroyo, ^ can you check that?08:07
froyosure!08:07
froyoMike-- that is under the core ovn umbrella, ovn-octavia-provider doesn't implement the check itself, it is only receiving events from Service_Monitor table in OVN SB DB. But I agree on your conclusion, if the chassis where monitor es pinned dissapear looks there isn't any logic there to reassign it and last status of the backend will remain in the Service_monitor entry table.08:13
froyoI will check ovn doc trying to find if this is a known limitation or something is written there about this case, I will keep you update08:15
Mike--froyo: thanks! most of the other parts on a chassis will get moved if the 'vm' moves (masakari / nova evacuate / manual) but this caught our eye.08:32
Mike--this holds true for the backend as well once the vm moves. But the scenario the vm never moves there with be a % blackhole on the load balancer08:34
*** Guest1419 is now known as ravlew08:36
opendevreviewRodolfo Alonso proposed openstack/neutron master: ml2: replace tunnel segment physical_network NULL with ''  https://review.opendev.org/c/openstack/neutron/+/100784408:36
opendevreviewMerged openstack/neutron master: Drop ``sys_platform`` from requirements  https://review.opendev.org/c/openstack/neutron/+/99959509:01
froyoMike-- Exactly — makes sense, since evacuation/masakari rebinding the logical port is what indirectly "fixes" this for every other case (health monitor gets re-created on the new chassis once the port moves). The gap is narrowly the stuck-VM-never-moves scenario: no fencing/evacuation  trigger, or a backend that's never Nova-managed at all. In that case the LB has no way to know, and keeps routing a steady % o09:02
froyof traffic (proportional to the backend's weight) into a blackhole indefinitely — it's a silent partial-outage, not a hard failure anyone gets paged for. I just confirmed it's a known class of issue: OVN upstream is currently fixing the exact same pattern for BFD status (ovn-org/ovn PR #321/#325, issue #320 — "NB/SB status stays 'up' forever nothing is left to update"), but that work explicitly scopes out 09:02
froyothe hard-crashed-chassis case (left to an opt-in Neutron policy) and doesn't touch Service_Monitor/LB health checks at all.09:02
opendevreviewMerged openstack/neutron-lib master: bgp: Add ``is_filter`` to API definition  https://review.opendev.org/c/openstack/neutron-lib/+/100691609:12
opendevreviewMerged openstack/neutron stable/2026.2: ovn: fix gateway scheduling for multi-segment networks  https://review.opendev.org/c/openstack/neutron/+/100875809:16
Mike--froyo: I did not find those ovn references (yet), thanks! if I read your messages correctly it would still require neutron level work? Does that make sense from an architecture level?09:25
froyo  Mike-- Refs:09:26
froyo  - ovn-sb(5): https://man7.org/linux/man-pages/man5/ovn-sb.5.html09:26
froyo  - https://github.com/ovn-org/ovn/pull/32109:26
froyo  - https://github.com/ovn-org/ovn/pull/32509:26
Mike--read the github issue now, interesting read! Shared it with the team internally just now.09:31
froyoMike-- So architecturally, yes — it needs a Neutron-side "confirmed dead" signal, with OVN/northd as the consumer that translates that signal into DB state (clear chassis_name, force status down). That's exactly the shape of the BFD fix: Neutron confirms silence → removes the chassis from scoped HA groups → northd reacts. The catch for your scenario: that signal doesn't really e in the Concept C work, sinc09:32
froyoexist today, even for Neutron's own purposes. Checked a related bug (RH BZ #1946179) — Neutron has no automatic dead-chassis detection at all right now. A stale chassis just sits in the SB DB until an operator manually runs openstack network agent delete for that host.09:32
froyoSo IMO two things would need to happen: 09:34
froyo 1. Neutron would need an automated "chassis confirmed dead" signal (today it's a fully manual operator step).09:34
froyo  2. OVN/northd would need a Service_Monitor-side consumer of that signal — which doesn't exist yet even in the Concept C work, since that's currently scoped only to BFD-tied HA chassis groups (gateway ports), not generic VIF-bound ports where LB members live.09:34
Mike--Yes we foud the same state, although not that elaborately put. In our discussions, with our current knowledge of openstack services, we think the best course of action is to add a masakari flow to do said "openstack network agent delete" for the host masakari flags as down09:35
Mike--reading your #2 our masakari route would not solve it either or am I misreading09:36
Mike--?09:36
opendevreviewMerged openstack/ovsdbapp master: ovn-sb: Set default ``hostname`` in ``chassis_add``  https://review.opendev.org/c/openstack/ovsdbapp/+/100520709:54
opendevreviewRodolfo Alonso proposed openstack/neutron master: Fix netlink test privsep entrypoint unwrapping  https://review.opendev.org/c/openstack/neutron/+/100901009:56
ralonsohykarel, ^09:56
ralonsohI've executed `check experimental`09:57
froyoMike-- Correction to my earlier point #2 — dug further and found this isn't as unsolved as I said. OVN northd has had a mechanism since 2022 (commit 23e203a3, "northd: set svc_mon status to offline if port_binding released", shipped in OVN v22.09.0) that forces a backend's Service_Monitor.status to offline when its Port_Binding.up goes false. But that fix had a gap: if up stays true while chassis gets cleared, th09:57
froyoe stale online status was still trusted forever — which is basically our exact scenario.09:57
ykarelthx ralonsoh 09:57
froyoMike-- Port_Binding.chassis is a weak reference to Chassis in the schema — so deleting the Chassis row automatically clears it at the DB level. With this new northd fix in place, that triggers northd to mark the Service_Monitor offline and clear chassis_name, which is exactly the outcome you want.09:59
Mike--aah cool, then our perceived masakari route should work. That leaves the point if neutron wants to own some 'monitoring' or 'liveness' check for a chassis?10:00
froyoMike-- commit e180d57 ("northd: Mark unbound ports' service monitors offline"), merged into ovn-org/ovn main on 2026-09-2910:00
Mike--nice nice10:01
opendevreviewFiorella Yanac proposed openstack/neutron-tempest-plugin master: Add additional Json Tempest api tests for indirect floating IP  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/100901710:45
opendevreviewLajos Katona proposed openstack/neutron-vpnaas master: Rally scenario plugin API changed  https://review.opendev.org/c/openstack/neutron-vpnaas/+/100041710:54
opendevreviewLajos Katona proposed openstack/neutron-vpnaas master: Fix IPsec device driver status reporting races  https://review.opendev.org/c/openstack/neutron-vpnaas/+/100901910:54
opendevreviewMerged openstack/ovn-octavia-provider master: Migrate setup configuration to pyproject.toml  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/100394810:58
lajoskatonaslaweq, ralonsoh, mlavalle: do we have meeting today as haleyb is not around? For me it is fine to say that let's have everybody add topics to the etherpad and lets meet next week10:59
slaweqlajoskatona: personally I don't have any topics for today, we can probably wait week to discuss things during PTG next week11:00
opendevreviewElod Illes proposed openstack/networking-bagpipe stable/2026.1: DNM: gate health test  https://review.opendev.org/c/openstack/networking-bagpipe/+/100902411:02
lajoskatonaslaweq: thanks11:04
opendevreviewElod Illes proposed openstack/networking-bgpvpn stable/2026.1: DNM: gate health test  https://review.opendev.org/c/openstack/networking-bgpvpn/+/100902811:09
opendevreviewMerged openstack/ovn-octavia-provider master: Add --octavia-config-file to the neuron-ovn-db-sync plugin  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/99973611:15
ralonsohlajoskatona, slaweq good for me, we can skip todays meeting11:19
ralonsohI've been adding some topics to the PTG etherpad11:19
opendevreviewRodolfo Alonso proposed openstack/neutron-fwaas master: fwaas: skip L2 status when no local ports  https://review.opendev.org/c/openstack/neutron-fwaas/+/100259012:44
mlavalleslaweq, ralonsoh no meeting today, right?13:02
ralonsohno, we commented that before13:03
ralonsohif there is any hot topic, we can discuss it here13:03
ralonsohany other topic can be added to the PTG etherpad13:03
ralonsoh(let me find the link)13:03
ralonsoh#link https://etherpad.opendev.org/p/oct2026-ptg-neutron13:03
mlavalleralonsoh, thanks!13:03
mlavallehave a nice day13:03
slaweqhave a good one mlavalle :)13:04
ralonsohSo, for everybody, if you have something to discuss, you can raise any topic here in this channel. For PTG topics, use the ^^ provided link13:04
ichenPlease review EVPN Type-2 route spec https://review.opendev.org/c/openstack/neutron-specs/+/1004908 .  Thanks in advance.13:04
* haleyb hopes someone got his email about missing meeting13:14
opendevreviewMerged openstack/neutron stable/2025.2: qos: Handle missing port binding in resource request  https://review.opendev.org/c/openstack/neutron/+/100552013:17
opendevreviewFiorella Yanac proposed openstack/neutron-tempest-plugin master: Add additional Json Tempest api tests for indirect floating IP  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/100901713:28
*** elodille1 is now known as elodilles14:23
opendevreviewRodolfo Alonso proposed openstack/neutron master: ml2: replace tunnel segment physical_network NULL with ''  https://review.opendev.org/c/openstack/neutron/+/100784414:46
opendevreviewRodolfo Alonso proposed openstack/neutron master: ml2: derive segment IDs from ``networksegments``  https://review.opendev.org/c/openstack/neutron/+/100784914:46
opendevreviewLajos Katona proposed openstack/neutron-vpnaas master: Rally scenario plugin API changed  https://review.opendev.org/c/openstack/neutron-vpnaas/+/100041714:57
opendevreviewMerged openstack/neutron stable/2026.1: [OVN] Use poll(2) instead of select(2) for the OVSDB poller  https://review.opendev.org/c/openstack/neutron/+/100889115:23
opendevreviewMerged openstack/neutron stable/2026.2: [OVN] Retrieve only the SG stateful flag in the logapi driver  https://review.opendev.org/c/openstack/neutron/+/100891115:23
opendevreviewMerged openstack/neutron master: Imported Translations from Zanata  https://review.opendev.org/c/openstack/neutron/+/100890215:23
opendevreviewMerged openstack/neutron stable/2026.1: [OVN] Retrieve only the SG stateful flag in the logapi driver  https://review.opendev.org/c/openstack/neutron/+/100891215:23
opendevreviewMathieu GRZYBEK proposed openstack/neutron master: Restrict ``delete_port`` for the OVN metadata port  https://review.opendev.org/c/openstack/neutron/+/100876215:38
opendevreviewMarcin Wilk proposed openstack/neutron stable/2025.2: Use idl.has_lock instead of idl.is_lock_contended for OVSDB lock checks  https://review.opendev.org/c/openstack/neutron/+/100908016:05
opendevreviewMerged openstack/neutron master: ml2: Stop binding when a mechanism driver reports failure  https://review.opendev.org/c/openstack/neutron/+/98573216:06
opendevreviewLajos Katona proposed openstack/neutron-vpnaas master: Rally scenario plugin API changed  https://review.opendev.org/c/openstack/neutron-vpnaas/+/100041716:07
opendevreviewMaor Blaustein proposed x/whitebox-neutron-tempest-plugin master: Add EVPN-BGP FRR gateway HA failover test  https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/100909717:15
opendevreviewMaor Blaustein proposed x/whitebox-neutron-tempest-plugin master: Add EVPN-BGP FRR gateway HA failover test  https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/100909717:31
opendevreviewMerged openstack/neutron stable/2025.2: ovn: Add ip_substring_filtering API extension support  https://review.opendev.org/c/openstack/neutron/+/100666718:29
opendevreviewBrian Haley proposed openstack/neutron master: Add explicit return value to _bind_port_level()  https://review.opendev.org/c/openstack/neutron/+/100913023:50

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