Provide install manifests that do not contain the gateway-api admission server

[arkodg]

What would you like to be added:
A release artifact similar to https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.8.1 which contains the installation manifests for Gateway API CRDs and not the Gateway API admission server and related resources

Why this is needed:

Installing the Gateway API admission server is optional and all its functionality has been replaced by CEL validations
https://kubernetes.io/blog/2023/08/29/gateway-api-v0-8/#cel-validation

[shaneutt]

Is this kind of a part of #2319? We could merge them as it would seem reasonable for one body of work to take care of both at the same time.

[arkodg]

@shaneutt yes its related to #2319, but imo having a smaller work item is much easier to track and assign to a community contributor

looks like https://github.com/kubernetes-sigs/gateway-api/blob/main/hack/build-install-yaml.sh needs to be updated to accomplish this goal, the question is around naming and content - should we just create a experimental-crds-install.yaml & standard-crds-install.yaml and keep the existing experimental-install.yaml & standard-install.yaml as is ?

[shaneutt]

@shaneutt yes its related to #2319, but imo having a smaller work item is much easier to track and assign to a community contributor

👍

looks like https://github.com/kubernetes-sigs/gateway-api/blob/main/hack/build-install-yaml.sh needs to be updated to accomplish this goal, the question is around naming and content - should we just create a experimental-crds-install.yaml & standard-crds-install.yaml and keep the existing experimental-install.yaml & standard-install.yaml as is ?

I'm not sure we should start having all these extras laying around, I think we should just remove the admission server bits and be done with it, v0.8.0 (the last release intended to "support" the webhook) is branched and any future webhook development should probably be isolated to that branch.

[arkodg]

cool @shaneutt, I can take care of this
/assign @arkodg

[robscott]

I'm not sure we should start having all these extras laying around, I think we should just remove the admission server bits and be done with it, v0.8.0 (the last release intended to "support" the webhook) is branched and any future webhook development should probably be isolated to that branch.

Unfortunately per #2319 we still actually need to keep the webhook around in v1.0. Because we've committed to supporting 5 trailing Kubernetes versions, we need to wait until v1.29 is live to fully drop the webhook. It looks like that is currently scheduled for Dec 5, and of course we want to launch v1.0 by the end of October. My suggestion would be for the default installation method to exclude the webhook starting in v1.0, but I think we still need to leave it around for that release and provide a way to install it as an add-on for 1.24 clusters.

[shaneutt]

Ah, yeah this had slipped my mind, and it's true so sorry about that @arkodg but I guess we can't get away with a toss in the bin on this one.

[arkodg]

Cool, waiting for specific guidance on this before continuing any further

[arkodg]

@robscott two options here, for each of standard and experimental, we have two install manifests

• crds-install & webhook-install
  OR
• crds-install & all-install (this file exists today)

which one do you prefer ?

[robscott]

Thanks @arkodg! Currently each release has experimental-install.yaml and standard-install.yaml files, I think we should keep those going forward, but remove the webhook from them and instead add a short-lived (v1.0 only) webhook-install.yaml, does that make sense? (The webhook installation is the same regardless of release channel).

I think the result would just be a relatively simple change to https://github.com/kubernetes-sigs/gateway-api/blob/main/hack/build-install-yaml.sh.

Maybe you were talking about different files than I was though, so let me know if I missed something.

[shaneutt]

I'm on board with that too 👍

[arkodg]

Thanks @arkodg! Currently each release has experimental-install.yaml and standard-install.yaml files, I think we should keep those going forward, but remove the webhook from them and instead add a short-lived (v1.0 only) webhook-install.yaml, does that make sense? (The webhook installation is the same regardless of release channel).

I think the result would just be a relatively simple change to https://github.com/kubernetes-sigs/gateway-api/blob/main/hack/build-install-yaml.sh.

Maybe you were talking about different files than I was though, so let me know if I missed something.

sgtm, on it !