WIP: Promote StorageClass to GA

[jsafrane]

Work in progress. This note will be removed when TODO list in "Feature tracker" is complete and agreed.

Description

Change StorageClass implementation from Beta to Stable.

We already went through Alpha and Beta, this feature tracks progress from Beta to Stable

Progress Tracker

• Design Approval

  • Design Proposal. This goes under docs/proposals. Doing a proposal as a PR allows line-by-line commenting from community, and creates the basis for later design documentation. Paste link to merged design proposal here: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/volume-provisioning.md

• Stable

  • moved kubernetes/community/contributors/design-proposals to docs/design/
    - cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
  • Change API:
    • introduced PersistentVolume.Spec.Class and PersistentVolumeClaim.Spec.Class attributes (instead of annotation volume.beta.kubernetes.io/storage-class)
    • change annotation storageclass.beta.kubernetes.io/is-default-class to storageclass.kubernetes.io/is-default-class
    • moved StorageClass from storage.k8s.io/v1beta1 to storage.k8s.io/v1
  • Completely removed alpha behavior (annotation volume.alpha.kubernetes.io/storage-class).
  • Updated e2e tests
  • detailed user docs and examples
    • updated existing docs at http://kubernetes.io/docs/user-guide/persistent-volumes/ with real attributes instead of annotations
    • updated existing examples in https://github.com/kubernetes/kubernetes/tree/master/examples/experimental/persistent-volume-provisioning with real attributes instead of annotations
    • cc @kubernetes/docs
    • cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

Open items

• should be mixing of selectors and classes part of this feature? Allow pvc.Selector and pvc.Class both to be set. community#247

More advice:

Design

• Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

• Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
• As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
  and sometimes http://github.com/kubernetes/contrib, or other repos.
• When you are done with the code, apply the "code-complete" label.
• When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
  check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
  testing. They won't do detailed code review: that already happened when your PRs were reviewed.
  When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

• Write user docs and get them merged in.
• User docs go into http://github.com/kubernetes/kubernetes.github.io.
• When the feature has user docs, please add a comment mentioning @kubernetes/docs.
• When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

[jsafrane]

cc: @kubernetes/sig-storage-misc

[thockin]

I endorse moving to GA.

I want to talk about is-default. I actually think it makes sense to stay as an annotation. Here's why. The defaultness or non-defaultness of a storage class is actually not a property of the class - it is a property of the admission system that is defaulting PVClaims.

We happen to have a simple defaulter as an admission controller, and that simple defaulter looks for a class that nominates itself as default. But it's not hard to imagine a more robust admission controller that assigned defaults based on service account, or namespace, or tenant ID. In those cases, it makes no sense to have an is-default property on StorageClass.

Now, we need to balance normalization of the API fields with user experience, and that is really the argument in play here. How bad is UX if we leave this as a (non-beta) annotation?

To drawn an analog, node.spec.podCIDR is effectively specific to a single network driver and is completely ignored by others, and is confusing, at best.

[jsafrane]

I want to talk about is-default. I actually think it makes sense to stay as an annotation.

Ack, your arguments sound reasonable, I updated the feature to remove only beta from the annotation.

[liggitt]

is this different than #36?

[jsafrane]

Oops, it is. I'm working on a feature for more than half a year without knowing about it :-(. Let's continue in #36.