-
Bug
-
Resolution: Unresolved
-
Normal
-
None
-
4.17.0
-
None
-
None
-
3
-
PODAUTO - Sprint 258, PODAUTO - Sprint 259
-
2
-
False
-
Description of problem:
Seems like we can't use oc edit or apply to and edit an existing CR, because the existing deployment will not react to the change. Probably a problem with the reconciler.
Version-Release number of selected component (if applicable):
4.17.0
How reproducible:
Only after all reconcilliation and the operator is in a stable state, will CR in-place changes not work. If the operator is in an unstable state (e.g., not all pods have rolled out), then CR changes will seem to work (but really its just reconciling over and over again since the operator is trying to move into a READY state).
Steps to Reproduce:
1. Installed 4.17 CRO-operator 2. Create a CRO CR like this: apiVersion: operator.autoscaling.openshift.io/v1 kind: ClusterResourceOverride metadata: name: cluster spec: podResourceOverride: spec: memoryRequestToLimitPercent: 50 cpuRequestToLimitPercent: 25 limitCPUToMemoryPercent: 200 deploymentOverrides: replicas: 1 nodeSelector: node-role.kubernetes.io/worker: "" tolerations: - key: "key" operator: "Equal" value: "value" effect: "NoSchedule" 3. Edit it with oc edit and change replicas to 2 (alternatively use oc apply with an existing yaml definition of 2 replicas) 4. oc get deployment clusterresourceoverride -n clusterresourceoverride 5. Notice replicas do not change.
Actual results:
Replicas do not change and stays at 1 pod.
Expected results:
Replicas should scale to 2 pods.
Additional info:
- blocks
-
OCPBUGS-38539 clusterresourceoverride deployment does not reconcile if the CR is edited inplace
- Closed
- is cloned by
-
OCPBUGS-38539 clusterresourceoverride deployment does not reconcile if the CR is edited inplace
- Closed
- links to
-
RHEA-2024:6122 OpenShift Container Platform 4.18.z bug fix update