[Standard] A simple, usable default StorageClass should be available in Kubernetes clusters

[martinmo]

At the moment, we have scs-0211-v1 SCS KaaS default storage class, which defines some contraints for a default storage class, if it exists. But it doesn't enforce that such an SC exists.

Proposal to be discussed:

1. Require that a default storage class exists and is properly annotated (storageclass.kubernetes.io/is-default-class).
2. It must support RWO access mode.
3. Users may delete this SC, it just has to exist in a fresh cluster.
4. How this default StorageClass is implemented, is up to the CSP. For example, it could be provided by something simple as rancher/local-path-provisioner.
5. Advanced requirements are out of scope, for example:
   • not being backed by local storage
   • support for allowVolumeExpansion
   • HA / redundancy
   • performance

Motivation: lower the entry barrier for users by making things work out of the box, wrt storage. For example, many Helm charts require either a default SC or the user needs to specifiy a SC name.

Risks: users may solely rely on this default SC without checking what guarantees it gives.

(CC @mxmxchere because he proposed this to me via chat and I endorse this.)

Definition of Done:

Please refer to scs-0001-v1 for details.

• [ ] Proposal has been written with name of the form scs-xxxx-v1-slug.md (only substitute slug)
• [ ] Proposal has the fields status, type, track set
• [ ] Proposal has been voted upon in the corresponding team
• [ ] Status has been changed into Draft, file renamed: xxxx replaced by document number
• [ ] If applicable: test script has been written (this item may be moved into a separate issue so long as the state is Draft)

[martinmo]

I've edited the above text and added some more details and thoughts to be discussed in upcoming calls.

[martinmo]

I brought this up in today's Container Call. The original author of the existing standard participated and he endorsed it as well. In the call, I think we reached consensus on the following:

• there must be a default SC
• the requirement of "not being backed by local storage" should remain
  • e.g., remember that in OpenStack, local storage is ephemeral
  • but users expect persistence, after all it's called PVC and (not EVC)
• there was a quick discussion whether this is too strict from a standards point of view
  • example: edge clouds probably cannot fulfill this -> but this a very special case and might be solved by another hypothetical certificate scope for edge environments

[joshmue]

Agreed.

Not explicitly stating that such storage class has to exist, was technically an oversight in the original standard, as it always was the intention.

I think the quickest way to handle the explicit would be a small change to the original standard. Instead of...

The default StorageClass is made default using the storageclass.kubernetes.io/is-default-class annotation, following Kubernetes upstream.

...something like...

A default StorageClass MUST exist and MUST be made default using the storageclass.kubernetes.io/is-default-class annotation, following Kubernetes upstream.

---

According to the consensus, the other points regarding data durability (not necessarily regarding availability) do not need changes, I guess.