Uploaded image for project: 'Red Hat Advanced Cluster Management'
  1. Red Hat Advanced Cluster Management
  2. ACM-1094

[RFE] Ability to select storage class for boot device when deploying cluster

XMLWordPrintable

    • [RFE] Ability to select storage class for boot device when deploying cluster
    • False
    • False
    • To Do
    • ACM-637 - Self-managed IPI provider support

      Epic Goal

      • Allow user to select the storage class / rootVolume type when creating a cluster on AWS

      Why is this important?

      With version 2.3 and future 2.4 the AWS instances get deployed with a boot device hosted on IO1 storage class. We whould let customers decide, for cost reasons' which storage class is to be used gp2 or io1
      Bugzilla RFE Issue:  https://bugzilla.redhat.com/show_bug.cgi?id=1994815 

      https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html 

      Scenarios

      1. On the Create cluster wizard for AWS, on the Node pools step, add a new dropdown for "EBS volume type" for each node pool (Control plane and worker pools)
        1. The default selection should be "io1"
        2. Add new selections, as organized in AWS documentation:  https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html 
          1. General Purpose SSD volumes
            1. gp3
            2. gp2
          2. Provisioned IOPS SSD volumes
            1. io2 Block Express
            2. io2
            3. io1
          3. Throughput Optimized HDD and Cold HDD volumes
            1. st1
            2. sc1
        3. Add tooltip
          1. The type of the root volume."
          1. Add launch link to the AWS documentation.
      1. Configure the selection in each node pool in the install-config.yaml
        1. https://docs.openshift.com/container-platform/4.10/installing/installing_aws/installing-aws-customizations.html#installation-aws-config-yaml_installing-aws-customizations 

      Acceptance Criteria

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

      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>

              bweidenb@redhat.com Bradd Weidenbenner
              showeimer Sho Weimer
              Nelson Jean Nelson Jean
              Kevin Cormier Kevin Cormier
              Joy Jean Joy Jean
              Bradd Weidenbenner Bradd Weidenbenner
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: