In OSASINFRA-3610 we merged the Manila CSI Driver from openshift/csi-driver-manila-operator to openshift/csi-driver. As part of this migration, we noticed that the authentication mechanisms configured by the Cinder and Manila Driver Operators varies. We would like to address this and use the same authentication mechanism for both.

Both the Cinder and Manila CSI driver expect a configuration file, commonly referred to as a clouds.conf file. You can either embed authentication information directly into this file, or you can configure it to use a clouds.yaml file and rely on the underlying OpenStack SDK library used by the drivers, Gophercloud, to extract this information for us. While Cinder is doing the latter, Manila is doing the former. This in turn necessitates a few additional differences from the Cinder CSI Driver Operator:

• Credentials are ultimately provided to the Operator in a clouds.yaml format by the Cluster Storage Operator (standalone) or the Hypershift Operator/Hosted Control Plane Operators (HCP). As a result, the Manila CSI Driver Operator needs code to transform information from this format to the clouds.conf format. This code does not cover all authentication mechanisms supported by Keystone, meaning it will need changes if customers ever ask for something other than the v3password or v3applicationcredential authentication mechanisms.
• Because the (generated) clouds.conf file now contains authentication information, it needs to be stored in a secret rather than a config map.

Work items

We can resolve this discrepancy as follows:

• We should rework the Manila CSI Driver Operator to add a new controller that will generate a cloud.conf file containing relevant settings like [Global] use-clouds and [Global] clouds-file and save it to a config map. This will be very similar to the equivalent controller in the Cinder CSI Driver Operator and we may even be able to re-use the exact same code.
• We should tweak the assets to mount this new config map along with the secret containing the clouds.yaml file in the the controller and driver deployments.
• We should remove the old controller containing the previously generated clouds.conf secret.
• [Optional] We may wish to add a temporary controller to delete the previously generated clouds.conf secret, as it will no longer be used by anything.

Definition of Done

Both the controller and driver deployments of the Manila CSI Driver should use clouds.conf config map and a clouds.yaml secret.