Remove validating webhook

[robscott]

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
As described in #2319, it's time for the webhook to go away. The next minor release of Gateway API will not include the webhook, so there's no need to keep it around. This should also dramatically speed up presubmits.

Does this PR introduce a user-facing change?:

The validating webhook has been removed. CEL validation is now built-in to CRDs and replaces the webhook.

[robscott]

This is a pretty big PR, will add a hold so we can get at least a couple reviewers to sign off on this.

/hold

[LiorLieberman]

not CEL validation ? I feel like CRD validation is vague and can be done in various different ways and not necessarily CEL

[LiorLieberman]

ditto for other mentions of CRD validation

[robscott]

Yep, you're right, this is intentionally vague. CRD validation is intended to cover all forms of built-in validation, including both CEL and OpenAPI, I don't think we need to provide that level of detail in the spec though as the implementation details of the validation could change without meaningfully changing the spec.

[Xunzhuo]

Generally LGTM, thanks for working on it Rob, since it is a big PR, defer to other forks to have a look, in case we do not miss anything.

[shaneutt]

We still have a section in guidelines.md entitled Limitations of CRD and Webhook Validation which we may want to reword some, as it seems the relevance will be somewhat changed and broken after this PR.

Also found a couple other documentation areas, you can probably just apply this diff to resolve them:

diff --git a/site-src/concepts/versioning.md b/site-src/concepts/versioning.md
index 4a254122..d9e11f48 100644
--- a/site-src/concepts/versioning.md
+++ b/site-src/concepts/versioning.md
@@ -2,12 +2,11 @@
 
 ## Overview
 Each new release of Gateway API is defined with a "bundle version" that
-represents the Git tag of a release, such as v0.8.0. This contains the
+represents the Git tag of a release, such as v1.0.0. This contains the
 following:
 
 * API Types (Go bindings for the resources)
 * CRDs (Kubernetes definitions of the resources)
-* Validating Webhook (Will be deprecated in v1.0 release)
 
 ### Release Channels
 Release channels are used to indicate feature stability within Gateway API. All
diff --git a/site-src/contributing/contributor-ladder.md b/site-src/contributing/contributor-ladder.md
index d498de5b..760fb7f7 100644
--- a/site-src/contributing/contributor-ladder.md
+++ b/site-src/contributing/contributor-ladder.md
@@ -85,7 +85,6 @@ reviewer or approver, this includes:
 * Conformance
 * Documentation
 * GEPs
-* Webhook Validation
 
 ## Maintainers and GAMMA Leads
 

If not part of THIS pr, then definitely of one in the future as we cut the release that removes the webhook.

[robscott]

Thanks @shaneutt! I applied your suggestions + added the following note on the guidelines.md file:

    Webhook validation in Gateway API has been deprecated and will be fully
    removed in v1.1.0. With that said, all of this guidance will still apply for
    implementations as long as they support v1.0.0 or older releases of the API.

[youngnick]

Hmm, for all the files in /validation, are breaking an API by removing this validation code? Is this code used directly by implementations, rather than just in the webhook? Should we do a separate deprecation for it?

[robscott]

Good question. In my opinion, this is covered under "source code" within our versioning policy which has no compatibility guarantees: https://gateway-api.sigs.k8s.io/concepts/versioning/#source-code. I started to split this out to leave validation code in and just deprecate the packages, but I think that could lead to a worse outcome - stale code. Although we have some unit tests for the code, by removing the webhook, we'd be removing one of the primary ways we tested this code. I think the removal of this is adequately covered by the overall webhook deprecation announcements we made in the v0.8 and v1.0 release notes.

[youngnick]

🎉

[youngnick]

LGTM with one caveat about if we can remove the validation packages yet.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: robscott, shaneutt

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:

• OWNERS [robscott,shaneutt]

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

[youngnick]

/lgtm

[robscott]

I think this has sat long enough, been discussed at multiple community meetings, and now has multiple approvals, removing the hold.

/hold cancel

[jwendell]

Should the validation go package be removed only from v1 and not from v1alpha1 and v1beta1?

Asking because Istio imports sigs.k8s.io/gateway-api/apis/v1alpha2/validation to perform some validation, and now they are gone. How can we support both 1.0 and older?

[howardjohn]

Should the validation go package be removed only from v1 and not from v1alpha1 and v1beta1?

Asking because Istio imports sigs.k8s.io/gateway-api/apis/v1alpha2/validation to perform some validation, and now they are gone. How can we support both 1.0 and older?

Istio doesn't support v1alpha2 anymore. I think the current logic is broken in Istio, and can probably be removed entirely given the removal of the webhook?

[robscott]

Since CEL has been present in CRDs since v0.8 and this validation code will only be removed as part of the v1.1 release (when this PR will get released), I think it's likely safe to remove any code that ran these validations controller-side when you upgrade to importing v1.1. Note that the v1.1 release is still likely at least a couple of months away.