-
Bug
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
None
-
0
-
False
-
-
False
-
?
-
rhos-conplat-core-operators
-
None
-
-
-
-
Important
To Reproduce Steps to reproduce the behavior:
Customer is running resilience testing. One of their scenarios is a master node failure while the registry is unavailable. This situation blocks master node recovery/initialization.
Customer tried to figure out which RHOSO operators contribute to this situation and came up with the following list:
oc get pods --all-namespaces -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,IMAGE_PULL_POLICY:.spec.containers[*].imagePullPolicy | grep Always openshift-cluster-observability-operator observability-operator-7bb5f6f9b4-qvjbs Always openshift-marketplace cs-redhat-operator-index-v4-18-hnbz5 Always openstack ceilometer-0 Always,Always,Always,Always openstack kube-state-metrics-0 Always openstack openstack-data-plane-vaaa-provisionserver-openstackprovisivq6xv Always openstack openstack-data-plane-vdns-provisionserver-openstackprovisi59fk4 Always openstack openstack-data-plane-vdoor-provisionserver-openstackproviss7hrb Always openstack openstack-data-plane-ving-provisionserver-openstackprovisijmxv4 Always openstack openstack-data-plane-vpcrf-provisionserver-openstackproviscgd6f Always openstack openstack-data-plane-vradi-provisionserver-openstackprovis445wm Always
From operator's code it looks like we hard code ImagePullPolicy to Always in many scenarios, while allowing to change it in some situations.
Expected behavior
An option to set ImagePullPolicy to IfNotPresent (or another value) when operator needs this.
Bug impact
This may trigger cascade failures in air-gaped RHOSO deployments.
Known workaround
None
