Provide OutputService and InjectionListener implementation

[werkt]

Description of the problem / feature request:

Implement the output service consistent with the execution strategy module, and re-release the ActionFileSystem to satisfy its requirements.

Feature requests: what underlying problem are you trying to solve with this feature?

The integration of OutputService, an ActionFileSystem (now redacted), and InjectionListeners are non-public, with their intended connectivity unclear. In trying to improve the behavior of the remote caching/execution client, these interfaces serve a clear purpose, but a registration system or example for these is missing.

What operating system are you running Bazel on?

Ubuntu 18.04

What's the output of bazel info release?

0.15.0

Have you found anything relevant by searching the web?

A revert of e35e8cf is a start here, but there is similarly nothing documented publicly regarding the implementation of skyframe's interaction with the output service or created filesystem (since there is no output service implementation today).

Any other information, logs, or outputs that you want to share?

This issue is to document a request by myself after discussing the nature of this work with @janakdr and shahan. While I have implemented the connections between the relevant actors, I expect that any implementation of a listener or filesystem metadata registration will clash with internals and be unlikely to be accepted without being a pure specialization of a smaller scoped improvement which interacted with internally defined registrars.

[werkt]

A perfectly acceptable first step here would be to follow through on comments in code, compelling skyframe to only interact with OutputService and its created FileSystem for all operations.

[lfpino]

Assigning to @janakdr for triage.

[ulfjack]

There's also #1922.

[ulfjack]

If you have an implementation of this, how about sharing it? We may have two or three parties interested in implementing changes to avoid downloading intermediate files.

[werkt]

https://github.com/werkt/bazel/tree/remote-action-file-system My implementation is awkward for integration, doesn't properly scope out all of the OutputService behaviors, and does not cause artifacts to be downloaded yet for critical/local execution, but it does manage to execute for fully remote executions without downloading anything

…

On Fri, Jul 20, 2018 at 9:14 AM, Ulf Adams ***@***.***> wrote: If you have an implementation of this, how about sharing it? We may have two or three parties interested in implementing changes to avoid downloading intermediate files. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5505 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABTltpg2gSaF-JQ2wzBMwKn1Zd2gMAaks5uIdfDgaJpZM4U-kdB> .

[werkt]

I have prepared a design doc for this implementation, and will be sharing this with the bazel mailing lists. After discussions with @buchgr who also spoke with @janakdr, I am anxiously awaiting the reopening of the ActionFileSystem implementation, and am moving forward.

https://docs.google.com/document/d/1FDPMQd70fA5tM9JkWeT9tWKACGZgHXdXTVz8Jel1OZg/edit?usp=sharing

[buchgr]

Hi George, sorry for the delay with open sourcing ActionFS. I ll be back in the office tomorrow.

[buchgr]

Closing this in favor of #6862