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

remote caching support #10960

Merged
merged 9 commits into from
Oct 23, 2020
Merged

remote caching support #10960

merged 9 commits into from
Oct 23, 2020

Conversation

tdyas
Copy link
Contributor

@tdyas tdyas commented Oct 14, 2020

Problem

Pants is currently able to run Process requests remotely or to run and cache them locally. It cannot, however, write local results to a remote cache and also consume a remote cache without remote execution.

Solution

Teach Pants how to read and write from a remote cache without remote execution.

Result

Added tests of remote caching functionality.

@tdyas
Copy link
Contributor Author

tdyas commented Oct 14, 2020

Caveats:

  • Setup in context.rs is now even more convoluted. Moreover, I left the cache checks in the remote execution client because of platform choices differing. (Platform::current versus Platform::Linux). Remote caching mode and remote execution mode should probably be made mutually exclusive.

  • Still working on getting remote_cache_tests::recover_from_missing_store_contents to work. May point at a bug or need to verify all digests are present for a cache result.

@tdyas tdyas changed the title remote caching support [WIP] remote caching support Oct 14, 2020

#[tokio::test]
async fn recover_from_missing_store_contents() {
env_logger::init();
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is here while testing WIP

.unwrap();

// And that the entire output directory can be loaded.
assert!(store
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is failing currently.

@tdyas
Copy link
Contributor Author

tdyas commented Oct 19, 2020

Discussed with @gshuflin: Going to refactor context.rs first in a separate PR to clean up how we setup CommandRunner impl's, then will rebase this PR on top of that refactor.

@Eric-Arellano
Copy link
Contributor

Discussed with @gshuflin: Going to refactor context.rs first in a separate PR to clean up how we setup CommandRunner impl's, then will rebase this PR on top of that refactor.

That'd be really helpful. Thanks!

tdyas pushed a commit that referenced this pull request Oct 20, 2020
### Problem

Core::new is a very convoluted function and it is hard to read what is actually going on in it.

### Solution

Refactor the store and command runner setup into separate functions. (Also refactors the load of some certificates.) This refactor will make the subsequent introduction of remote caching in #10960 easier to comprehend.

### Result

Existing tests pass.
Tom Dyas added 7 commits October 21, 2020 21:38
[ci skip-build-wheels]
[ci skip-build-wheels]
[ci skip-build-wheels]
[ci skip-build-wheels]
[ci skip-build-wheels]
[ci skip-build-wheels]
[ci skip-build-wheels]
@tdyas tdyas changed the title [WIP] remote caching support remote caching support Oct 22, 2020
@tdyas tdyas marked this pull request as ready for review October 22, 2020 04:45
@tdyas
Copy link
Contributor Author

tdyas commented Oct 22, 2020

This is ready for review. I will be adding more tests, but the basic functionality is ready to get reviewed.

@coveralls
Copy link

coveralls commented Oct 22, 2020

Coverage Status

Coverage remained the same at 0.0% when pulling 9a1a2e2 on tdyas:remote_caching_support into 8da1680 on pantsbuild:master.

[ci skip-build-wheels]
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.

Awesome. Has this been used in the wild?

Comment on lines +26 to +30
/// This runner expects to sit between the local cache CommandRunner and the CommandRunner
/// that is actually executing the Process. Thus, the local cache will be checked first,
/// then the remote cache, and then execution (local or remote) as necessary if neither cache
/// has a hit. On the way back out of the stack, the result will be stored remotely and
/// then locally.
Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for the excellent comment! I'm a bit unclear how the execution CommandRunner is different than the local cache CommandRunner? I'm not very familiar with this part of the codebase.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you mean the remote execution command runner (process_execution::remote::CommandRunner) or the remote cache command runner (process_execution::remote_cache::CommandRunner)?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't understand what this sentence means:

This runner expects to sit between the local cache CommandRunner and the CommandRunner that is actually executing the Process.

Copy link
Contributor Author

@tdyas tdyas Oct 22, 2020

Choose a reason for hiding this comment

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

It means that the nested "stack" of command runners looks like this:

cache::ComandRunner -> remote_cache::CommandRunner -> local::ComandRunner

The actual execution of the Process is done by local::CommandRunner (the one on the right). But before it is invoked, we first check the local cache and then check the remote cache. On the way back up the stack, the remote_cache::CommandRunner will take the result of any actual invocation performed by local::ComandRunner and write it to the remote Action Cache.

[ci skip-build-wheels]
@tdyas tdyas merged commit 336ae9a into pantsbuild:master Oct 23, 2020
@tdyas tdyas deleted the remote_caching_support branch October 23, 2020 17:33
gshuflin added a commit that referenced this pull request Oct 31, 2020
Internal-only changes: 

* upgrade to cpython crate v0.5.1 (#11052)
  `PR #11052 <https://github.com/pantsbuild/pants/pull/11052>`_

* Prepare 2.0.0 (#11053)
  `PR #11053 <https://github.com/pantsbuild/pants/pull/11053>`_

* Revert "Add new EngineAware method metadata() (#11030)" (#11047)
  `PR #11030 <https://github.com/pantsbuild/pants/pull/11030>`_
  `PR #11047 <https://github.com/pantsbuild/pants/pull/11047>`_

* Remove deprecated `python_binary` target in favor of `pex_binary` (#11046)
  `PR #11046 <https://github.com/pantsbuild/pants/pull/11046>`_

* Prepare 2.0.0rc3 (#11044)
  `PR #11044 <https://github.com/pantsbuild/pants/pull/11044>`_

* Eagerly validate entry points for `setup_py().with_binaries()` (#11034)
  `PR #11034 <https://github.com/pantsbuild/pants/pull/11034>`_
  `PR #11021 <https://github.com/pantsbuild/pants/pull/11021>`_

* Use Ubuntu Bionic for CI (#11027)
  `PR #11027 <https://github.com/pantsbuild/pants/pull/11027>`_

* Prepare 2.0.0rc2 (#11017)
  `PR #11017 <https://github.com/pantsbuild/pants/pull/11017>`_

* Remove RunTrackerLogger (#11018)
  `PR #11018 <https://github.com/pantsbuild/pants/pull/11018>`_

* Upgrade Pex to 2.1.20 (#11014)
  `PR #11014 <https://github.com/pantsbuild/pants/pull/11014>`_

* Remove more unused code from RunTracker (#11012)
  `PR #11012 <https://github.com/pantsbuild/pants/pull/11012>`_

* Add type annotations to AggregatedTimings (#11009)
  `PR #11009 <https://github.com/pantsbuild/pants/pull/11009>`_

* Increase default `[python-setup].resolver_jobs` to `cpu_count / 2` (#11006)
  `PR #11006 <https://github.com/pantsbuild/pants/pull/11006>`_

* Include `<PYENV>` in `[python-setup].interpreter_search_paths` default (#10998)
  `PR #10998 <https://github.com/pantsbuild/pants/pull/10998>`_

* Remove PantsDaemonStats class wrapper (#11003)
  `PR #11003 <https://github.com/pantsbuild/pants/pull/11003>`_
  `PR #files#r508861045 <https://github.com/pantsbuild/pants/pull/11000/files#r508861045>`_

* Revert using libCST for dep inference due to performance (#10907) (#11001)
  `PR #10907 <https://github.com/pantsbuild/pants/pull/10907>`_
  `PR #11001 <https://github.com/pantsbuild/pants/pull/11001>`_


* Run tracker refactor (#11000)
  `PR #11000 <https://github.com/pantsbuild/pants/pull/11000>`_

* refactor Core::new including command runner setup (#10993)
  `PR #10993 <https://github.com/pantsbuild/pants/pull/10993>`_
  `PR #10960 <https://github.com/pantsbuild/pants/pull/10960>`_

* Allow changing the versioning scheme for `python_distribution` first-party dependencies (#10977)
  `PR #10977 <https://github.com/pantsbuild/pants/pull/10977>`_

* Remove tokio Handle type from Executor::new (#10980)
  `PR #10980 <https://github.com/pantsbuild/pants/pull/10980>`_

* Remove deprecated `Address.parse()` and `Address.reference()` (#10981)
  `PR #10981 <https://github.com/pantsbuild/pants/pull/10981>`_

* Remove project_ methods from the externs module (#10955)
  `PR #10955 <https://github.com/pantsbuild/pants/pull/10955>`_

* Prepare 2.0.0rc1 (#10972)
  `PR #10972 <https://github.com/pantsbuild/pants/pull/10972>`_

* Fix interpreter selection when building a PEX to use `[python-setup].interpreter_search_paths` (#10965)
  `PR #10965 <https://github.com/pantsbuild/pants/pull/10965>`_

* Delete `JsonReporter` (#10964)
  `PR #10964 <https://github.com/pantsbuild/pants/pull/10964>`_

* Fix log (#10959)
  `PR #10959 <https://github.com/pantsbuild/pants/pull/10959>`_

* Expose getattr method for Python-related APIs (#10953)
  `PR #10953 <https://github.com/pantsbuild/pants/pull/10953>`_

* Upgrade tokio package to 0.2.22 (#10949)
  `PR #10949 <https://github.com/pantsbuild/pants/pull/10949>`_

* Use `package` to build Pants's wheels, rather than `setup-py` (#10947)
  `PR #10947 <https://github.com/pantsbuild/pants/pull/10947>`_

* Simplify val_to_str and have it and val_to_log_level use PyObject (#10946)
  `PR #10946 <https://github.com/pantsbuild/pants/pull/10946>`_
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.

4 participants