• OCM UI EUS Channels
    • Product / Portfolio Work
    • False
    • False
    • In Progress
    • ROSA-403 - Enable EUS lifecycle for managed OpenShift clusters
    • 36% To Do, 36% In Progress, 27% Done
    • (10/6) Lot of uncertainty if it can be completed by the deadline. This needs to be watch very closely. If the code items aren’t in code review by Oct 10, it most likely will NOT make the deadline.

      Description

      As part of XCMSTRAT-1119, Managed OpenShift will expose a new EUS channel that will be used by all users.

      Users can create clusters using extend lifecycle (EUS) versions

      Users can see which channel group a cluster belongs to from the cluster overview page

      Users can switch channel group if their cluster version allows it

      Acceptance criteria

      When selecting the cluster version at day 1, users are able to select the "Extended update support" channel first

      When selecting the cluster version at day 1, unstable versions are no longer listed inside the cluster version dropdown. The unstable channels (Candidate, Nightly, Fast) are moved inside the new channel group field. Users wanting to use unstable versions will have to select their channel and (eventually) pick a version 

      When opening an existing cluster overview page, users are able to see the Channel group the cluster belongs to

      When opening an existing cluster overview page, users are able to switch to a different Channel group if other channels are available

      Users are able to update an EUS cluster

      Feature should be behind a feature flag.

      Mockups/Design

      See figma mockups for day1 and day2

      Notice that the edit link to change channel group inside cluster details is only on the pencil button. This new "pencil pattern" has to be applied to all edit links in the cluster details overview area (delete protection, billing marketplace account and owner).

      Out of scope

      NA

      Testing implications

      The EUS channel will be available to everyone (unlike non stable channels).

      The new channel will also be available for all clusters types.

      No changes are expected in regard to the "End of life" message, it comes from APIs. Same for end of life treatment in the support label. EOL is not related to EUS.

      Implementation notes

      For day 1 we are going to fetch the EUS versions along the stable ones from the /api/clusters_mgmt/v1/versions endpoint we already use. We are going to introduce a new channel selection field before the cluster version one. The options will be "Stable" and “Extended update support”.  Users within orgs with the unstable channel capability will also have the unstable channels options (Candidate, Fast, Nightly). See figma mockup for the UI design

      When opening an existing cluster overview page, we are going to add a new property “Channel group” and show the related value we can already retrieve from cluster.version

      In order to determine if it’s possible to change channel group, we are going to use again the versions /api/clusters_mgmt/v1/versions endpoint. We need to find all options for the specific version of the cluster. If there are multiple options for the same version (i.e. 4.15.0-stable and 4.15.0-eus) we are going to give the ability to switch between them (stable and eus in this example). Keep in mind that unstable channels are only visible to users belonging to organizations with the non_stable_channel_group capability (see hasUnstableVersionsCapability check we already use for the version selection field).

      Only users that have permission to update the cluster resource should be able to see the edit change group button at day2. The permission is referred to as canUpdateClusterResource in the code.

      In order to save the channel group change, we have to send a request to PATCH /api/clusters_mgmt/v1/clusters/$clusterId, with a payload like:

      {
        "kind": "Cluster",
        "version": {
         "kind": "Version",
         "channel_group": "eus"
       }
      }
      

      This API call could fail if there are already scheduled updates. In this case we display the error returned from the API. The user can then choose what to do (cancel the update or postpone the switch).

      No changes are expected in the update flow. We are already retrieving the available updates from the cluster specific endpoint, not the versions ones. We don't need to change anything besides verifying everything is working as expected.

      More information needed

      We will likely have to explain what the EUS channel is during day 1 and day 2. We will have updated docs about it (see OSDOCS-11705). We can add an help icon + tooltip to the channel selection field for day 1 and for the channel property switch for day 2. The tooltip can contain a brief description and a link to the docs.

      DDR

      https://docs.google.com/document/d/1q9S6UcL7ATjz_QoyurubVKrcs39FGT8TqY1wVfzP7Ao/edit?tab=t.0

              rh-ee-dcooper Dylan Cooper
              lponce@redhat.com Lucas Ponce
              Jayakrishnan Mekkattillam Jayakrishnan Mekkattillam
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: