Description

As a cluster admin, I want to select an OCP version and a channel when creating clusters, so that I don't accidentally upgrade to Y+1 without evaluating the impact first.

Acceptance criteria 

• When creating a cluster, users will select an OCP version first and then a channel. The channel field will show all channels that support the selected OPC version. Both fields will present default values. 
• It’s not possible to select a “channel group” anymore, the channel group field is replaced with just a channel field.
• A tooltip on the channel field explains the new field and how it works.
• It is possible to change channel on day 2 inside cluster details and cluster settings.

Mockups/Design

No wireframes atm.

Cluster creation wizard (day 1)

The Channel group field is removed and replaced with the Channel one. We are also switching their order inside the wizard form. The Version field will come first, then the Channel field. This is mainly because we are only showing channels available for that specific version.

A tooltip on the Channel field will explain the migration from channel groups to channels. 

The Version field will be reverted to what it was before the initial EUS effort (OCMUI-3690). It will be a single dropdown showing all versions grouped by channel groups:

• Stable (full support)
• Stable (maintenance support)
• EUS
• Candidate 
• Fast 
• Nightly 

Unstable versions (Candidate, Fast, Nightly) are already behind a feature flag enabled only on stage. They also require the unstable channels capability in the users’ org.

Cluster details (day 2)

The Channel group property will be replaced by the Channel one. It will be possible to change the channel value following the same patterns we have today for the channel group (modal with a form containing a field with the available channel options).

Cluster upgrades

It will not be possible to upgrade from Y to Y+1 without changing channel first (from stable-4.15 to stable-4.16 for example). Suggested upgrades and the upgrade process stay unchanged.

Given that in order to do Y upgrades it will be necessary to switch channels first, we want to provide a way to change channels in the “Cluster > Settings” tab too. We will add another card before the “Update status” one with the channel switching ability, similarly to what we do in the “Cluster > Overview” tab.

Out of scope

The Version field is going to show even more options than before. We should consider changing the approach, possibly removing the dropdown options and only leaving a typeahead field.

We should at some point investigate how the upgrade experience differs between OCM, ACM and OCP consoles (showing risks, upgrade path, etc)

Testing implications

• Creating clusters on different channels
• Verifying available upgrades before and after changing channels
• Upgrading clusters

Implementation notes

The /versions endpoint will include a new property, called “available_channels”, like: 

{
  "kind": "Version",
  "id": "openshift-v4.16.50",
  "channel_group": "stable",
  "default": "false",
  "available_channels": [
    "stable-4.16", 
    "stable-4.17",
    "stable-4.18",
    "eus-4.16",
  ],
    ...
} 

We already pick the default Version using the “default” property. We will use the available channels property to populate the “Channel” field options. The API will return a sorted array of available channels, the default value we will use in the field will be the first one.

The Cluster spec on the API side will have a new channel property. When creating clusters, we will send the selected channel with the payload, e.g.:

{
  "name": "my-cluster",
  "channel": "stable-4.16",
  "version": { "id": "openshift-v4.20.0" },
  ...
} 

For day 2, we will retrieve the channel from the Cluster response. 

We will get the available channels based on the cluster version using the versions API. If we don’t cache them already, it’s possible to inquiry for a specific version by calling for example /api/clusters_mgmt/v1/versions/openshift-v4.16.50 and accessing the “available_channels” property of the returned item

Similarly to what we do today, the API call to update the channel is a patch to /api/clusters_mgmt/v1/clusters/cluster_id with a payload like:

{
  "channel": "stable-4.17"
} 

More information needed

NA