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
add "workspace" process execution strategy #20772
add "workspace" process execution strategy #20772
Conversation
c6fd8d3
to
beb5516
Compare
src/rust/engine/src/context.rs
Outdated
@@ -219,6 +220,22 @@ impl Core { | |||
exec_strategy_opts.local_keep_sandboxes, | |||
); | |||
|
|||
// TODO: Wrap this in a BoundedCommandRunner so only run process can execute in the workspace at once. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thoughts on using BoundedCommandRunner
to enforce this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are the sandboxes uniquely named such that they wouldn't collide?
For cases where we are invoking an existing build tool, we'd expect them to do the right thing with regard to locking so that they could safely run concurrently. But I wonder whether it would make it challenging to write correct end users scripts to have concurrency.
It sounds like mutability of declared outputs is hidden, because those go into the sandbox? So only undeclared outputs that didn't go into temporary directories would be a problem. And that is easy to fix... but definitely need to be documented.
I think it's fine to ship without limiting to 1... in future could add a concurrency limit as a workspace option perhaps?
51c55a4
to
b911f9d
Compare
Did some refactoring and added tests. This should be ready for review now. |
d093168
to
54aceee
Compare
797ee54
to
c9ca3fa
Compare
c9ca3fa
to
b35e034
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! Thanks @tdyas : sorry for the long delayed review.
src/rust/engine/src/context.rs
Outdated
@@ -219,6 +220,22 @@ impl Core { | |||
exec_strategy_opts.local_keep_sandboxes, | |||
); | |||
|
|||
// TODO: Wrap this in a BoundedCommandRunner so only run process can execute in the workspace at once. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are the sandboxes uniquely named such that they wouldn't collide?
For cases where we are invoking an existing build tool, we'd expect them to do the right thing with regard to locking so that they could safely run concurrently. But I wonder whether it would make it challenging to write correct end users scripts to have concurrency.
It sounds like mutability of declared outputs is hidden, because those go into the sandbox? So only undeclared outputs that didn't go into temporary directories would be a problem. And that is easy to fix... but definitely need to be documented.
I think it's fine to ship without limiting to 1... in future could add a concurrency limit as a workspace option perhaps?
@@ -29,17 +29,22 @@ impl PyProcessExecutionEnvironment { | |||
platform: String, | |||
remote_execution: bool, | |||
remote_execution_extra_platform_properties: Vec<(String, String)>, | |||
execute_in_workspace: bool, | |||
environment_name: Option<String>, | |||
docker_image: Option<String>, | |||
) -> PyResult<Self> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oy. Need support for ADTs at this boundary. Oh well!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oy. Need support for ADTs at this boundary. Oh well!
What's the preferred way to do that? A Python class per enum variant with them all in a Union
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I will explore such a refactor after this PR has landed.
Yes, the code makes use of the same temporary directory support has the ordinary local executor and so makes uniquely-named temporary directories for the sandbox directories. |
Agreed. Seems too early to fix without affirmative proof it is a problem. And it can be a config option in the future. I'll update the comment accordingly. |
@stuhood: What do you mean by "mutability of declared outputs is hidden"? |
86a6371
to
5a58a79
Compare
85db027
to
6c72fc9
Compare
# Reserved sentinel value representing execution within the workspace and not local sandbox. | ||
LOCAL_WORKSPACE_ENV_NAME = "__local_workspace__" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sentinel value was added so tests in this PR could make use of the workspace process execution strategy even without the next PR in the series (which adds the workspace_environment
type). That next PR in the series will remove this particular use and rename it.
Maybe it should be renamed so the support in this PR is not in the public API (in case the next PR is delayed in landing)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @benjyw
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefixed the symbol with underscore to make it clear that the symbol is not public API, and added a comment to that effect.
6c72fc9
to
212167f
Compare
212167f
to
58fc224
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LG, thanks for pairing on this!
Add a "workspace" process execution strategy and a
process_execution::workspace::ComandRunner
to execute processes in the workspace instead of the ordinary "local" execution sandbox.This implements the Rust parts of Design B from the "In-Workspace Process Execution" design document which will add support to Pants for "workspace environments."
This PR supersedes #20740 since the approach of using the existing
Process
capture workflow fits better with the existing system design.