Skip to content
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

Allow custom resources for runner pod #1095

Closed
augray opened this issue Nov 13, 2023 · 0 comments · Fixed by #1099
Closed

Allow custom resources for runner pod #1095

augray opened this issue Nov 13, 2023 · 0 comments · Fixed by #1099
Labels
enhancement New feature or request infrastructure Things that relate to setting up the runtime

Comments

@augray
Copy link
Member

augray commented Nov 13, 2023

No description provided.

@tscurtu tscurtu added enhancement New feature or request infrastructure Things that relate to setting up the runtime labels Nov 13, 2023
github-merge-queue bot pushed a commit that referenced this issue Nov 15, 2023
Closes #1095

Until now, runner pods could only use fixed resource requirements. We
had to pick a value that was big enough to not OOM in the vast majority
of cases while also not being wasteful in what was requested. This led
to a few limitations:

1. Not all runner pods had equal compute needs (inline runs might
require more or less memory, importing large libs might increase memory
near the limit for some workloads, etc.)
2. Anything requiring a secret could not be executed inline. Note that
inline (aka non-standalone) stuff should STILL be only used for
lightweight tasks, these do sometimes require secrets (ex: a func which
makes just one quick API call)
3. It wasn't possible to pursue cluster resource efficiency/reliability
goals by putting runner pods on non-pre-emptible nodes or similar.

This PR adds the functionality to overcome these limitations.

Testing
--------

- Executed the test pipeline using custom resources and looked at the
pod spec to confirm they were actually used
- cloned a pipeline run that had done that and confirmed that the cloned
one also used custom resources

In both cases I confirmed that custom compute (ex: cpu and mem) was
used, as well as that secrets were properly mounted to the runner.
neutralino1 pushed a commit that referenced this issue Apr 3, 2024
Closes #1095

Until now, runner pods could only use fixed resource requirements. We
had to pick a value that was big enough to not OOM in the vast majority
of cases while also not being wasteful in what was requested. This led
to a few limitations:

1. Not all runner pods had equal compute needs (inline runs might
require more or less memory, importing large libs might increase memory
near the limit for some workloads, etc.)
2. Anything requiring a secret could not be executed inline. Note that
inline (aka non-standalone) stuff should STILL be only used for
lightweight tasks, these do sometimes require secrets (ex: a func which
makes just one quick API call)
3. It wasn't possible to pursue cluster resource efficiency/reliability
goals by putting runner pods on non-pre-emptible nodes or similar.

This PR adds the functionality to overcome these limitations.

Testing
--------

- Executed the test pipeline using custom resources and looked at the
pod spec to confirm they were actually used
- cloned a pipeline run that had done that and confirmed that the cloned
one also used custom resources

In both cases I confirmed that custom compute (ex: cpu and mem) was
used, as well as that secrets were properly mounted to the runner.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request infrastructure Things that relate to setting up the runtime
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants