Uploaded image for project: 'OpenShift Node'
  1. OpenShift Node
  2. OCPNODE-2262

Remove cgroupsv1 from OpenShift

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • Remove cgroupsv1 from OpenShift
    • BU Product Work
    • False
    • None
    • False
    • Not Selected
    • To Do
    • OCPSTRAT-1341 - Remove Cgroup v1 from OCP in 4.19
    • OCPSTRAT-1341Remove Cgroup v1 from OCP in 4.19
    • 100% To Do, 0% In Progress, 0% Done

      OCP/Telco Definition of Done
      Epic Template descriptions and documentation.

      <--- Cut-n-Paste the entire contents of this description into your new Epic --->

      Epic Goal

      • Cgroupsv1 removal
        • After 4.16 announcement of deprecation: Coincides with RHEL announcement w/9.4
        • Need documentation
        • Maybe a blog
        • Code change warning v1 usage?
          • Node config object?
        • Telemetry for checking how many nodes are v1/v2.
        • E2e for starting a cluster in v1 and upgrading to v2.
        • Block clusters configured with v1 upgrade to 4.19 and later releases.

      Why is this important?

      • Advantages of cgroupsv2:
        • Our central goal with cgroups v2 is to provide our customers with a unified and simplified system management experience that is both versatile and extensible. 
        • Its single-hierarchy design provides seamless interaction, reducing complexity and bolstering efficiency. The more accurate and straightforward resource distribution allows you to have real-time control over your system’s resources.
        • You are equipped with strong guards against system failures and are always informed of the resource starved tasks. Notably, it opens the door for features like user space OOM killer and Pressure Stall Information (PSI) to make them available in OpenShift in the future.
      • RHEL 10 does not support cgroupsv1. 
        • From the past multiple releases there has been minimal fixes and enhancements to v1 in favor of v2 adoption.

      Scenarios

      1. ...

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      Open questions::

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • 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>

              Unassigned Unassigned
              nagrawal@redhat.com Neelesh Agrawal
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: