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

[batch] Properly expose and document "job-private instances" #14500

Open
daniel-goldstein opened this issue Apr 25, 2024 · 0 comments
Open

[batch] Properly expose and document "job-private instances" #14500

daniel-goldstein opened this issue Apr 25, 2024 · 0 comments

Comments

@daniel-goldstein
Copy link
Contributor

What happened?

It might also be good to consider a better public-facing name.

While nearly all jobs in Batch are scheduled on shared machines, a user sometimes wants a custom machine type that we don't offer shared pools for. The solution in that instance is a "job-private" machine, where we spin up a machine that lives and dies along with the single job that's scheduled on it. There is no public interface for this yet, and our few users that use it (for whom this feature was developed) do j._machine_type = '<gcp-machine-type>' to opt into this functionality. This feature is gaining more traction and we should create a proper API for it instead of using a private field. This shouldn't be much code at all, but we should spend a little thought on naming and ensure that it is properly documented and discoverable. There should also be a clear distinction in the documentation on the intended use case of this feature, how it differs from shared pools, and the cost penalty of using it (they pay for the lifetime of the instance not just the job).

Version

0.2.130

Relevant log output

No response

@patrick-schultz patrick-schultz removed the needs-triage A brand new issue that needs triaging. label May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants