Default storage class on bundle deploy
Bug #1815967 reported by
Ian Booth
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Kubernetes Control Plane Charm |
Fix Released
|
Medium
|
Mike Wilson |
Bug Description
I couldn't see the best project to file this under.
When CDK is deployed, we need to have a cluster default storage class created which provisions relevant disks for the underlying cloud, eg
google - gce-pd
aws - ebs
azure - azure disk
This is needed to allow Juju to work seamlessly on supported clouds.
Changed in charm-kubernetes-master: | |
status: | New → In Progress |
Changed in charm-kubernetes-master: | |
status: | In Progress → Fix Committed |
Changed in charm-kubernetes-master: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
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.