I finally managed to reproduce a similar issue using stx and stx-openstack master builds.In my case the reapply is breaking because of missed overrides, something I could not find inside the attached logs though.
The critical point is: all the cg-openstack-*.yaml files inside /opt/platform/armada/22.06/stx-openstack/1.0-192-centos-stable-versioned seems to be disappearing on the first stx-os reapply after a controller node reboot, during the "generating application overrides" step. It happens because the first stx-os reapply after a controller node reboot is cleaning the armada-overrides.yaml content:
Definitely something to look into, this is probably the root cause of the lock/unlock test failures. I need to understand what's making those files to vanish and what recent change, to platform or application, introduced this problematic behavior.
I finally managed to reproduce a similar issue using stx and stx-openstack master builds.In my case the reapply is breaking because of missed overrides, something I could not find inside the attached logs though.
The critical point is: all the cg-openstack-*.yaml files inside /opt/platform/ armada/ 22.06/stx- openstack/ 1.0-192- centos- stable- versioned seems to be disappearing on the first stx-os reapply after a controller node reboot, during the "generating application overrides" step. It happens because the first stx-os reapply after a controller node reboot is cleaning the armada- overrides. yaml content:
$ cat /opt/platform/ helm/22. 06/stx- openstack/ 1.0-192- centos- stable- versioned/ armada- overrides. yaml
[]
Definitely something to look into, this is probably the root cause of the lock/unlock test failures. I need to understand what's making those files to vanish and what recent change, to platform or application, introduced this problematic behavior.