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

Local caching CommandRunner has default-on flag #8040

Conversation

illicitonion
Copy link
Contributor

No description provided.

Copy link
Member

@stuhood stuhood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Copy link
Contributor

@Eric-Arellano Eric-Arellano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Woohoo!

@stuhood stuhood force-pushed the dwagnerhall/local-process-execution-cache/wireup branch from ebb33bc to 8904ae4 Compare July 12, 2019 02:27
@stuhood
Copy link
Member

stuhood commented Jul 12, 2019

Hm, the panic on the OSX bootstrap shard repros after a rebase.

@stuhood
Copy link
Member

stuhood commented Jul 12, 2019

Pushed an edit which exposed the issue. Looks like we need to increase the file handle count on the OSX bootstrap shard. It looks like we only do on the test shard(s).

subprocess.run(["./pants", "binary", "src/python/pants/bin:pants_local_binary"], check=True)
env = dict(os.environ)
env['RUST_BACKTRACE'] = "1"
subprocess.run(["./pants", "binary", "src/python/pants/bin:pants_local_binary"], check=True, env=env)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw, cool Py3 only idiom to do this:

...check=True, env={**os.environ, 'RUST_BACKTRACE': '1'})

stuhood pushed a commit that referenced this pull request Jul 12, 2019
This will allow local process execution to be cached across runs once #8040 lands.

See #8041 for discussion of keeping its size down.
@illicitonion illicitonion force-pushed the dwagnerhall/local-process-execution-cache/wireup branch from 1b14726 to a0fe0b8 Compare July 15, 2019 21:58
@illicitonion illicitonion force-pushed the dwagnerhall/local-process-execution-cache/wireup branch from a0fe0b8 to 02d0179 Compare July 18, 2019 00:33
Copy link
Contributor

@blorente blorente left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is cool, thanks! The comments are all nits, feel free to ignore them.

@@ -435,6 +438,8 @@ def register_bootstrap_options(cls, register):
'and fall back to the local host if remote calls take longer than the speculation timeout.\n'
'`none`: Do not speculate about long running processes.',
advanced=True)
register('--process-execution-use-local-cache', type=bool, default=True, advanced=True,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see us having more --process-execution-prefixed flags. It would maybe be worth adding a TODO like:

Suggested change
register('--process-execution-use-local-cache', type=bool, default=True, advanced=True,
# TODO Make a subsystem to namespace `--process-execution`-prefixed flags.
register('--process-execution-use-local-cache', type=bool, default=True, advanced=True,

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I don't think it's relevant here, but passing daemon=True will make this option invalidate the daemon, in case that's something we want to do.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have this TODO further up in this file. But currently it's not possible to have a "bootstrap" subsystem.

Also, I don't think it's relevant here, but passing daemon=True will make this option invalidate the daemon, in case that's something we want to do.

daemon=True is the default.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We currently need this to be daemon=True (the default) because we statically create CommandRunners early in the daemon lifecycle, and have no way to re-create them, or pass their config around dynamically. We may want to change that at some point :) (cc @hrfuller)

if process_execution_use_local_cache {
let process_execution_store = ShardedLmdb::new(
local_store_dir2.join("processes"),
5 * 1024 * 1024 * 1024,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: name this magical number.

cache_key_gen_version: remote_execution_process_cache_namespace.clone(),
platform_properties: remote_execution_extra_platform_properties.clone(),
};

let mut command_runner: Box<dyn process_execution::CommandRunner> =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not have an if/else here, instead of creating the mutable variable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think my instinct here is because this is more clear in the face of multiple wrappers:

let mut val = foo;
if wrap {
  val = do_wrap(val);
}
if wrap_in_other {
  val = do_other_wrap(val);
}

but I don't have a strong preference either way, if you do.

Copy link
Member

@hrfuller hrfuller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool! LGTM.

@illicitonion illicitonion merged commit 4435b8e into pantsbuild:master Jul 19, 2019
@illicitonion illicitonion deleted the dwagnerhall/local-process-execution-cache/wireup branch July 19, 2019 00:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants