feat(api): Add appProtocol to InferencePool API for gRPC support#2162
feat(api): Add appProtocol to InferencePool API for gRPC support#2162k8s-ci-robot merged 4 commits intokubernetes-sigs:mainfrom
Conversation
✅ Deploy Preview for gateway-api-inference-extension ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
The only failure is the CRD validation check. From the CRD validation failure, it's really just because I added the CEL validation on targetPorts: Thus, we need to force merge by approver for this PR. /assign @ahg-g |
| // +kubebuilder:validation:MinItems=1 | ||
| // +kubebuilder:validation:MaxItems=8 | ||
| // +kubebuilder:validation:XValidation:message="port number must be unique",rule="self.all(p1, self.exists_one(p2, p1.number==p2.number))" | ||
| // +kubebuilder:validation:XValidation:message="all ports must have the same AppProtocol",rule="self.all(p, (has(p.appProtocol) ? p.appProtocol : 'Unset') == (has(self[0].appProtocol) ? self[0].appProtocol : 'Unset'))" |
There was a problem hiding this comment.
why define it in TargetPort if all ports must share the same protocol? why not define it directly here?
There was a problem hiding this comment.
Good call, listing the pros and cons below. I feel add a single appProtocol in InferenceSpec is better. So I changed accordingly. PTAL
Option 1. the original change: add appProtocol to Port and create a separate Port for EndPointPicker.
Pros:
- more aligned with the structure of servicePort putting Port and AppProtocol at the same level.
- give possibility for future mix gRPC and http model support
Cons:
- break the goClient backward compatibility
- poor user experience, user has to explicitly set all the appProtocol for every ports
Option 2. new solution(the comment here), add appProtocol in parallel with targetPorts.
Pros:
- simple change
- no breaking change even in go client.
- simple user experience
Cons:
- a little different from servicePort
- don't support mix protocol model servers. But this could be a very rare use cases. and we can always introduce new appProtocol field to Port(as option 1) to override it if necessary.
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahg-g, zetxqx The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
…ernetes-sigs#2162) * Add appProtocol for gRPC support. * rename the proposal folder to include pr number. * move appprotocol out of Port. * add default.

What type of PR is this?
/kind feature
What this PR does / why we need it:
Add appProtocol field to InferencePool API for further gRPC support.
Also includes the proposal of gRPC support.
Which issue(s) this PR fixes:
Fixes #2164
Does this PR introduce a user-facing change?: