1. Proposed title of this feature request

[RFE] Deploying ODF for external IBM FlashSystem storage using thick volumes that do not format as thin volumes causes warnings/errors on the Flashsystem side with storage calculations which disables the pool from creating new volumes

3. What is the nature and description of the request?

When creating thick volumes from ODF gui to a IBM flashsystem it creates them with formating on, which causes the volumes to not be available for use until formatting is done (2 TB takes 300 hours).

Cu would like option to create thick volumes that do not format and/or have more options on creation for ODF connection to flashsystem such as thin-compressed or compressed. Normal thin volumes, which is an option, cannot be used as it causes warnings/errors on the IBM Flashsystem side with storage calculations which disables the pool from being able to create new volumes.

If thin-compressed and compressed volumes could be added that would be the best as those play the best in data reduction pools.

thin-compressed should work yes as it can be calculated correctly in a data reduction pool. (if i select thin volume in ODF and compress them manually on the flash system side the error would also go away, but it's uncertain if ODF likes if we manually adjust or change settings on volumes it has created). Cu was also talking with IBM support to see what other options were available on the flashsystem side and received this in response:

-----------------------------------
"Generally, the use of thin volumes in DRP with FCMs is discouraged because we can not accurately gather compression ratio information from it.
I believe the option to create a thin only volume in a DRP pool with FCMs should be grayed out or even missing. However, since this is an externally created volume/s, the system allowed this.
Is there a possibility for the ODF to create thin and compressed or compressed only volumes?"
-------------------------------

Cu decided on going with thick volumes as that would be ok on the compression calculations for the flashsystem and did not require any modifications of the volumes created by ODF.

Also, cu doesn't have the resources/disks at the moment to have a separate pool just for OpenShift/ODF.

Is there anything that can be done to avoid this issue the next time storage is connected to an OpenShift cluster, as not much else can be done on the cluster for two weeks on the cluster now because of having to wait for the storage to be ready?

Would the option for creating thick volumes that do not format result in simply using the thin volumes option that is already available? If not, is it possible to implement thick volumes that do not format?

Can ODF be modified to create thin and compressed or compressed only volumes?

4. Why does the customer need this? (List the business requirements here)

Deploying using thick volumes would be ok on the compression calculations for the flashsystem and did not require any modifications of the volumes created by ODF. However, cu cannot do much else for two weeks on the cluster due to having to wait for the storage to be ready.

5. How would the customer like to achieve this? (List the functional requirements here)

Would the option for creating thick volumes that do not format result in simply using the thin volumes option that is already available? If not, is it possible to implement thick volumes that do not format?
Can ODF be modified to create thin and compressed or compressed only volumes?

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

Install ODF for external IBM FlashSystem storage [1].

[1] https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.15/html-single/deploying_openshift_data_foundation_in_external_mode/index#creating-an-openshift-data-foundation-cluster-for-ibm-flashsystem-storage_ibmfs-external

When selecting thick volumes, long format times are avoided.
It is possible to select thin-compressed or compressed-only volumes.

7. Is there already an existing RFE upstream or in Red Hat Bugzilla? No

8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL8, RHEL9)? No

9. Is the sales team involved in this request and do they have any additional input? No

10. List any affected packages or components.

ODF installer.

11. Would the customer be able to assist in testing this functionality if implemented? Yes.