Feature Overview (aka. Goal Summary)

The transition from runc to crun is part of OpenShift’s broader strategy for improved performance and security. In OpenShift clusters with hosted control planes, retaining the original runtime during upgrades was considered complex and unnecessary, given the success of crun in tests and the lack of proof for significant risk. This decision aligns with OpenShift’s default container runtime upgrade and simplifies long-term support.

Requirements (aka. Acceptance Criteria)

1. Transparent Runtime Change: The switch to crun should be seamless, with minimal disruption to the user experience. Any workload impacts should be minimal and well-communicated.
2. Documentation: Clear documentation should be provided, explaining the automatic runtime switch, outlining potential performance impacts, and offering guidance on testing workloads after the transition.

Deployment Considerations

Use Cases

Scenario 1:
A user upgrading from OpenShift 4.17 to 4.18 in a HyperShift environment has NodePools running runc. After the upgrade, the NodePools automatically switch to crun without user intervention, providing consistency across all clusters.

Scenario 2:
A user concerned about performance with crun in 4.18 can create a new NodePool to test workloads with crun while keeping existing NodePools running runc. This allows for gradual migration, but default behavior aligns with the crun upgrade. 

Scenario 2 needs to be well documented as best practice. 

Questions to Answer

• How will this automatic transition to crun affect workloads that rely on specific performance characteristics of runc?
• Are there edge cases where switching to crun might cause compatibility issues with older OpenShift configurations or third-party tools?

Out of Scope

• Supporting retention of runc as the default runtime post-upgrade is not part of this feature.
• Direct runtime configuration options for individual NodePools are not within scope, as the goal is to align with OpenShift defaults and reduce complexity.

Documentation Considerations

Based on this conversation, we should make sure we document the following:

• Canary Update Strategy:
• Highlight the benefits of HyperShift and HCP as architecture that allows the decoupling of NodePools and controlplanes upgrades better enabling the canary upgrade pattern
• Reuse or create new docs around canary upgrades with HCP NodePools. 
• Gradually upgrading a small subset of nodes / Nodepools ("canaries") first to test the new runtime in a production environment before rolling out the upgrade to the rest of the nodes.

• Release Notes:
• Clearly announce the switch from runc to crun as the default runtime in version 4.18 and explain HCP’s behaviour. 
• Briefly explain the rationale behind the change, emphasizing the expected transparency and minimal user impact.
• Reference the documentation on the canary update strategy for users seeking further information or guidance.