Re: [BuildStream] Introduce a docker sandbox

[Benjamin Schubert <ben c schubert gmail com>]

Hi all,

I finally managed to get a docker sandbox POC working; You can find the required work at https://gitlab.com/BuildStream/buildstream/tree/bschubert/docker-sandbox. It is still lacking features, that are shown by TODO comments.

This has been tested with running BuildStream on WSL, using native Windows' docker.

My question now is, do we want to develop this further? If so, how?

I also added a few comments inline to answer previous messages.

On Wed, Oct 31, 2018 at 5:55 PM Richard Maw via BuildStream-list <buildstream-list gnome org> wrote:

On Tue, Oct 23, 2018 at 06:34:32PM +0100, Benjamin Schubert via BuildStream-list wrote:
> - How that would be implemented ?
>
> The aim is to have a second sandbox implementation, using docker that
> would behave similarily to the current bwrap sandbox.
> We would introduce a "sandbox" parameter in the buildstream.conf user
> configuration that would default to "brwap" on linux and to "docker"
> on any other OS.

My recollection of discussions I was present to
suggested that it would be branded as something OCI-compatible
and stick to the subset of Docker that has been standardised in OCI
rather than explicitly Docker.

That seems hard to do, if not impossible, since OCI only defines a file format and the rest depends on the runtimes (docker, podman, machinectl, ...). However, with a good base class and documentation it would be easy-ish to support more of those.

Other than that it sounds like a good thing to have.

> - Questions to answer:
>
> - How would we handle cache keys? Would docker and brwap sandbox
> considered equivalent and the cache keys match? Do we want a cache key
> per sandbox?
>   - We think a single cache key would be enough, if, and only if, we
> consider brwap and docker sandboxes "equal" in term of features.
>     There is a precedent for that: remote execution uses the same keys
> than the local ones.

I think bwrap and remote execution get away with it from the assumption
that the remote end is going to be using the same technology.

If we are making this assumption then it's going to require
that the remote execution protocol can report its sandbox backend.

I think Docker's containment capabilities should be a superset of bubblewrap's,
though things might get interesting when it comes to user namespaces
and the copy-on-write overlay may be less capable and stat differently,
so we ought to be able to consider their artifacts equivalent.

I haven't dig more into this for now and don't think I know enough about the artifact caching to be sure. Would someone want to double check/ help me double check this?

If you find difficulties making the sandboxes behave equivalently
we can re-visit whether they should cache to the same keys.

Cheers!

Benjamin

_______________________________________________
BuildStream-list mailing list
BuildStream-list gnome org
https://mail.gnome.org/mailman/listinfo/buildstream-list