Skip to content

Commit

Permalink
Remote Output Service: Mention read-only output paths (#223)
Browse files Browse the repository at this point in the history
@alexjski made a fair point on the mailing list thread last week that it
may make sense to make the output path completely read-only. I agree,
though it would break unsandboxed actions.

For now, let's stick to keeping the output path writable, but at least
add a section to the proposal on what needs to be done to make it
read-only in the future.
  • Loading branch information
EdSchouten authored Apr 29, 2021
1 parent 84e1702 commit a0b33b9
Showing 1 changed file with 28 additions and 1 deletion.
29 changes: 28 additions & 1 deletion designs/2021-02-09-remote-output-service.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
created: 2021-02-10
last updated: 2021-02-10
last updated: 2021-04-28
status: To be reviewed
reviewers:
- coeuvre
Expand Down Expand Up @@ -225,3 +225,30 @@ The goal is to implement this feature in such a way that local
execution, plain remote execution, remote execution with
`--remote_download_minimal`, the use of a local disk cache, etc. all
remain functional.

# Future work

The initial goal of this proposal is to let the Remote Output Service
offer a file system to Bazel that is fully writable, but simply
augmented to support the creation of lazy-loading files. In the future
it may be of interest to allow this file system to be read-only,
requiring all changes to be made by Bazel through gRPC. This reduces the
need for tracking changes in the file system, or scanning the file
system when doing incremental builds. The following things will need to
be kept in mind when implementing this:

- Not all changes to Bazel's output directory are made through the
RemoteOutputService interface. Additioning wrapping of FileSystem will
need to be performed to prevent Bazel from making direct writes.
- Making the output path read-only makes it impossible to run actions
with sandboxing disabled. This may be acceptable for many users,
though.

Such a change could be decomposed into two separate parts:

1. Adding a gRPC method that Bazel can use to write files into the file
system, as opposed to writing files directly. The protocol as
currently defined only allows the creation of files that are backed
by a remote CAS.
2. Extending StartBuild() to allow Bazel to request the creation of a
read-only output directory.

0 comments on commit a0b33b9

Please sign in to comment.