Add an option to GatewayProvisioner CRD to watch subset of namespaces

[padlar]

fixes #5256

[pnbrown]

As discussed in person, this will need to wait for #5214, but can be lined up now by basing the branch off the other PR.

[codecov]

Codecov Report

Merging #5302 (36fbbb4) into main (bdb8b92) will decrease coverage by 0.46%.
The diff coverage is 40.00%.

❗ Current head 36fbbb4 differs from pull request most recent head 60f9e35. Consider uploading reports for the commit 60f9e35 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5302      +/-   ##
==========================================
- Coverage   78.18%   77.73%   -0.46%     
==========================================
  Files         138      139       +1     
  Lines       18480    18078     -402     
==========================================
- Hits        14449    14053     -396     
+ Misses       3755     3752       -3     
+ Partials      276      273       -3     

Impacted Files	Coverage Δ
internal/provisioner/model/model.go	92.30% <ø> (-0.10%)	⬇️
...ernal/provisioner/objects/deployment/deployment.go	88.28% <0.00%> (-1.21%)	⬇️
internal/provisioner/controller/gateway.go	61.93% <100.00%> (-0.12%)	⬇️

... and 26 files with indirect coverage changes

[skriss]

Thanks @padlar!

Once #5214 merges, we'll need to rebase this on upstream/main.

This will also need:

• make generate to be run and the results committed
• unit testing
• a changelog file per https://github.com/projectcontour/contour/actions/runs/4755394119/jobs/8449483023?pr=5302

[padlar]

• make generate to be run and the results committed

I have run make generate bunch of times with no changes. Not sure why the CI thinks otherwise. Go version v1.20.3 is the same.

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[skriss]

@padlar we've just merged #5214, so this should be ready for a rebase onto main. I'd suggest something like:

git fetch upstream main
git rebase -i upstream/main
<in the interactive rebase prompt, delete the lines for any commits that aren't yours>
<resolve any conflicts>
git push -f

[sunjayBhatia]

I think we want the documentation here and the release note to state that this field is for limiting the namespaces the Contour instance will watch for resource updates (and not what the Gateway Provisioner will watch)

[skriss]

One thing I'm realizing we haven't been great about as we add more options to ContourDeployment, is keeping in mind this section from the Gateway API spec:

It is recommended that [GatewayClass] be used as a template for Gateways. This means that a Gateway is based on the state of the GatewayClass at the time it was created and changes to the GatewayClass or associated parameters are not propagated down to existing Gateways. This recommendation is intended to limit the blast radius of changes to GatewayClass or associated parameters. If implementations choose to propagate GatewayClass changes to existing Gateways, that MUST be clearly documented by the implementation.

(ref. https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.GatewayClass)

So basically, any settings from the GatewayClass/ContourDeployment should be applied at the time of creating a Gateway's Kubernetes resources, but not subsequently updated if the GatewayClass/ContourDeployment change.

There is also kubernetes-sigs/gateway-api#1868 (GEP) to consider, which has recently been merged upstream but has not yet been added to the API.

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[sunjayBhatia]

Hey @padlar looks like we'll have to move this to the next release milestone since 1.26.0 is coming up

We'll have to discuss how to handle @skriss' comment #5302 (comment) and how we want to move this one forward