OSDOCS-13459#Add cross-subscription support for Azure File

[lpettyjo]

Version(s): 4.19+

Issue: https://issues.redhat.com/browse/OSDOCS-13459

Link to docs preview: https://92108--ocpdocs-pr.netlify.app/openshift-enterprise/latest/storage/container_storage_interface/persistent-storage-csi-azure-file.html#persistent-storage-csi-azure-file-cross-sub-overview_persistent-storage-csi-azure-file

QE review:

• QE has approved this change.

Additional information:

PTAL: @gcharot @jsafrane @duanwei33

[ocpdocs-previewbot]

🤖 Tue May 13 19:35:32 - Prow CI generated the docs preview:

https://92108--ocpdocs-pr.netlify.app/openshift-enterprise/latest/storage/container_storage_interface/persistent-storage-csi-azure-file.html

[mburke5678]

@lpettyjo A few suggestions. Otherwise LGTM

[gcharot]

In case of static provisioning the SC name does not really matter it does not need to actually exists right? Should we call it out explicitly to avoid confusion ? i.e avoid customers wondering if they should create one.

@duanwei33

[duanwei33]

I think it matters, the sc name in PV and PVC helps binding, it could help avoid unexpected behaviour. (Like there are other azure-disk PVs without sc name and the size is the same)
But yes, the storage class itself (with the same name) exists or not will not impact the binding, I think for customer scenario, non-admin users have no access to list PV, so usually an admin will create a sc which a meaningful name and create pvs with the same sc name inside, then the non-admin users create the PVC with the sc for expected pvs.

In short, let's keep sc name in both pvc and pv.

[gcharot]

ok to keep it but it can be misleading as customers will not know what to set here.

[lpettyjo]

so.....leave as is or change?

[gcharot]

I was wondering if we should mention that the SC does not need to exist.
What happens if a user sets an existing (unrelated) storage class?

[jsafrane]

I personally think we should keep the SC in the example + comment that it's used to disable dynamic provisioning for such PV / PVC.

What happens if a user sets an existing (unrelated) storage class?

In theory nothing, the PVC will try to bind to an existing PV. In practice, when the manually created PV and PVC accidentally don't match, Kubernetes will try to dynamically provision a new PV. Which is not what the user wants. Either a dedicated SC with provisioner: kubernetes.io/no-provisioner or non-existing SC will ensure the dynamic provisioning does not happen. Mis-matched PV + PVC stay Pending and user can fix their errors.

[gcharot]

Agree to keep the SC in the PVC/PV definition i was just wondering if we could add an extra note on the fact that the SC should not actually to avoid potential user errors (or as Jan said create a no-provisioner one). Not mentioning anything can be error prone i think

[openshift-ci]

@lpettyjo: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.