Problem description
After a port is attached to a server via Nova's interface-attach API, the port controller may never observe the Neutron status transition from DOWN to ACTIVE. The same race affects volumes (available → in-use). This causes test assertions on status.resource.status to time out.
Observed
CI flake in server-update test step 1: assertion port2.status.resource.status == 'ACTIVE' timed out after 4 minutes.
Neutron API logs confirm the port went ACTIVE at 14:08:56, but ORC's last fetch was at 14:08:54 (saw DOWN). No subsequent fetch occurred until namespace deletion at 14:12:45.
Root cause
serverToPortMapFunc detects that a port attached to a server still has status DOWN and attempts to re-trigger reconciliation by:
- Patching the port's
Progressing condition to True via SSA
- Returning a reconcile request
However, the SSA patch uses field owner GetSSAFieldOwner(controllerName) (openstack.k-orc.cloud/portcontroller), while the generic reconciler's UpdateStatus uses GetSSAFieldOwnerWithTxn(controllerName, SSATransactionStatus) (openstack.k-orc.cloud/portcontroller/status). These are different SSA field owners, both with ForceOwnership.
This creates a race:
- Port controller reconciles port — fetches from Neutron (
DOWN), starts writing status
- Server controller writes Server status with port in interfaces →
serverToPortMapFunc fires
- MapFunc patches
Progressing=True (field owner: portcontroller)
- Port controller's
UpdateStatus writes Progressing=False (field owner: portcontroller/status), overwriting step 3
- MapFunc's enqueued reconcile request is processed —
shouldReconcile() sees Progressing=False → skips
The port is never re-fetched from Neutron. serverToVolumeMapFunc has the identical pattern.
Affected code
internal/controllers/port/controller.go — serverToPortMapFunc SSA patch
internal/controllers/volume/controller.go — serverToVolumeMapFunc SSA patch
ORC version
main
Additional information
No response
Relevant log output
Problem description
After a port is attached to a server via Nova's interface-attach API, the port controller may never observe the Neutron status transition from
DOWNtoACTIVE. The same race affects volumes (available→in-use). This causes test assertions onstatus.resource.statusto time out.Observed
CI flake in
server-updatetest step 1: assertionport2.status.resource.status == 'ACTIVE'timed out after 4 minutes.Neutron API logs confirm the port went
ACTIVEat 14:08:56, but ORC's last fetch was at 14:08:54 (sawDOWN). No subsequent fetch occurred until namespace deletion at 14:12:45.Root cause
serverToPortMapFuncdetects that a port attached to a server still has statusDOWNand attempts to re-trigger reconciliation by:Progressingcondition toTruevia SSAHowever, the SSA patch uses field owner
GetSSAFieldOwner(controllerName)(openstack.k-orc.cloud/portcontroller), while the generic reconciler'sUpdateStatususesGetSSAFieldOwnerWithTxn(controllerName, SSATransactionStatus)(openstack.k-orc.cloud/portcontroller/status). These are different SSA field owners, both withForceOwnership.This creates a race:
DOWN), starts writing statusserverToPortMapFuncfiresProgressing=True(field owner:portcontroller)UpdateStatuswritesProgressing=False(field owner:portcontroller/status), overwriting step 3shouldReconcile()seesProgressing=False→ skipsThe port is never re-fetched from Neutron.
serverToVolumeMapFunchas the identical pattern.Affected code
internal/controllers/port/controller.go—serverToPortMapFuncSSA patchinternal/controllers/volume/controller.go—serverToVolumeMapFuncSSA patchORC version
main
Additional information
No response
Relevant log output