Refactor Gateway API installation process and bump Gateway API v1.2.1

[tico88612]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Upgrade Gateway API to the latest version (v1.2.1), and remove templates (Gateway API manifests).

Which issue(s) this PR fixes:

Fixes #11630
Related #11636

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

[action required] If you need to install Gateway API offline, you must edit the `gateway_api_download_url` variable.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: tico88612
Once this PR has been reviewed and has the lgtm label, please assign vannten for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[tico88612]

/ok-to-test

[VannTen]

I presume the idea is to ship gateway api manifest unmodified and download them at runtime just as we do for other deps ? TBH, I'm not sure that's the way we should go. The download role is not in a great shape, and I think we should be cautious putting more things in it. Possible alternative: besides run-time download, or jinja templates, we could consider another alternative: vendoring We would have all the manifests in one directory possibly something like this: vendor/ - gateway-api/ - other-vendored-deps/ Even for things which we currently need to template (which gateway-api is not, if I'm correct), we could use the kubernertes.core.kustomize lookup to patch at the k8s tooling layer rather than in jinja (which might even be cleaner) I don't think update would be too much complicated, maybe git subtree could help ? I think we would want to avoid submodules because it's not straightforward when pulling kubespray itself. wdyt ?

[tico88612]

Our Gateway API is unmodified. (Yes, it should.)

Possible alternative: besides run-time download, or jinja templates, we could consider another alternative: vendoring

What is the context in which vendoring is used? Like other 3rd party packages (e.g. MetalLB, Argo CD, etc.)?

I don't think update would be too much complicated, maybe git subtree could help ? I think we would want to avoid submodules because it's not straightforward when pulling kubespray itself.

Git subtree will create a merge commit. Maybe I guess k8s-ci-robot won't allow this?
I won't prefer the Git submodule; it will complicate this project.

[VannTen]

Sorry, I though I had replied, apparently not.

What is the context in which vendoring is used? Like other 3rd party packages (e.g. MetalLB, Argo CD, etc.)?

Only for Kubernetes manifests yeah.

> I don't think update would be too much complicated, maybe git subtree could help ? I think we would want to avoid submodules because it's not straightforward when pulling kubespray itself. Git subtree will create a merge commit. Maybe I guess `k8s-ci-robot` won't allow this? I won't prefer the Git submodule; it will complicate this project.

I'll take your word for it, I haven't used subtree at all, only submodules. I don't think dumping raw manifests (preferably from a release/tag of the project in question) would be that complicated, no ? (this is a (probably much) larger scope, but we should probably try to make a global decision to have some consistency here, either manifests should be baked in, or downloaded like artifacts, or a 3rd solution)