Bug 1956725 - Disable OCS installation for OCP 4.8 until OCS 4.7 is GA
Summary: Disable OCS installation for OCP 4.8 until OCS 4.7 is GA
Keywords:
Status: NEW
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: assisted-installer
Version: 4.8
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
: ---
Assignee: Priyanka
QA Contact: Lital Alon
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-04 10:08 UTC by N Balachandran
Modified: 2021-05-09 16:25 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)

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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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.


Note You need to log in before you can comment on or make changes to this bug.