Bug 2085383

Summary: Getting different behaviour while installing with wrong HPCS credentials on 4.10
Product: [Red Hat Storage] Red Hat OpenShift Data Foundation Reporter: Gayathri Menath <gmenath>
Component: ocs-operatorAssignee: Humble Chirammal <hchiramm>
Status: CLOSED NOTABUG QA Contact: Martin Bukatovic <mbukatov>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.10CC: Gayathri.M, hchiramm, jrivera, madam, mmuench, muagarwa, ocs-bugs, odf-bz-bot, sostapov
Target Milestone: ---Flags: hchiramm: needinfo? (gmenath)
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-10-11 09:50:36 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:
Attachments:
Description Flags
included 2 folders where one having clusterwide and storage class and one with storageclass encryption enabled with wrong HPCS none

Description Gayathri Menath 2022-05-13 08:20:33 UTC
Created attachment 1879338 [details]
included 2 folders where one having clusterwide and storage class and one with storageclass encryption enabled with wrong HPCS

Description of problem (please be detailed as possible and provide log
snippests):
I tried to install odf 4.10 with clusterwide and storageclass encryption enabled with invalid HPCS instance as a negative test. I am able to see the storage cluster is going to error state with error storage class not able to create as pre-req not met and while describing cephcluster, I am able to see status is True and type as Ready. Also able to see KMS related error on events, which is different from what RH conveyed us(expected cephcluster status as False with error details).

Also I tried the same HPCS instance for only storageclass encryption enabled. I can see both cephcluster and StorageCluster is in ready state and I am able to see all storage classes are created including the encrypted storage class. When I try to create a PVC from the encrypted storage class I got error.

The behaviour is different in both case even the HPCS instance is wrong. Also in the first case, cephcluster status is coming true, not False.

Version of all relevant components (if applicable):
ODF 4.10 installation

Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?
Yes, trying to rollout 4.10 ODF with HPCS. As an end user how to confirm the ODF is installed properly with HPCS encryption. And in both cases with wrong HPCS credential the behaviour is different. 

Is there any workaround available to the best of your knowledge?
No

Rate from 1 - 5 the complexity of the scenario you performed that caused this
bug (1 - very simple, 5 - very complex)?
1


Can this issue reproducible?
Yes

Can this issue reproduce from the UI?
Yes

If this is a regression, please provide more details to justify this:


Steps to Reproduce:
1.
2.
3.


Actual results:


Expected results:


Additional info:

Comment 4 Gayathri Menath 2022-05-18 09:36:01 UTC
Hi, any update on the issue raised

Comment 5 Gayathri M 2022-05-23 06:55:13 UTC
Hi, Can you please provide an update on the above issue raised

Comment 6 Mudit Agarwal 2022-05-31 13:27:02 UTC
Humble, please take a look.

Comment 7 Humble Chirammal 2022-05-31 14:17:46 UTC
>Also I tried the same HPCS instance for only storageclass encryption enabled. I can see both cephcluster and StorageCluster is in ready state and I am able to see all storage classes are created including the encrypted storage class. When I try to create a PVC from the encrypted storage class I got error.
>

Unfortunately I dont get the issue referred here.. The SC creation and its input is completely upto the admin and its just an object at API server.

The `real` validation and the parameters correctness only ( sspecially in context of params)  happens when it comes to the request path which actually happened here and caused the error scenario. In short, it seems to me completely working as expected and I dont see an issue/problem here!