Comment 1 for bug 1815967

We had some discussion about this today. We could certainly add logic in the k8s charms to create an appropriate SC out of the box depending on which, if any, integrator charm is available. However, due to the differing levels of support from the various providers and the need to handle the case where an integrator charm isn't available, it may be that another approach would give us a more consistent and reliable level of support.

Specifically, it seems that CDK + CephFS is already being deployed in the field, and the k8s charms have support for CephFS and the CephFS CSI plugin. If we made this part of the default CDK bundle, and preferentially use that to back the standard storage class, it would be a much nicer experience out of the box. Additionally, if we're smart about placement, we could do this without adding any additional machines to the bundle.

The main caveats are:

* CephFS doesn't work under LXD, due to the need for block device access for storage (at least according to my current understanding). This would limit deploying CDK on a LXD provider.

* Juju would still need to be able to handle being handed a non-CDK cluster that may not provide the standard SC. But this would apply equally to the integrator approach and eventually, we can't get around the limitation that we can't introspect what provisioners are available on a random cluster, so we have to rely on the cluster admin (or charms) to provide a SC we can use.