Re: [BuildStream] BuildBox transitioning

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

Hi,

Thanks for the exciting writeup :)

On Mon, 2019-05-20 at 11:56 +0100, William Salmon via buildstream-list
wrote:
> Fellow BuildStreamers
>
> We have talked about using the BuildBox sandbox as BuildStream's
> local sandbox in the past.
>
> I believe the consensus was that we would remove all other sandboxes
> and just have the Dummy, Remote and BuildBox sandboxes.
>
> Juerg created https://gitlab.com/BuildStream/buildstream/merge_reques
> ts/951 6 months ago and I have now re-based and started updating it.
> I have a branch that now passes the tests locally and I have a new
> test stage that passes CI.
>
> Having spoken to some members of our community I believe that rather
> than removing all the old sandboxes and adding the new one in one go,
> we should aim to do this over a number of MRs, but make sure that all
> are landed before bst2.0.
[...]
> If this plan is acceptable I imagine the first MR would cover:
> ==============================================================
>
> * The first implementation of the new sandbox.
>
> * Report nice errors rather than bugs for those trying out the new
> sandbox, if they use parts that are not finished, for example: 
>   - warning due to limited bst shell support 
>   - error for element plugins that don't support the virtual
> directory API 
>   - error for elements requiring non-0 UID/GID 
>   - error when BuildBox is not available. 

Can we get an explanation of what is meant by "limited" support for
launching shells in BuildBox, and any idea of when this will be fixed ?

Also, I guess that mapping the UID/GID is trivial enough, is this on
the roadmap for BuildBox ?

Seeing as BuildBox seems not to be ready for showtime, I would agree
that it is important to have this temporarily optional.


> * The BuildBox sandbox should only be used if explicitly enabled. I
> will implement this option with the existing option code paths as
> much as possible. Eg, environment Var, maybe also user settings file
> and CLI if they prove to be easy to add, I do not see this as a
> project level setting.
>   - We currently have BST_FORCE_BACKEND, I will add BST_FORCE_SANDBOX
> etc.

Originally when we added BST_FORCE_BACKEND to test the unix generic
backend on linux, both the artifact cache and the sandbox needed to be
implemented separately.

If I'm not mistaken ever since we implemented CAS, the only thing that
is conditional with BST_FORCE_BACKEND is the sandbox now - seeing as
this is also a new sandbox, I think it would be redundant to have two
separate environment variables here - we can probably just drop
BST_FORCE_BACKEND in favor of BST_FORCE_SANDBOX and have that support
all three sandboxes (bwrap, chroot and buildbox).


As a side note: Please remember that environment variables are not a
part of the API at all, we use them for testing purposes but we do not
consider env vars as API surface.

That said, I think that an env var is a perfect fit for something that
is going to be a temporary measure while we mature the integration of
BuildBox and transition to it.


[...]
> Note: AFAIK, currently BuildBox is not packaged for any OS. So a step
> towards getting to the point where we can remove the old sandboxes
> may be updating the install procedure for BuildStream master to
> include BuildBox.

Before we decided to break API and create a new BuildStream 2, this was
the main blocker Jürg and I had discussed to transitioning to BuildBox.

Now that we are working on BuildStream 2, I don't think this is a
blocker to dropping our current sandboxes in favor of BuildBox anymore,
and I think it would be preferable to drop at least the bwrap sandbox
as soon as possible in BuildStream 2.

Ideally we should drop both chroot and bwrap backends, it would be
better to focus platform support in one place in BuildBox rather than
having multiple implementations in BuildStream.

As for installation instructions, it can make sense to include those in
BuildStream 2 docs for now.

Once BuildStream 2 is ready for a 2.0 release, I expect that packaging
of BuildBox at that time will not cause any friction and will be done
anyway as a side effect of BuildStream 2 hard depending on it (so I
don't suspect that instructions on compiling and installing BuildBox to
be necessary for end users at release time).

Cheers,
    -Tristan