Add configs for readonly and writeonly proxies.

[uri-canva]

Implements #69.

[uri-canva]

This is configured via separate disable_reads and disable_writes fields in the yaml so that the default values match the current behavior of having both enabled. I could have used an enum as well but I didn't want to complicate the yaml parsing code, it might be worth it?

In the code it's represented as a Mode enum because that way the invalid configuration of disabling both cannot be represented at the type level.

Happy to change the config to be a mode enum in yaml as well if that is preferable.

[bayareabear]

maybe 'accessMode'?

[bayareabear]

adding spaces: r.mode & Write?

[uri-canva]

gofmt formats this without spaces.

[bayareabear]

just curious, what is the use case for disable_reads?

[uri-canva]

Write through from a cache that is less likely to get poisoned to one that is more likely to, and being able to shared cached artefacts without blocking any builds.

For example if your CI cache is in a data center and your developer cache is in the office, the link between them might not be as fast as the link between developers and the developer cache. In that case waiting to download the artefact from the data center cache might be generally slower than building locally. But if you set up write through the data center cache can slowly send artefacts to the developer cache without blocking any builds.

[bayareabear]

Thanks! If the network is slow and is blocking the Dev box's build, understood we want to disable read. However, we may also want to disable write too as we may not want upload cache from Dev box? In this case 'disable_reads' and 'disable_writes' should be used at the same time, no?

[uri-canva]

Developer machine <===> developer cache <---> CI cache
                    ^                     ^
            fast connection        slow connection

Developer machines can quickly read and write to developer cache, developer cache can slowly write to CI cache without blocking developers because uploads are asynchronous, but it cannot slowly read from CI cache without blocking developers because downloads are synchronous.

[ob]

One thing that trips me is the negated logic of disable_reads: true, I tend to prefer reads_enabled: true. But I'll let @buchgr's opinion there trump mine. The code looks fine to me.

[uri-canva]

ping @buchgr

[ob]

@buchgr is OOO until Feb 25

[uri-canva]

ping @buchgr

[uri-canva]

ping @buchgr

[brentleyjones]

We could really use this feature.

@uri-canva would you reopen this if @buchgr would accept it?

How about it @buchgr 🙏?

[uri-canva]

We're not using this patch anymore ourselves, as it didn't fit our purpose as well as I thought, you're welcome to base a new PR on it though.

[mostynb]

Since there are a few interrelated issues/PRs on this topic, I want to make sure that I understand the use case...

Is this the scenario:

• There's a central CI system with its own cache. This is trustworthy because the CI setup is locked down.
• There is a developer-local cache, which is more easily poisoned.
• The link between the central and developer-local cache is slow enough that you don't want synchronous lookups between them.
• You want the central cache to asynchronously populate the developer-local cache, but not to read from it.
• (Not sure if this was requested, but do you potentially want multiple developer-local caches to work like this, with a single central cache?)

[brentleyjones]

I’ll let @uri-canva answer for their situation, but for us it is much simpler, we only really need the writes_disabled setting:

• Central CI cache. Written to by CI, since it’s trusted to not poison it.
• Local developer cache on each machine. Used since disk_cache doesn’t clean up, and implementing naive cleanup in a non-AC aware way breaks Builds without the Bytes.
• Local developer cache points it’s proxy to CI cache with writes_disabled to get remote cache benefits without possibility of poisoning it.

Essentially, if disk_cache could set a size limit and clean up in an LRU way, we wouldn’t need this solution at all. This allows bazel-remote to fill that purpose instead.

[uri-canva]

Disregard the note around disable_reads above, we have it set up differently now because it wasn't working that well anyway. We were using disable_writes exactly the same way as @brentleyjones: to use bazel-remote as a local disk cache, given the discussion in bazelbuild/bazel#5139.

Essentially, if disk_cache could set a size limit and clean up in an LRU way, we wouldn’t need this solution at all. This allows bazel-remote to fill that purpose instead.

We use it to fall back to reading from a remote cache too, which Bazel doesn't do.