Closed martinmo closed 1 week ago
I've edited the above text and added some more details and thoughts to be discussed in upcoming calls.
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:
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.
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:
storageclass.kubernetes.io/is-default-class
).allowVolumeExpansion
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.
scs-xxxx-v1-slug.md
(only substituteslug
)status
,type
,track
setDraft
, file renamed:xxxx
replaced by document numberDraft
)