conformance: Move Inference Extension conformance helper functions to gateway-api/conformance#4602
Conversation
…ctions in gateway-api/conformance Signed-off-by: Eric Bishop <ericbish.dev@gmail.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: ericdbishop The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @ericdbishop. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
Work in progress. |
Signed-off-by: Eric Bishop <ericbish.dev@gmail.com>
| } | ||
|
|
||
| // NOTE: Used in Gateway API Inference Extension conformance. | ||
| func GetGatewayAcceptedCondition() metav1.Condition { |
There was a problem hiding this comment.
@ericdbishop Could you clarify why this function needs to be part of this repository if it’s only used for Inference Extension conformance?
I don’t quite see how this helps eliminate the circular dependencies.
There was a problem hiding this comment.
So my understanding was that any helper functions to check Gateway API CRD statuses/usage of the gatewayv1 apis in gateway-api-inference-extension could be moved here for general use, and this is to make sure that any changes in gateway-api wouldn't break gateway-api-inference-extension/conformance.
Maybe @rikatz could also help clarify what a good end state here would be, as we discussed this in the past few weeks.
There was a problem hiding this comment.
Also I realize this PR lacks testing, I will work on that if we agree these changes are useful.
There was a problem hiding this comment.
cc @zetxqx if you have additional thoughts.
There was a problem hiding this comment.
@snorwin mostly we are trying to avoid GIE importing Gateway API core just for its own assertions, so during a GIE meeting we have discussed about bringing these helper functions to the repository.
Eventually this will change, but for now what we want here is that GIE conformance has no dependency on Gateway API, just on Gateway API conformance
There was a problem hiding this comment.
Eventually this will change, but for now what we want here is that GIE conformance has no dependency on Gateway API, just on Gateway API conformance
@rikatz what I don’t quite understand is, what’s the practical difference between having an indirect dependency on the Gateway API (which you already have anyway, since it’s a dependency of Gateway API conformance) versus having a direct dependency on it?
To be honest, functions like this don’t seem to provide much value:
func GetGatewayProgrammedCondition() metav1.Condition {
return metav1.Condition{
Type: string(gatewayv1.GatewayConditionProgrammed),
Status: metav1.ConditionTrue,
}
}
Especially if they were introduced just to avoid importing gatewayv1.GatewayConditionProgrammed. In that case, it might be simpler for GIE to use "Programmed" as a plain string instead of adding extra helpers and cluttering the conformance utils.
There was a problem hiding this comment.
@snorwin basically depending on Gateway API core broke their release workflow, and we agreed that their conformance should depend as less as possible on Gateway API internals (they need a statement like "provision a gateway and wait to be ready")
There was an agreement during the GIE meeting and we that it was a low effort approach to get some helper functions on our side that would reduce their dependency, and in fact this is a very low effort :)
I am assuming we will come back to the conformance machinery this quarter to do some proper cleanups, and we may revisit all of this, but for now this is not really a change that will break anything on our side
There was a problem hiding this comment.
@rikatz sounds good to me. I was just trying to understand the issue.
There was a problem hiding this comment.
I'd be happy to consolidate some of these helper functions as a follow up, I have other conformance tasks I'm tracking here: #4478.
|
/ok-to-test sorry Eric, I owe you and I know! Just some busy days, I will try to be here soon |
| ObjectMeta: metav1.ObjectMeta{Name: routeNN.Name, Namespace: routeNN.Namespace}, | ||
| } | ||
| t.Logf("Deleting HTTPRoute %s", routeNN.String()) | ||
| require.NoError(t, c.Delete(context.TODO(), httpRoute), "failed to delete httproute %s", routeNN.String()) |
There was a problem hiding this comment.
what if this is not found? should it still error?
There was a problem hiding this comment.
I see what you're saying, but I'm tempted to leave this as-is, since it's the behavior they had in gateway-api-inference-extension and the only reason I could see it being 'not found' is if the user running the tests deletes the HTTPRoute somehow?
|
@rikatz Should be ready for another review. |
What type of PR is this?
/area conformance-machinery
What this PR does / why we need it:
Moving code from gateway-api-inference-extension/conformance that relies on importing Gateway API CRD types (mostly used there for checking status of Gateways when running conformance tests).
Part of an effort to improve conformance and circular dependency issues for projects that import both gateway-api/conformance and gateway-api-inference-extension/conformance: #4478
PR in gateway-api-inference-extension to be merged after this: kubernetes-sigs/gateway-api-inference-extension#2433
Does this PR introduce a user-facing change?: