graduate RetroactiveDefaultStorageClass feature to GA in 1.28

[RomanBednar]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Graduate RetroactiveDefaultStorageClass featrue to GA in 1.28.

Which issue(s) this PR fixes:

Fixes # - N/A

Special notes for your reviewer:

Does this PR introduce a user-facing change?

RetroactiveDefaultStorageClass feature is stable and enabled by default.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [KEP]: https://github.com/kubernetes/enhancements/issues/3333
- [Other doc]: https://github.com/kubernetes/enhancements/pull/4021
- [Other doc]: https://github.com/kubernetes/website/pull/41206

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[RomanBednar]

/retest

[carlory]

/cc @wojtek-t @smarterclayton

[carlory]

@RomanBednar As the feature-gate GAed and locked to default, we need also remove the EnableRetroactiveDefaultStorageClass field from the PersistentVolumeClaimSpecValidationOptions struct.

https://github.com/kubernetes/kubernetes/pull/111467/files#diff-c713e8919642d873fdf48fe8fb6d43e5cb2f53fd601066ff53580ea655948f0dR2031

On the other hand, we need remove the feature-gate checked in the pv controller.

https://github.com/kubernetes/kubernetes/pull/111467/files#diff-9a553e2f939f7ad1470cfe1cf8a48b56b39c6b34fb7ad820c79f2f43602499bdR354

[carlory]

/test pull-kubernetes-e2e-storage-kind-disruptive

[RomanBednar]

@RomanBednar As the feature-gate GAed and locked to default, we need also remove the EnableRetroactiveDefaultStorageClass field from the PersistentVolumeClaimSpecValidationOptions struct.

https://github.com/kubernetes/kubernetes/pull/111467/files#diff-c713e8919642d873fdf48fe8fb6d43e5cb2f53fd601066ff53580ea655948f0dR2031

On the other hand, we need remove the feature-gate checked in the pv controller.

https://github.com/kubernetes/kubernetes/pull/111467/files#diff-9a553e2f939f7ad1470cfe1cf8a48b56b39c6b34fb7ad820c79f2f43602499bdR354

@carlory Thank you for pointing that out. I'm aware of this but thought that a full cleanup of the featuregate should be done one release after GA (so 1.29) to keep a way to opt-out for one more release in case something goes wrong. If this is not desired procedure please let me know, but at this point I don't see any advantage of doing the full cleanup in 1.28.

[carlory]

At present, I have not found a requirement document that must do a comprehensive cleanup. This seems to be a common practice, for example:

• https://github.com/kubernetes/kubernetes/pull/117718/files
• https://github.com/kubernetes/kubernetes/pull/116741/files
• https://github.com/kubernetes/kubernetes/pull/116233/files

I think it's reasonable, when a feature is stable, to remove the feature-gate control of the code, to ensure that the feature is tested as expected by testing. When the feature-gate is removed in the next version, there will be no additional Code changes, which means there are no other risks

[RomanBednar]

@carlory According to Kubernetes deprecation policy the feature gate must function for not less than 6 months or 2 releases (whichever is longer) when transitioning from Beta to GA.

https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecation

[carlory]

@RomanBednar IMO, we need remove the feature-gate check logic, but remain the feature-gate existing in the command line in order to make the binary work when users specify the feature-gate as same as the default value util the deprecation window is complete.

If the feature-gate isn't locked to default, we need also remain the feature-gate check logic. because users can choose turn off/on a feature.

[RomanBednar]

@carlory Ah I see now, I'll do the cleanup then. Thanks!

[jsafrane]

/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 80a5f20b26b6097f0cafeb38fd842fa113810026

[msau42]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jsafrane, msau42, RomanBednar

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/apis/OWNERS [msau42]
• pkg/controller/volume/OWNERS [jsafrane,msau42]
• pkg/features/OWNERS [jsafrane,msau42]
• test/OWNERS [msau42]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment