-
Epic
-
Resolution: Done
-
Major
-
None
-
None
-
None
-
As a managed service provider of hosted clusters, I need to know behavior of cluster update configurations so that I can upgrade hosted clusters with validations
-
To Do
-
Product / Portfolio Work
-
False
-
-
False
-
Not Selected
-
None
-
None
-
None
-
0
Goal
- Will HyperShift also follow the same (age-based) order to pick nodes for NodePool config updates?
A: CAPI has the option to set one of 3 delete policies Random, Newest or Oldest.
https://github.com/kubernetes-sigs/cluster-api/blob/main/api/v1beta1/machinedeployment_types.go#L204C11-L209
However, Hypershift doesn't expose or set this value today and the default policy "Random" is used.
- What is the behavior of changing MaxUnavailable when an update is in progress? I.e customer picks incorrect MaxUnavailable (i.e. 1) and would like to increase.
A: CAPI should honor new value changes to MaxUnavailable/MaxSurge during a rolling upgrade. Need QA to validate if there are any edge cases which prevent that.
- When MaxUnavailable is 3 but 1 node is blocked and 2 nodes are draining for update. Will HyperShift ignore the 1 blocked node and move to the next node to honor MaxUnavailable?
A: if the blocked node status is not "Ready", it will be considered unhealthy and therefore will be counted as one of the 3 MaxUnavailable and won't be ignored.
- Is there a Metric to actually let admins know when the drain is blocked due to Platform workload vs. non-platform workload? If not, we will need it.
A: No metric.
Why is this important?
- …
Scenarios
- ...
Acceptance Criteria
- Dev - Has a valid enhancement if necessary
- CI - MUST be running successfully with tests automated
- QE - covered in Polarion test plan and tests implemented
- Release Technical Enablement - Must have TE slides
- ...
Dependencies (internal and external)
- ...
Previous Work (Optional):
- …
Open questions:
- …
Done Checklist
- CI - CI is running, tests are automated and merged.
- Release Technical Enablement <link to Feature Enablement Presentation>
- DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
- DEV - Enhancement merged: <link to meaningful PR or GitHub Issue>
- QE - Test plans in Polarion: <link or reference to Polarion>
- QE - Automated tests merged: <link or reference to automated tests>
- DOC - Downstream documentation merged: <link to meaningful PR>