Last Modified: Oct 19, 2026
Affected Product(s):
F5OS F5OS-C
Known Affected Versions:
F5OS-C 1.8.0, F5OS-C 1.8.1, F5OS-C 1.8.2, F5OS-C 1.8.2-HR1, F5OS-C 1.8.2-HR2, F5OS-C 1.8.2-HR3
Opened: May 01, 2026 Severity: 3-Major
The two controller-manager pods are observed to be disrupted and not in a 1/1 Ready state after assigning blades to the 'none' partition. For example, in the output of 'oc get pods --all-namespaces', the pods are observed to be in 'CrashLoopBackOff' state, similar to the following example: [root@controller-2(VEL410):Active ~]# oc get pods --all-namespaces -o wide | grep controller-manager kube-service-catalog controller-manager-kb7th 0/1 CrashLoopBackOff 1 27s 100.76.0.29 controller-1.chassis.local kube-service-catalog controller-manager-4zp6r 0/1 CrashLoopBackOff 1 37s 100.77.0.30 controller-2.chassis.local The controller-manager pods may also be observed in the 'Error' or 'Running' state with the status as 0/1 Ready containers. The output of the 'oc logs -n kube-service-catalog <pod name>' command displays an error similar to the following: controller_manager.go:237] error running controllers: failed to get api versions from server: failed to get supported resources from server: unable to retrieve the complete list of server APIs: subresources.kubevirt.io/v1alpha3: the server is currently unable to handle the request
- Controller-manager pods crash repeatedly and fail to turn the status to 1/1 Ready. - Orchestration Manager removes the pods that are not ready or are newly scheduled pods that have not turned ready yet. - New blades cannot be added to the OpenShift cluster while the controller-manager pods are unhealthy.
Slots that were previously assigned to an enabled VELOS partition are re-assigned to the 'none' partition.
Assign the slots to an enabled partition. The CLI prompt may display a "Cluster update in-progress" message for a brief period while playbooks run to add blades into the cluster.
None