Goal

• Nodepools can hold off on performing a rollout of their nodes until said roll-out is triggered

Why is this important?

• Allows Managed Service to implement their policies or Node rollouts regardless if that is:
• Node maintenance windows
• Explicit user confirmation

Scenarios

• HyperShift upgrade fixes/adds reconciliation of some NodePool spec fields that result in ignition changes. Said upgrade should respect the Nodepool contract of not triggering node replacement/reboot without user/service intervention
• An important fix for the Nodes (potentially a CVE) comes up and the user wants to trigger a rollout at any given point in time to receive the benefits of the fix.

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
• SD QE - covered in SD promotion testing
• Release Technical Enablement - Must have TE slides

Open questions:

1. What is the right UX to trigger the roll-out in these cases? Should Cluster service just scale down and up or can we offer a more powerful/convenient UX to the service operators.

Done Checklist

• CI - CI is running, tests are automated and merged.
• * Documentation and SRE enablement
• 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>