Goal

• Stay aligned with OCP Standalone with the runtime when relevant events happen.
  • Is there any implication in ControlPlane upgrades.
    • Being HostedControlPlane a MGMT Cluster workload, it will be affected as any other workload, we need to verify if that affects us in any way.
  • NodePool Updates from 4.18
  • NodePool updates from 4.17 to 4.18 (Changing runtime release)
• Testing
• Implications to maintain a NodePool with the non-default runtime
  • Deprecation of the runc at some point, forcing the customers to create a new NodePool with the new runtime
  • Perfomance implications
  • Footprint
  • Testing (duplicated tests?)
  • MultiArch config
  • Backup and Restore
• Documentation
  • How to change the runtime
  • Implications of changing and use
• Service Delivery affectation
  • Eventually this change will happen too in SD, we need to stay aligned too with them. (ADR https://docs.google.com/document/d/1I-sxbXqdZUZyJ6ZyQoZIQnktaSVlZ13ONkogTQIBxqo/edit)

Why is this important?

• Prevent issues on runtime use and migration with customer workloads in SaaS and Self-Manage platforms
• Stay aligned with OCP Standalone

Scenarios

1. Scenario 1: A user upgrading from OpenShift 4.17 to 4.18 wants to ensure that their nodepools continue using runc. The upgrade proceeds without changes to the container runtime, preserving the existing environment.
2. Scenario 2: A user intends to switch to crun post-upgrade. They create a new nodepool explicitly configured with crun, ensuring a controlled transition.

Acceptance Criteria

• Dev
  • Validated upgrade from 4.17 to 4.18 does not modify the runtime
  • Validated upgrade from 4.18 does not modify the runtime
  • Validated from 4.18 the new nodepools are based on crun
  • Questions from above answered
  • Keep aligned with OCP Standalone
• CI
  • MUST be running successfully with tests automated
  • E2E test to validate the desired behaviour
  •  
• QE - covered in Polarion test plan and tests implemented
• Release Technical Enablement - Must have TE slides
• Doc
  • Documentation in place Upstream and the docs team aware of the new additions for downstream

Open questions:

1. How will the automatic retention of runc impact long-term support for crun as the default runtime?
   1. Deprecation of the runc at some point, forcing the customers to create a new NodePool with the new runtime
   2. Perfomance implications
   3. Footprint
   4. MultiArch config
   5. Backup and Restore
2. Are there edge cases where the automatic retention of runc could cause issues with newer OpenShift features or configurations?
3. Is there any implication in ControlPlane upgrades?
4. Will we cover the testing of both runtimes?

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>