Adding new SupportedVersion condition to GatewayClass #2384
Conversation
k8s-ci-robot
added
release-note
k8s-ci-robot
added
the
approved
k8s-ci-robot
added
the
lgtm
| @@ -186,6 +187,49 @@ const ( | |||
| GatewayClassReasonWaiting GatewayClassConditionReason = "Waiting" | |||
| ) | |||
|
|
|||
| const ( | |||
| // This condition indicates whether the GatewayClass supports the version(s) | |||
| // of Gateway API CRDs present in the cluster. This condition MUST be set by | |||
There was a problem hiding this comment.
Since this condition "MUST be set", would it make sense to update the conformance tests too?
There was a problem hiding this comment.
Yes, I think we'll want to have corresponding updates to the conformance tests. I'd initially thought those should be a separate PR, but they may be simple enough to combine here.
There was a problem hiding this comment.
I'm aware of the dilemma with generally not wanting to rely on information from CRDs, but I'm also aware we don't have an alternative to get this feature. Also if we ever needed to change it, it would be mostly on implementations. Generally, if we ever move off CRDs I think having to change this will be the least of problems we have to contend with.
|
[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:
Approvers can indicate their approval by writing |
|
I think that we have no option than to require something like this; I'm working on an implementer's guide that will lay out some suggestions for how to determine the required information in the right way. I like the Condition idea because it allows implementations to mark the GatewayClass as I also agree that it would be nice to have conformance tests for this behavior, but I think that they may be harder to build than it seems (since we don't have any way to install different versions of the CRDs in the testing suite). So I am going to merge this as-is, and create an issue for follow-up conformance testing of this Condition. /unhold |
k8s-ci-robot
removed
the
do-not-merge/hold
What type of PR is this?
/kind documentation
/kind feature
What this PR does / why we need it:
This is intended to fix #2077 by adding a new SupportedVersion condition on GatewayClass and corresponding documentation.
Which issue(s) this PR fixes:
Fixes #2077
Does this PR introduce a user-facing change?:
/hold for consensus