Remove deprecated webhook interfaces

[nathanperkins]

Context: #2596

After giving projects a few versions to migrate, we should remove the webhook.Validator and webhook.Defaulter interfaces to prevent this issue from happening.

[nathanperkins]

cc: @alvaroaleman

[troy0820]

/kind support

@nathanperkins This will probably have to be a couple of minor releases before removal to prevent churn? Also, Kubebuilder scaffold will probably have to implement the webhook generation to not include this as well.

[sbueringer]

cc @camilamacedo86 for awareness

[nathanperkins]

This will probably have to be a couple of minor releases before removal to prevent churn?

Yeah, do you have milestone tracking so that it can be added to a future version? We might want to update the deprecation message to say when it will be removed as well so that users know when they will need to remove it.

[nathanperkins]

Also, Kubebuilder scaffold will probably have to implement the webhook generation to not include this as well.

I asked them to look into it here:

kubernetes-sigs/kubebuilder#3721

[troy0820]

Yeah, do you have milestone tracking so that it can be added to a future version? We might want to update the deprecation message to say when it will be removed as well so that users know when they will need to remove it.

I do not, but if we announce the planned deprecation for this in v0.17.0 and deprecate it in v0.18.0 and then remove it in v0.19.0, it'll give a little run way to be planned around k8s releases. Since we are on 1.29 now, that'll also give kubebuilder a chance to implement their strategy for this around their release schedule as well.

We probably should mark this as part of the v0.17.0 milestone? @sbueringer

[nathanperkins]

I do not, but if we announce the planned deprecation for this in v0.17.0 and deprecate it in v0.18.0 and then remove it in v0.19.0, it'll give a little run way to be planned around k8s releases. Since we are on 1.29 now, that'll also give kubebuilder a chance to implement their strategy for this around their release schedule as well.

@alvaroaleman already added the deprecation notice for next version in #2596. The deprecation notice is just to encourage shifting new usage and migration to the other interface so it probably doesn't need to wait for an entire version to be added.

So maybe we can announce and deprecate in 0.17 and then remove in 0.19?

[alvaroaleman]

yeah the deprecation will definitely be in the next version, the removal we will see, 0.19 sounds reasonable I guess

[sbueringer]

I created a v0.19.x milestone and added it there for now. Let's see what sort of feedback / pushback we get from the deprecation.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[sbueringer]

/remove-lifecycle stale

/lifecycle frozen

[sbueringer]

We're planning to merge this for 0.20, #2877 (comment)

[camilamacedo86]

Kubebuilder scaffold will be impacted by.
The new interfaces are not scaffolded used by it yet.

See that we have an open pr for it but the implamentation does not seems to be accurate: https://github.com/kubernetes-sigs/kubebuilder/pull/3723/files

Help to move forward is more than welcome.

[sbueringer]

@camilamacedo86 Responded on the thread on the PR. Let me know if you have any specific questions that I can help with (I don't have time to impelment the change in kubebuilder though).

And just to avoid misunderstanding, we will drop Validator/Defaulter with controller-runtime v0.20 in December/January. At this point it will have been deprecated for 3 CR minor release / ~ a year.

[troy0820]

@sbueringer I have to finish reviewing it but if it makes sense to just allow the types to still be scaffold with kubebuilder in the api directory (attaching controller-runtime as part of the api layer) than we can do that until we need to move them out of that directory with the go v5 plugin. I don't want to hold this up and maybe during the next release when it is removed, we can have it be moved.

I understand the scope would be to just not allow the use of Defaulter and Validator with kubebuilder but the other issues we identified with having the webhooks be attached to the types (living in the api directory) can be handled in a subsequent PR and addressed with a different plugin. (Maybe moving them to internal like where we keep the controllers)

I believe there is a follow up PR that focuses more on that and I can create an issue around this for discussion. I can work on the fixes here for the PR I have for controller-runtime and work on the limited scope we have to achieve the deprecation of the webhooks (Defaulter/Validator) with Kubebuilder @camilamacedo86 @nathanperkins

[sbueringer]

Not sure I follow for the kubebuilder changes to be honest. But the situation in controller-runtime seems clear to me. We're going to drop Defaulter/Validator entirely with CR v0.20.0

[camilamacedo86]

Hi @troy0820,

First,

We cannot change the Kubebuilder layout without careful consideration. We have a stable layout, and breaking changes would require a new plugin version unless we can ensure that these changes do not affect pre-existing projects and maintain backward compatibility. You can find more information about this in the Kubebuilder plugin versioning documentation.

The effort in Kubebuilder is divided into two steps:

1. Replace the deprecated interfaces with the new ones
   The key here is to ensure that we properly scaffold the Custom Interfaces and that they are implemented correctly. You can see more details in this pull request.

2. Discuss layout changes
   After completing step 1, we can move on to discuss potential layout changes. For that discussion, let's use this issue thread.

(Maybe moving them to internal, similar to where we keep the controllers.)

Webhooks are implemented for specific API versions, so before considering moving them to an internal directory within the APIs, we need to evaluate scenarios where:

• a) Should nobody be encouraged to import the webhooks, as is the case with controllers, or is that valid only for specific scenarios?
• b) What approach do we want to encourage people to adopt?

More info: https://kubernetes.slack.com/archives/C02MRBMN00Z/p1723373582440229