Welcome @wgahnagl!

It looks like this is your first PR to kubernetes/kubernetes 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/kubernetes has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

Hi @wgahnagl. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

/kind feature
/sig node
/ok-to-test
/priority important-soon
/triage accepted

/test pull-kubernetes-e2e-kind

/retest

This LGTM, the only real difference from #99263 is that PR removes the feature gates.

I don't understand why that wouldn't happen in the release where the feature gates actually get removed; otherwise, if for some reason we want to turn it back off the reverts would be very messy. What is the point of going through the step to lock the feature gate to true and not just remove it entirely if we're going to remove all the codepaths in advance of removal? cc @dims

/lgtm
🎉 for your first PR

A small comment on PR description part, additional documentation for KEP link should be like https://github.com/kubernetes/kubernetes/blame/master/.github/PULL_REQUEST_TEMPLATE.md#L66

- [KEP]:  link

/approve

/assign @liggitt

/approve

for removal of locked GA feature gate checking in API helpers.

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ehashman, liggitt, mrunalp, pacoxu, wgahnagl

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

The pull request process is described here

What is the point of going through the step to lock the feature gate to true and not just remove it entirely if we're going to remove all the codepaths in advance of removal?

Feature gates are user-visible in the CLI invocation. Locking to true at GA lets us simplify the code while giving deployments that opted into the feature early and are explicitly enabling it time to adjust their invocations to drop the explicit enable.

https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior tried to describe this (but I acknowledge it is confusing):

Feature gates are intended to cover the development life cycle of a feature - they are not intended to be long-term APIs. As such, they are expected to be deprecated and removed after a feature becomes GA or is dropped.

As a feature moves through the stages, the associated feature gate evolves. The feature life cycle matched to its corresponding feature gate is:

• Alpha: the feature gate is disabled by default and can be enabled by the user.
• Beta: the feature gate is enabled by default and can be disabled by the user.
• GA: the feature gate is deprecated (see "Deprecation") and becomes non-operational.
• GA, deprecation window complete: the feature gate is removed and calls to it are no longer accepted.

/hold cancel

Thanks @liggitt ! @dims also put together kubernetes/community#5545