[feat] Latency Prediction CI tests#2651
[feat] Latency Prediction CI tests#2651Gregory-Pereira wants to merge 1 commit intokubernetes-sigs:mainfrom
Conversation
Signed-off-by: greg pereira <grpereir@redhat.com>
|
Skipping CI for Draft Pull Request. |
✅ 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: Gregory-Pereira The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
this looks good to me. will catch regressions in the latencypredictor python module. @Gregory-Pereira is this WIP? |
|
needs to be opened against the llm-d repo after the move. |
What type of PR is this?
Add one of the following kinds:
/kind feature
/area conformance-test
What this PR does / why we need it:
Functional / regression testing for latency prediction. Provides maintainers more clarity about if a change is affecting the codebase.
How it works:
On open PRs that modify the latencyprediction directory it will rebuild the images, tag them both by sha- and tag them by pr number. It will push those ephemeral images to this repo's package registry in
ghcr.io(open to alternatives here, I know y'all do something else with prow for on push builds). Then it patches the new images into thekustomization.yaml. It will then roll our functional tests with these new images.Important Technical Detail
After running these tests a bunch of times, I realized when you deploy the job at the same time as prediction and training servers, it will automatically skip every fixture in the job, which will show up as a pass. Instead we need to rollout the prediction and training servers, waiting for them to come online, before creating our test job.
Why only run this on open PRs and not on pushes to
main(merged work)?This is because the
cloudbuild.yamlwill already build images for every push to main - so if we want to test merged work too we should refactor this to a workflow call.Does this PR introduce a user-facing change?:
No user facing changes
cc @kaushikmitr @kfswain