-
Bug
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
None
-
0
-
False
-
-
False
-
?
-
rhos-ops-day1day2-upgrades
-
None
-
-
-
-
Critical
We are performing a large-scale OpenStack adoption from RHOSP 17.1 to RHOSO 18.0 in an environment with 250+ nodes.
During data plane adoption, the hostname on compute nodes changes, which is also updated in OVS configuration, resulting in an inconsistency between "requested-chassis" for the existing ports in OVNSB and the new hostname for the same compute.
Observed behavior on a compute:
- OVN Southbound database re-registers the chassis with a new hostname as "computer660-50.ctlplane.redhat.local"
- Neutron logical ports continue to reference requested-chassis=computer660-50.redhat.local
- Due to this mismatch, the OVN controller on the compute node logs “Not claiming lport” messages and refuses to bind the affected ports.
As a result, logical ports are not claimed by the compute chassis and the affected VMs experience loss of network connectivity during adoption.
// hostname is changed to ctlplane.redhat.local [root@computer660-50 tripleo-admin]# sudo ovs-vsctl get open_vswitch . external_ids | head -1 {garp-max-timeout-sec="0", hostname=computer660-50.ctlplane.redhat.local, ovn-bridge=br-int, //chassis re-registered with new hostname in ovn southbound [root@e18-h18-000-r660 adoption-nodesets]# oc exec -n openstack ovsdbserver-sb-0 -c ovsdbserver-sb -- ovn-sbctl --no-leader-only show 2>&1 | grep -A10 "660-50" hostname: computer660-50.ctlplane.redhat.local Encap geneve ip: "172.18.2.200" options: {csum="true"} // requested chassis mismatch pointing to old hostname [root@e18-h18-000-r660 adoption-nodesets]# oc exec -n openstack ovsdbserver-sb-0 -c ovsdbserver-sb -- ovn-sbctl --no-leader-only list port_binding 2>&1 | grep -B5 "computer660-50.redhat.local" | head -30 ha_chassis_group : [] logical_port : "956506f7-65f9-4549-a0b5-6dd5a89eda0e" mac : ["fa:16:3e:18:ce:db 192.101.2.15"] mirror_rules : [] nat_addresses : [] options : {requested-chassis=computer660-50.redhat.local} // compute not claiming ports from ovn-controller logs 2026-01-11T20:53:56Z|00310|binding|INFO|Not claiming lport 956506f7-65f9-4549-a0b5-6dd5a89eda0e, chassis 62de21f0-81b5-407c-b262-22dda4b55df2 requested-chassis computer660-50.redhat.local pb->chassis 62de21f0-81b5-407c-b262-22dda4b55df2 2026-01-11T20:54:23Z|00697|binding|INFO|Not claiming lport 956506f7-65f9-4549-a0b5-6dd5a89eda0e, chassis 62de21f0-81b5-407c-b262-22dda4b55df2 requested-chassis computer660-50.redhat.local pb->chassis 2026-01-11T20:56:22Z|01553|binding|INFO|Not claiming lport 956506f7-65f9-4549-a0b5-6dd5a89eda0e, chassis 62de21f0-81b5-407c-b262-22dda4b55df2 requested-chassis computer660-50.redhat.local pb->chassis 2026-01-11T20:56:37Z|01777|binding|INFO|Not claiming lport 956506f7-65f9-4549-a0b5-6dd5a89eda0e, chassis 62de21f0-81b5-407c-b262-22dda4b55df2 requested-chassis computer660-50.redhat.local pb->chassis 2026-01-11T20:56:50Z|01831|binding|INFO|Not claiming lport 956506f7-65f9-4549-a0b5-6dd5a89eda0e,
After manually aligning the OVN chassis hostname with the requested-chassis value and restarting the OVN controller, the compute node immediately begins claiming ports and network connectivity is restored.
Workaround:
RHOSO by default uses "Ctlplane" network DnsDomain for Canonical hostname. The users should use old CloudDomain that matches tripleo given hostname for the "Ctlplane" network DnsDomain in Netconfig for adoptions. This way it doesn't change compute hostname during adoptions.
"edpm_pre_adoption_validation" services checks this hostname mismatch, But it allows to bypass this check via https://github.com/openstack-k8s-operators/edpm-ansible/blob/a5cf980b1d54f9dfb94673b65352a338364bec6e/roles/edpm_pre_adoption_validation/defaults/main.yml#L22. For the environments that are being adopted, allowing this hostname mismatch brings down the network connectivity for the workloads.
