feat: move x-k8s to apix and add v1 InferencePool to api/v1

[capri-xiyue]

1. move inference.networking.x-k8s.io resources from /api to /apix
2. add inference.networking.x-k8s.io resources in /api

[k8s-ci-robot]

Hi @capri-xiyue. 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.

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.

[netlify]

✅ Deploy Preview for gateway-api-inference-extension ready!

Name	Link
🔨 Latest commit	70de454
🔍 Latest deploy log	https://app.netlify.com/projects/gateway-api-inference-extension/deploys/686c2c3cd35e6f000869b255
😎 Deploy Preview	https://deploy-preview-1116--gateway-api-inference-extension.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[capri-xiyue]

/assign @robscott

[capri-xiyue]

It's ready for review. I added DO-NOT-MERGE because this PR should be merged in v1 branch

[capri-xiyue]

It's ready for review. I added DO-NOT-MERGE because this PR should be merged in v1 branch

Change the base to be kubernetes-sigs:release-1.0

[kfswain]

/hold

Adding this label until we have confirmation that we can merge this PR without sig-net approval (or getting sig-net approval)

[kfswain]

/ok-to-test

[capri-xiyue]

/retest

[capri-xiyue]

/retest

[capri-xiyue]

/retest

[capri-xiyue]

/hold

Adding this label until we have confirmation that we can merge this PR without sig-net approval (or getting sig-net approval)

Currently I added the annotation api-approved.kubernetes.io=unapproved, experimental-only which matches the criteria defined in https://github.com/kubernetes/enhancements/pull/1111/files, I guess it should be ok to get the PR merged.

[capri-xiyue]

/assign @zetxqx

[k8s-ci-robot]

@capri-xiyue: GitHub didn't allow me to assign the following users: zetxqx.

Note that only kubernetes-sigs members with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign @zetxqx

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.

[zetxqx]

looks good to me! just one comment

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

Needs approval from an approver in each of these files:

• OWNERS

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

[capri-xiyue]

I followed https://github.com/kubernetes-sigs/gateway-api pattern to have api-x and api directory, otherwise make generate failed as it seems like it can't support different group CRD with the same name.

[robscott]

Thanks @capri-xiyue!

[robscott]

These should be updated to use aliases pointing to the v1 types. See https://github.com/kubernetes-sigs/gateway-api/blob/093f6538409c071e906856bd1ce4072204fb3f08/apis/v1beta1/gateway_types.go#L48-L55 for an example.

[capri-xiyue]

The existing make generate can't work with such alias usage, it will throw non-local type error. I guess it is because gateway-api use https://github.com/kubernetes-sigs/gateway-api/blob/main/hack/update-clientset.sh while this repo uses kube-codegen natively. I'm wondering should we move to gateway-api self-written codegen to support alias or we are fine with native kube-codegen with non-alias

1. change from kube-codegen to self-written codegen like gateway api to support alias usage like type EndpointPickerConfig = v1.EndpointPickerConfig

• pros: avoid type duplication
• cons: need to maintain self-written codegen

2. keep existing kube-codegen usage but need to duplicate the InferencePool types in alpha and v1

• pros: use kube-codegen and can get the latest code-gen feature without self-development
• con: duplicate the v1 and alpha type for now

cc @kfswain

[kfswain]

I'm not familiar with GW API's custom code gen tool so I'm not quite sure what tradeoffs we would be making. Generally speaking, we do use a pretty slimmed down version of kubebuilders codegen tooling.

And to share more context: we might have need to define a controller for the evolution multi-tenant APIs. So IGW and GW-API differ in that regard where GW API is primarily a shared API surface w/ conformance spec. IGW has the EPP and potentially an additional controller, so we might have different code gen needs.

I understand that isn't a clear decision, just sharing additional context to help with decision making. Ultimately, I think you @capri-xiyue and @robscott would know the tradeoffs between the two tools best. I can help more if needed, but would need a tl;dr for what each choice entails.

[capri-xiyue]

@kfswain
Here are the trade-off I think(also commented above)

• change from kube-codegen to self-written codegen like gateway api to support alias usage like type EndpointPickerConfig = v1.EndpointPickerConfig

  • pros: avoid type duplication, can use alias like type EndpointPickerConfig = v1.EndpointPickerConfig
  • cons: need to maintain self-written codegen

• keep existing kube-codegen usage but need to duplicate the InferencePool types in alpha and v1

  • pros: use kube-codegen and can get the latest code-gen feature without self-development
  • con: duplicate the v1 and alpha type for now

  Do you need additional info? For me, I think if gateway-api-inference-extension and gate-way-api may have different code gen needs, I prefer to keep using the existing slimmed down version of kubebuilders codegen tooling with which we can easily get the kubebuilder codegen latest feature easily without self development, the only cons is that we duplicate the CRD golang type in different versions, I think it is fine as I've seen such pattern commonly used in other k8s extension OSS repo, see events/v1 and events/v1beta1

[kfswain]

Discussed offline, @capri-xiyue and I agree that keeping the existing kubebuilder codegen tool is a better path forward, at the cost of duplicating the InferencePool spec into 2 different places.

Thanks @capri-xiyue!

[capri-xiyue]

@robscott suggested that we won't need deepcopy code like api/v1alpha2/zz_generated.deepcopy.go, therefore we can still use alias like type EndpointPickerConfig = v1.EndpointPickerConfig. As without deepcopy code api/v1alpha2/zz_generated.deepcopy.go, we won't hit the limitation of k8s codegen. I tried it, but still no luck as our repo uses the deepcopy code, see https://prow.k8s.io/view/gs/kubernetes-ci-logs/pr-logs/pull/kubernetes-sigs_gateway-api-inference-extension/1116/pull-gateway-api-inference-extension-test-e2e-main/1943761093448962048. Will continue the discussion with Rob.

At the same time I have filed an issue in kubernetes/code-generator#187 to get the confirmation from the code-generator side to see whether they have such support or not. I'm wondering for GA, can we tolerate the non-alias now and see later we can achieve using k8s-codegen natively and at the same time using alias? I searched the existing usage of k8s code generator. I have not found the usage of such alias. See https://github.com/kubernetes/api/blob/master/events/v1/types.go, https://github.com/kubernetes/api/blob/master/events/v1beta1/types.go. I guess the code-gen probably doesn't have such alias support right now.

[capri-xiyue]

Spent a few hours working together with Rob to see whether we can use existing kube codegen in this repo and at the same time with GW api types definition like type InferencePool v1.InferencePool. However, it will eventually lose alpha InferencePool CRD. Rob suggested v1.0 exclusively includes v1 InferencePool with no alpha version of InferencePool type or CRD, release channels come in to play later and will raise it in next OSS meeting.

For now, I will duplicate the alpha golang types for InferencePool to unblock @zetxqx GA efforts.

[capri-xiyue]

Currently it failed to pass the test because of #1116 (comment).

[capri-xiyue]

Currently it failed to pass the test because of #1116 (comment).

Revert it back to make it work.