-
Bug
-
Resolution: Done
-
Major
-
None
-
4.13, 4.12, 4.14
-
Important
-
No
-
Rejected
-
False
-
This is a clone of issue OCPBUGS-10433. The following is the description of the original issue:
—
Description of problem:
When CNO is managed by Hypershift multus-admission-controller does not have correct RollingUpdate parameterts meeting Hypershift requirements outligned here: https://github.com/openshift/hypershift/blob/646bcef53e4ecb9ec01a05408bb2da8ffd832a14/support/config/deployment.go#L81 ``` There are two standard cases currently with hypershift: HA mode where there are 3 replicas spread across zones and then non ha with one replica. When only 3 zones are available you need to be able to set maxUnavailable in order to progress the rollout. However, you do not want to set that in the single replica case because it will result in downtime. ``` So when multus-admission-controller has more than one replica the RollingUpdate parameters should be ``` strategy: type: RollingUpdate rollingUpdate: maxSurge: 0 maxUnavailable: 1 ```
Version-Release number of selected component (if applicable):
How reproducible:
Always
Steps to Reproduce:
1.Create OCP cluster using Hypershift 2.Check rolling update parameters of multus-admission-controller
Actual results:
the operator has default parameters: {"rollingUpdate":{"maxSurge":"25%","maxUnavailable":"25%"},"type":"RollingUpdate"}
Expected results:
{"rollingUpdate":{"maxSurge":0,"maxUnavailable":1},"type":"RollingUpdate"}
Additional info:
- blocks
-
OCPBUGS-11547 multus-admission-controller does not have correct RollingUpdate parameterts when running under Hypershift
- Closed
- clones
-
OCPBUGS-10433 multus-admission-controller does not have correct RollingUpdate parameterts when running under Hypershift
- Closed
- is blocked by
-
OCPBUGS-10433 multus-admission-controller does not have correct RollingUpdate parameterts when running under Hypershift
- Closed
- links to