Bug 1956725

Summary: Disable OCS installation for OCP 4.8 until OCS 4.7 is GA
Product: OpenShift Container Platform Reporter: N Balachandran <nibalach>
Component: assisted-installerAssignee: Priyanka <pjiandan>
assisted-installer sub component: OCS Plugin QA Contact: Lital Alon <lalon>
Status: CLOSED WONTFIX Docs Contact:
Severity: unspecified    
Priority: high CC: alazar, aos-bugs, cvultur, yobshans
Version: 4.8   
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: OCP-Metal-v1.0.21.1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-06-09 14:04:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description N Balachandran 2021-05-04 10:08:44 UTC
Description of problem:
OCS 4.x is supported on OCP 4.x and 4.x+1.
The current available version is OCS 4.6 which is not supported on OCP 4.8

Until OCS 4.7 is GA, please disable OCS when OCP 4.8 is selected.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Jiri Tomasek 2021-05-05 08:34:45 UTC
This will need to be enforced from the backend in a form of OCS cluster validation or similar solution. Moving to assisted-service

Comment 2 Ronnie Lazar 2021-05-06 14:40:43 UTC
OCS plugin should fail validation if user is trying to use an unsupported version

Comment 3 N Balachandran 2021-05-06 16:13:58 UTC
(In reply to Ronnie Lazar from comment #2)
> OCS plugin should fail validation if user is trying to use an unsupported
> version

I am unaware of how to find out the version of the Operator that will be installed. We currently only create a subscription to use the default channel for the operator (which is usually the latest version).

If there is a way to get this information before we install the operator, we can fail the validation.

There has been some discussion on splitting the manifests for operators to be able to handle version specific requirements.
Jira : https://issues.redhat.com/browse/MGMT-4669

Comment 4 Ronnie Lazar 2021-05-09 15:28:47 UTC
@nibalach currently the version of the operator is hardcoded, However, I think the ask here is for the operator's validation code to fail if the installed cluster version is not supported (4.8 in this case)

Comment 5 N Balachandran 2021-05-09 15:44:26 UTC
(In reply to Ronnie Lazar from comment #4)
> @nibalach currently the version of the operator is hardcoded,
> However, I think the ask here is for the operator's validation code to fail
> if the installed cluster version is not supported (4.8 in this case)

There are 2 options here:
1. OCS validation needs to check the OCP version and fail if it is 4.8
2. The UI should disable the OCS checkbox if the OCP version selected is 4.8. 

Both approaches are required until OCS 4.7 is out, after which the code will need to be removed.

Comment 6 N Balachandran 2021-05-09 15:48:41 UTC
(In reply to Ronnie Lazar from comment #4)
> @nibalach currently the version of the operator is hardcoded,
> However, I think the ask here is for the operator's validation code to fail
> if the installed cluster version is not supported (4.8 in this case)

To clarify , we do not hardcode the operator version. The latest available version of the operator is installed.

Comment 7 Ronnie Lazar 2021-05-09 15:50:19 UTC
@nibalach We had discussed this and since the logic of which version OCS supports is part of the OCS logic, it was decided that the OCS validation needs to make the check, not the UI

Comment 8 N Balachandran 2021-05-09 16:25:58 UTC
(In reply to Ronnie Lazar from comment #7)
> @nibalach We had discussed this and since the logic of which
> version OCS supports is part of the OCS logic, it was decided that the OCS
> validation needs to make the check, not the UI

Noted.

Comment 9 Priyanka 2021-05-14 09:32:49 UTC
Fix PR: https://github.com/openshift/assisted-service/pull/1734

Comment 10 Constantin Vultur 2021-06-09 14:00:20 UTC
Given OCS 4.7 is GA, I was able to deploy OCP 4.8 with OCS 4.7. 


# oc get po -n openshift-local-storage
NAME                                      READY   STATUS    RESTARTS   AGE
diskmaker-manager-65kfr                   1/1     Running   0          10m
diskmaker-manager-7zckl                   1/1     Running   0          10m
diskmaker-manager-z6gc6                   1/1     Running   0          10m
local-storage-operator-7d465457db-mb2jl   1/1     Running   0          21m

# oc get StorageCluster -n openshift-storage
NAME                 AGE   PHASE   EXTERNAL   CREATED AT             VERSION
ocs-storagecluster   10m   Ready              2021-06-09T13:29:10Z   4.7.0

# oc get sc
NAME                          PROVISIONER                             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
localblock-sc                 kubernetes.io/no-provisioner            Delete          WaitForFirstConsumer   false                  30m
ocs-storagecluster-ceph-rbd   openshift-storage.rbd.csi.ceph.com      Delete          Immediate              true                   30m
ocs-storagecluster-ceph-rgw   openshift-storage.ceph.rook.io/bucket   Delete          Immediate              false                  30m
ocs-storagecluster-cephfs     openshift-storage.cephfs.csi.ceph.com   Delete          Immediate              true                   30m
openshift-storage.noobaa.io   openshift-storage.noobaa.io/obc         Delete          Immediate              false                  25m

Comment 11 Constantin Vultur 2021-06-09 14:01:11 UTC
Also clusterversion

# oc get clusterversion
NAME      VERSION      AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.8.0-fc.7   True        False         34m     Cluster version is 4.8.0-fc.7

Comment 12 Yuri Obshansky 2021-06-09 14:04:39 UTC
Since OCS 4.7 is GA, the current bug is not relevant
Will be closed as WONFIX