Uploaded image for project: 'OCMUI - OpenShift Cluster Manager UI'
  1. OCMUI - OpenShift Cluster Manager UI
  2. OCMUI-492

UI - Support NTO configuration for ROSA on HyperShift

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Critical Critical
    • None
    • None
    • None
    • Support NTO configuration for ROSA on HyperShift
    • False
    • Hide

      None

      Show
      None
    • False
    • To Do
    • XCMSTRAT-336 - Parent for all M6 Epics that were moved to Post GA
    • XCMSTRAT-336Parent for all M6 Epics that were moved to Post GA
    • 100% To Do, 0% In Progress, 0% Done

      User Story

      As a ROSA cluster administrator with a cluster deployed on HyperShift, I want to add NTO "Tuned" configurations for my NodePools, so that I can control various aspects of the Machine behavior.

      Process

      Reference document: https://github.com/openshift/hypershift/blob/main/docs/content/how-to/automated-machine-management/node-tuning.md, also see https://hypershift-docs.netlify.app/how-to/automated-machine-management/node-tuning/

      • Node tuning operator (NTO) must be installed on the Management Cluster
      • "Tuned" profiles are YAML configurations that specify MachineConfigs
      • Tuned profiles are stored in ConfigMaps in the HC's namespace on the Management Cluster
      • When creating a NodePool, a user can select one/many stored Tuned ConfigMap(s) that should be applied to the specific NodePool

      Acceptance Criteria

      • Management clusters have NTO installed
      • Customers can create Tuned profiles for their cluster
        • Likely a YAML file that will only contain the `spec` field for a Tuned profile
        • The ROSA CLI would then upload this YAML into CS
      • Tuned profiles can be CRUD'ed through the ROSA CLI
      • Customers can select their above-created Tuned profiles to be applied when creating a NodePool or editing a NodePool
        • Tuned profiles can be selected interactively through the "rosa create machinepool" interface, or be attached without interaction by specifying a flag
      • The configuration gets pushed to the cluster's Nodes

      Default Done Criteria

      • All existing/affected SOPs have been updated.
      • New SOPs have been written.
      • Internal training has been developed and delivered.
      • The feature has both unit and end to end tests passing in all test
        pipelines and through upgrades.
      • If the feature requires QE involvement, QE has signed off.
      • The feature exposes metrics necessary to manage it (VALET/RED).
      • The feature has had a security review.* Contract impact assessment.
      • Service Definition is updated if needed.* Documentation is complete.
      • Product Manager signed off on staging/beta implementation.

      Dates

      Integration Testing:
      Beta:
      GA:

      Current Status

      GREEN | YELLOW | RED
      GREEN = On track, minimal risk to target date.
      YELLOW = Moderate risk to target date.
      RED = High risk to target date, or blocked and need to highlight potential
      risk to stakeholders.

      References

      Links to Gdocs, github, and any other relevant information about this epic.

       

            dtaylor@redhat.com David Taylor
            wgordon.openshift Will Gordon
            Jayakrishnan Mekkattillam Jayakrishnan Mekkattillam
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: