ADR #8: Container image expansion #3
Conversation
|
|
||
| Assuming that the container image files and the client provided inputs are generally located in different directories, most of the Merkle tree merging will happen close to the root level and therefore not consume much resources. Merging the layers will go deeper in the structures, so a local AC and Merkle tree cache (CAS) is probably necessary. | ||
|
|
||
| # Other considered solutions |
There was a problem hiding this comment.
I think there are a couple of other options we should consider/document:
- Making Bazel itself responsible for emitting actions that have the right shape.
- There is the ActionRouter API in bb-scheduler, which can already be used to do rudimentary matching/rewriting of platform properties. Maybe that subsystem could be extend to also be able to interpret
container-imageand rewrite the action before it's submitted to the worker?
There was a problem hiding this comment.
Regarding Bazel, that would probably be the "correct" place to put it. Then Bazel itself could use the information when running locally. Maybe specifying a root_directory label in toolchains and/or platforms would be the solution. The problem is that the way Bazel put outputs would make it very impractical to specify a root tree. In practice, the only kind of root file system I can see is a container image. Referencing a container image built with Bazel would be something but I haven't looked into rules_docker yet.
Anyway, other remote executors supports the container-image platform property out of the box, so the feature might still be valuable within Buildbarn.
Am I missing something? I feel that a Buildbarn implementation would be easier than adding it to Bazel but I feel that I cannot find a good enough argument for not putting it in Bazel (more than too much effort).
There was a problem hiding this comment.
The problem with ActionRouter is that it only extracts the keys, my plan was to rewrite the action, or at least the input root of it. Now, the action is already rewritten before sent over to the executor, actionWithCustomTimeout. Shall the ActionRouter be taught to return the actual_input_root_digest as well?
There was a problem hiding this comment.
Maybe we should just reach out to the Bazel folks and ask them what their vision is on this. If they are interested in solving this inside Bazel, then we should help them out. If they despise the idea, we could support it on our end.
With regards to ActionRouter: indeed! We should let that return a new input root digest.
moroten
force-pushed
the
container-image-expansion
branch
from
71e3058 to
d324740
Compare
No description provided.