Skip to content

conformance: Move Inference Extension conformance helper functions to gateway-api/conformance#4602

Open
ericdbishop wants to merge 4 commits intokubernetes-sigs:mainfrom
ericdbishop:conformance-helper-functions-from-gaie
Open

conformance: Move Inference Extension conformance helper functions to gateway-api/conformance#4602
ericdbishop wants to merge 4 commits intokubernetes-sigs:mainfrom
ericdbishop:conformance-helper-functions-from-gaie

Conversation

@ericdbishop
Copy link
Contributor

@ericdbishop ericdbishop commented Feb 25, 2026

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?:

NONE

…ctions in gateway-api/conformance

Signed-off-by: Eric Bishop <ericbish.dev@gmail.com>
@k8s-ci-robot k8s-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. release-note-none Denotes a PR that doesn't merit a release note. area/conformance-machinery Issues or PRs related to the machinery and the suite used to run conformance tests. labels Feb 25, 2026
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

Details Needs approval from an approver in each of these files:

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

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Feb 25, 2026
@k8s-ci-robot
Copy link
Contributor

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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions 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.

@ericdbishop
Copy link
Contributor Author

Work in progress.

Signed-off-by: Eric Bishop <ericbish.dev@gmail.com>
@ericdbishop ericdbishop marked this pull request as ready for review February 26, 2026 22:17
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 26, 2026
}

// NOTE: Used in Gateway API Inference Extension conformance.
func GetGatewayAcceptedCondition() metav1.Condition {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also I realize this PR lacks testing, I will work on that if we agree these changes are useful.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @zetxqx if you have additional thoughts.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rikatz sounds good to me. I was just trying to understand the issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@rikatz
Copy link
Member

rikatz commented Mar 18, 2026

/ok-to-test

sorry Eric, I owe you and I know! Just some busy days, I will try to be here soon

@k8s-ci-robot k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Mar 18, 2026
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())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if this is not found? should it still error?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Mar 19, 2026
@ericdbishop
Copy link
Contributor Author

@rikatz Should be ready for another review.

@ericdbishop ericdbishop requested a review from rikatz March 20, 2026 15:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/conformance-machinery Issues or PRs related to the machinery and the suite used to run conformance tests. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. release-note-none Denotes a PR that doesn't merit a release note. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants