-
Notifications
You must be signed in to change notification settings - Fork 66
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
feat: Add vModelId to PayloadProcessor Payload #123
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@njhill -- your code changes look good. Would it make sense though to add some unit tests (or modify some of the existing ones) to test what should (should not) happen when vModelId
is (or is not) set?
FYI @RobGeada |
@ckadner yes, ideally we should add such unit tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do I remember you mentioned adding a unit test could be done using some existing helper functions without the overhead of setting up an extensive end-to-end test environment. If it could be done with reasonable effort, should we create an issue to track it where you could add some pointers? Was it this? #112 (comment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Motivation Currently the payloads passed to PayloadProcessors only contain the modelId, which in the case of vModels will be a "resolved" modelId corresponding to a particular model revision (in particular this will be true when used in KServe modelmesh-serving). It would be useful to include the vModelId too. Modifications Add a vModelId field to the Payload class and correspondingly update built-in PayloadProcessor implementations where applicable. It may be null if the request was directed at a concrete modelId rather than a vModelId. Result Both modelId and vModelId are available to PayloadProcessors Signed-off-by: Nick Hill <[email protected]>
2e4d1d6
to
b3dfb38
Compare
Signed-off-by: Christian Kadner <[email protected]>
New changes are detected. LGTM label has been removed. |
I see @njhill gave his |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ckadner, njhill, tteofili The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Motivation
Currently the payloads passed to PayloadProcessors only contain the modelId, which in the case of vModels will be a "resolved" modelId corresponding to a particular model revision (in particular this will be true when used in KServe modelmesh-serving). It would be useful to include the vModelId too.
Modifications
Add a
vModelId
field to thePayload
class and correspondingly update built-inPayloadProcessor
implementations where applicable.It may be null if the request was directed at a concrete modelId rather than a vModelId.
Result
Both modelId and vModelId are available to PayloadProcessors