[RS-2260] Add GatewayAPI field to configure CRD management #3769
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nelljerram
added
kind/bug
The default behaviour - which is used when the new field is not set, or is set to "Reconcile" - is to keep the cluster's Gateway API CRDs aligned with those that the Tigera operator would install on a cluster that does not yet have any version of those CRDs. Alternatively, if this field is set to "PreferExisting", the Tigera operator will create the Gateway API CRDs if they do not already exist, but will not overwrite any existing Gateway API CRDs. This setting may be preferable if the customer is using other implementations of the Gateway API concurrently with the Gateway API support in Calico Enterprise. It is then the customer's responsibility to ensure that CRDs are installed that meet the needs of all the Gateway API implementations in their cluster.
nelljerram
force-pushed
the
gateway-crd-management
branch
from
a26970b to
135e1be
Compare
On reflection, it has to be this way, because for a customer with existing CRDs who upgrades, they will have no opportunity to change the new field to PreferExisting, before it is too late.
Brian-McM
reviewed
Feb 10, 2025
api/v1/gatewayapi_types.go
Outdated
| type GatewayCRDManagement string | ||
|
|
||
| const ( | ||
| GatewayCRDManagementReconcile GatewayCRDManagement = "Reconcile" |
There was a problem hiding this comment.
We could probably use this terminology / setting for any third part crd management, i.e. take away the Gateway prefix and put this in a common folder.
In order to do this we also need a "create only" component handler to indicate whether or not any of the requested objects already existed.
Brian-McM
approved these changes
Feb 13, 2025
|
/merge-when-ready squash-commits delete-branch |
|
OK, I will merge the pull request when it's ready, squash the commits when I merge it, and delete the branch after I've merged it. |
|
Removing "merge-when-ready" label due to new commits |
|
I'm sorry but I failed delete the branch after merging the pull request. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The default behaviour - which is used when the new field is not set, or is set to "PreferExisting" - is that the Tigera operator will create the Gateway API CRDs if they do not already exist, but will not overwrite any existing Gateway API CRDs. This setting may be preferable if the customer is using other implementations of the Gateway API concurrently with the Gateway API support in Calico Enterprise. It is then the customer's responsibility to ensure that CRDs are installed that meet the needs of all the Gateway API implementations in their cluster.
Alternatively, if this field is set to "Reconcile", the Tigera operator will keep the cluster's Gateway API CRDs aligned with those that it would install on a cluster that does not yet have any version of those CRDs.