Self-hosting CAS for Swarming test infrastructure

[Quang Hai]

Hi,

I’m trying to set up a local / self-hosted Swarming test infrastructure for development and experimentation.

Currently, I’m looking for a way to deploy a CAS (Content Addressable Storage) service that is compatible with LUCI / Swarming.

From the Chromium infra repositories, the only thing I can find is:

• luci-go/fakecas

However, fakecas seems to be intended purely for unit / integration testing and is too minimal for running a realistic Swarming setup (e.g. limited configurability, not suitable as a long-running service).

What I’m trying to achieve:

• A CAS server that can be self-hosted (local or on-prem)
• Compatible with Swarming bots
• Configurable enough to simulate real CAS behavior for infra testing

My questions are:

1. Is there any officially supported or recommended way to self-host a CAS service for Swarming?
2. If not, what do Chromium infra developers usually do when they need a realistic CAS setup for testing (besides fakecas)?
3. Is the expectation that CAS is always backed by RBE / GCP infrastructure, and local setups are intentionally unsupported?

I want to make sure I’m not missing an existing tool or recommended approach before trying to build or adapt one myself.

Thanks in advance.

[Junji Watanabe]

Hi Quang, 

What do you mean by "a CAS (Content Addressable Storage) service that is compatible with LUCI / Swarming."? 

Are you already self-hosting LUCI/Swarming infrastructure for your CI? If so, you can technically host your CAS service that implements the ContentAddressableStorage RPCs. However, we have never tested using non-RBE CAS for Swarming CAS. So, I'm not sure if it just works (maybe not).

For the references, you can find some open source implementations of RBE servers here. You may re-use the CAS part of them.

https://github.com/bazelbuild/remote-apis/tree/main?tab=readme-ov-file#servers

I hope it answers your questions.

Thanks,

Junji

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/f0e79a16-072f-42a8-ab51-5d500220c62an%40chromium.org.

[Quang Hai]

Thanks for the information you shared earlier, that helps clarify the intended direction.

I’d like to add a bit more context on what I’m currently doing. I found the fake CAS implementation here:
https://github.com/bazelbuild/remote-apis-sdks/blob/master/go/pkg/fakes/server.go
 
At the moment, I’m trying to work around this implementation as a starting point.
It is able to interact with a Swarming test server and works for basic end-to-end experiments.
 
However, as expected, it has several limitations compared to a real CAS server (e.g. behavior completeness, scalability, long-running usage, configurability).My goal is not to replace production CAS, but to understand whether this approach (building on top of existing fake CAS implementations) aligns with how Chromium infra developers usually experiment with or test Swarming-related infrastructure.
 
Thanks again for the insights you’ve provided