-
Notifications
You must be signed in to change notification settings - Fork 195
Rename PodInfo struct to EndpointMetadata to better reflect its purpose #1866
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for gateway-api-inference-extension ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: shmuelk The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
facd8e6 to
0ec1d80
Compare
Signed-off-by: Shmuel Kallner <[email protected]>
Signed-off-by: Shmuel Kallner <[email protected]>
Signed-off-by: Shmuel Kallner <[email protected]>
Signed-off-by: Shmuel Kallner <[email protected]>
0ec1d80 to
474bc16
Compare
Signed-off-by: Shmuel Kallner <[email protected]>
|
PR needs rebase. 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. |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Gateway Inference Extension (GIE) PR #1663 added support for vLLM's Data Parallel feature. This feature enables running more than one exposed vLLM HTTP endpoint in a pod/container.
Previously the GIE assumed that there was only one vLLM endpoint per pod. Thus it tracked per pod information and called it PodInfo.
To simplify things PR #1663 simply treated each of the vLLM endpoints, described in a GIE InferencePool, as another pod with an appropriate PodInfo struct.
It was pointed out during the review of PR #1663 by @kfswain that we need to rename some of the structs due to the changes. Details can be found here
This PR is the first of several that will refactor/rename various structs/APIs to better reflect their usage.
In particular this PR:
Future PRs will do more of this refactoring/renaming and will improve variable names in the code as well.