-
Bug
-
Resolution: Done-Errata
-
Critical
-
rhos-17.1.4
-
2
-
False
-
-
False
-
No Docs Impact
-
osp-director-operator-container-1.3.1-20
-
None
-
-
-
Approved
-
Important
To align with non-OSPdO deployments, controller VMs under OCP should be configurable to auto start.
From Juniper:
As we stated in this case we found that the Openstack controller VMs running on OCP virtualization are not started after an OCP node failure/restart. This is a problem for our customer and a clear deviation from the RHOSP16.2 deployment where the Openstack controller VMs ran on RHV hypervisors and had autostart enabled.
Now, we had hoped that fencing/stonith would help with the issue in 17.1 and after testing we saw that it partly helped to start powered off instances but unfortunately stontih is not fit for purpose similar to our RHOSP16.2 installations where we got a support exception (refer to this case which explains why stonith makes things worse in failure scenarios). In essence, with stonith enabled, the cluster does not properly fail over resources like VIPs and the cluster becomes non functional with a single outage/server down which is not acceptable for our customer.
- links to
-
RHSA-2025:146286 Red Hat OpenStack Platform 17.1 (osp-director-operator) security update
- mentioned on