You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: