-
Notifications
You must be signed in to change notification settings - Fork 1
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
Support user-specified image pull policy #132
Conversation
Codecov ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## main #132 +/- ##
==========================================
+ Coverage 56.60% 56.89% +0.28%
==========================================
Files 62 63 +1
Lines 3132 3164 +32
==========================================
+ Hits 1773 1800 +27
- Misses 1359 1364 +5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
This is needed to access the newly added types in the client package.
This commit adds support for pull policies in the runners. The job submission endpoint passes the pull policy to the runner, by default the policy is set to `Always` to prevent issues with stale images. The e2e test has been updated to pass `IfNotPresent` as the pull policy, since the job image for the test suite is built locally and cannot be pulled from a registry.
The `Runner` interface has been changed to accept an `ImageRef`, instead of importing the (useless) `Image` type from the client package. Co-authored-by: Max Mynter <maxmynter@users.noreply.github.com>
Closes #124
Todo's
IfNotPresent
as pull policy to support running e2e tests in cluster with no image registry available.../runner/ray.py: 46
.../guides/exeution-modes.md
)Notes
I have thought a bit about where to put the pull policy. Candidates were the
Image
orImageOptions
, or a standalone argument.I decided on the former as
ImageOptions
are defined when theJob
is defined but a user may want to change the pull policy without touching the job. The pull policy is more ephemeral thanImageOptions
.As we build up the
Image
on the backend we can at that point inject the pull policy.A separate object is imo not warranted as we never need a policy without an association to an image.