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

[OSD & Rosa Classic] Cluster Autoscaler Max Node Total Default - 249 Nodes

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • Openshift Console / Editing Cluster Autoscaler default value - Support for 249 nodes
    • False
    • Hide

      Max Node limits are going to be returned from backend API, being tracked via https://issues.redhat.com/browse/OCM-11039

      Show
      Max Node limits are going to be returned from backend API, being tracked via https://issues.redhat.com/browse/OCM-11039
    • False
    • To Do
    • XCMSTRAT-161 - OSD & ROSA Classic scale to and upgrade with 249 nodes
    • 50% To Do, 17% In Progress, 33% Done
    • (10/22) short term solution to hardcode max to 249

      Overview

      When users open the UI console's modal to adjust the cluster's autoscaler max node total, it currently portrays a "default" value of 180.

      This is incorrect under certain scenarios.  We are going to do a short and long term solution.

      1. Short term.  
        1. Change 180 to 249 in both day 1  & 2 'Cluster Autoscaler Settings'. (A CONST in the UI)
        2. Add validation if user enters something over 249 (we currently don't do this!)
        3. Add tooltip to explain to user how to properly calc. and set the 'max nodes total'.
        4. 249 is the absolve max, however it will be lower in certain cluster configs depending on single zone and multi zone, and number of already existing nodes.
          Backend will do final validation of the value during cluster creation and it does return a pretty clear error message.
      2. Long Term
        1. It has be determined in this slack thread that rather than the UI using a CONST or doing calculations; it would be better if the backend API returns a set of values, so that CLI and UI have 'single source of truth'.
          The backend might send a list or map of all possible default values to the front end one time, and the frontend decides which value to return back to the user based on selections (single .vs MZ) made on the front end.   This part is going to be tracked in a different Epic

      Related to discussion:

      https://redhat-internal.slack.com/archives/C01G3PL29SS/p1725914440686789

      https://redhat-internal.slack.com/archives/C0534HDGBNW/p1723142301534779

      And results observed from:

      https://redhat-internal.slack.com/archives/C01G3PL29SS/p1723053946081229

      CC: pkreuser dtaylor@redhat.com dramakri@redhat.com

       

      Implementation Details

      • We will need a FedRAMP feature flag which would only be enabled after it has been tested in the FedRAMP environment.

       

              rh-ee-egilman Liza Gilman
              dle.openshift David Lee
              Jason Loss Jason Loss
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: