change default storageclass

[stefanbudim]

change default storageclass (FeatureRequest)

Currently it is not possible to change the default storage class.

Usecase: partition-gold should be the default storage class.

Try a workaroud:
set annotations on csi-lvm  to storageclass.kubernetes.io/is-default-class: 'false' 
k edit storageclass csi-lvm
Not works as gardener immediatly overwrite this change.

According to my information it is also not possible to delte storage class csi-lvm.

Current situation: 
we have two default storage classes csi-lvm  and partition-gold
To use partition-gold  the PersistentVolumeclaim must specify  partition-gold explicitly.

k get storageclasses
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
csi-lvm (default) metal-stack.io/csi-lvm Delete WaitForFirstConsumer false 329d
partition-gold (default) csi.lightbitslabs.com Delete Immediate true 50d
partition-silver csi.lightbitslabs.com Delete Immediate true 50d

{
    "apiVersion": "storage.k8s.io/v1",
    "kind": "StorageClass",
    "metadata": {
        "annotations": {
            "resources.gardener.cloud/description": "DO NOT EDIT - This resource is managed by gardener-resource-manager.\nAny modifications are discarded and the resource is returned to the original state.",
            "resources.gardener.cloud/origin": "c830a6e8-0bb0-4202-8f2e-9e63a04450a5:shoot--pbrdgj--dev01/extension-controlplane-storageclasses",
            "storageclass.kubernetes.io/is-default-class": "true"
        },
        "creationTimestamp": "2021-03-02T16:57:12Z",
        "labels": {
            "shoot.gardener.cloud/no-cleanup": "true"
        },
        "managedFields": [
            {
                "apiVersion": "storage.k8s.io/v1",
                "fieldsType": "FieldsV1",
                "fieldsV1": {
                    "f:metadata": {
                        "f:annotations": {
                            ".": {},
                            "f:resources.gardener.cloud/description": {},
                            "f:resources.gardener.cloud/origin": {},
                            "f:storageclass.kubernetes.io/is-default-class": {}
                        },
                        "f:labels": {
                            ".": {},
                            "f:shoot.gardener.cloud/no-cleanup": {}
                        }
                    },
                    "f:provisioner": {},
                    "f:reclaimPolicy": {},
                    "f:volumeBindingMode": {}
                },
                "manager": "gardener-resource-manager",
                "operation": "Update",
                "time": "2021-12-20T13:51:26Z"
            }
        ],
        "name": "csi-lvm",
        "resourceVersion": "143695465",
        "selfLink": "/apis/storage.k8s.io/v1/storageclasses/csi-lvm",
        "uid": "1ee39463-f9f4-4062-ab1e-34a369abda16"
    },
    "provisioner": "metal-stack.io/csi-lvm",
    "reclaimPolicy": "Delete",
    "volumeBindingMode": "WaitForFirstConsumer"
}

[majst01]

How do you envision should this be done in a backwards compatible way. If we change the default storage class to partition-gold for example, this would break existing clusters which didnt specifiy the storageclass in their PVCs

[mwennrich]

some possible ideas:

• setting default storageclass annotation somehow via some shoot.spec provider-parameter
• setting resources.gardener.cloud/ignore: "true" on the csi-lvm storageclass, allowing it to be altered via kubectl

[mwennrich]

Another option like with aws-provider:

The storage.managedDefaultClass controls if the default storage / volume snapshot classes are marked as default by Gardener. Set it to false to mark another storage / volume snapshot class as default without Gardener overwriting this change. If unset, this field defaults to true.

https://github.com/gardener/gardener-extension-provider-aws/blob/master/docs/usage-as-end-user.md?plain=1#L245

[Gerrit91]

But then they can only mark our csi-lvm storage class as default or none of the managed storage classes at all, right?

With AWS I guess it's not a problem because you can deploy your own storage classes. But our users cannot deploy own Lightbits storage classes. If they want, say, partition-silver as a default storage class, then the duros-controller somehow needs to know.

So, I am not sure how great the benefit for our users really is if we implement such a flag. In addition, we do not want to encourage self-deployed storage classes so much as they are difficult to account with our accounting model. Maybe if we'd offer self-managed storage classes for Lightbits, but I am not sure if it's worth the effort and how the interface for a user would be like.