Hi All,
On Wed, 2018-10-31 at 13:01 +0000, Sander Striker via BuildStream-list
wrote:
> Hi,
>
> On Tue, Oct 23, 2018 at 7:34 PM Benjamin Schubert via BuildStream-
> list <buildstream-list gnome org> wrote:
> > Hey everyone,
[...]
> There is one other question to consider: should the alternative
> sandbox support be added to BuildBox instead, and by extension be
> usable. The question of cache keys then goes away.
Looks like you beat me to it :)
:)
There are some points which make the Sandbox, the CAS, and the fuse
layer tightly coupled, and I worry that implementing a whole separate
sandbox implementation will imply re-implementing some of these details
over time.
If the goal here is to have the capability of doing cross platform
development without remote execution (or alternatively, with remote
execution but without workers which run on the target execution
environment natively), and if Docker can help to achieve this, then I
think this should probably be implemented as a detail of BuildBox.
This will probably be complicated to implement whether it is in
BuildStream or BuildBox, but at least in BuildBox it is closer to other
related sandboxing details, and so presumably more manageable and
easier to ensure correctness across execution environments.
I think you're overestimating the complexity to be quite honest. I would be
interested an PoC implementation to see what it would look like.
As an added thought, there is yet another approach:
* Spin up a remote worker locally, inside a docker container
* Use remote execution to communicate with the locally running
remote worker, with BuildBox, inside a docker container
Not entirely sure if that setup works by itself, but if it does then
perhaps there is a way to make that setup convenient, or automated.
That isn't necessarily as easy as it sounds.
Cheers,
-Tristan
Cheers,
Sander
