Re: [BuildStream] Proposal: Add 'remote-execution' project configuration

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

Hi,

On Fri, 2018-08-17 at 12:46 +0100, Jim MacArthur via BuildStream-list wrote:
> I'd like to add an option to the project and element YAML spec to 
> control remote execution. In the code, the remote execution part of 
> BuildStream takes the form of a third sandbox, but I don't think it 
> makes sense for the user to consider remote execution as a type of 
> sandbox. Hence, I think this needs a new top-level label. If anyone 
> thinks it'd fit into an existing top-level label I'd be happy to change 
> it. Does this look like a reasonable approach?

Sort of.

So to clarify some things; the project.conf is mostly project data,
which usually defines how a project is built, and essentially what is
built.

The build server one might use to optimize builds clearly does not fall
into this category; as such it should naturally be considered user
configuration, not project data.

*However*, I should emphasize that I said "usually" above; we have bent
the rules a bit here for the sake of the artifact sharing functionality
to be more practical.

I think it makes sense here to follow the same pattern we use to define
the artifact share servers:

  * A project.conf can specify the server, so that people working on
    the project don't have to configure it themselves - this is really
    only for the sake of convenience.

  * The user must always have the final say in their config file.


When we start talking about the specific machine architecture and
binary format that we need from a worker, this kind of configuration
needs to be available at the element and project level (e.g., one might
want to cross-bootstrap on x86, and then consume that output to build
linux on arm).

Just raising this second part because; while it seems related, it's
important to keep these concepts clearly separated. If a project has
requirements for specific machine architecture, that is completely
orthogonal to how we go and carry out the build - however it *will*
impose some restrictions on what abstract sandbox a project will be
able to choose.

To answer some of Ed's questions:

  * No, the project.conf is not considered in it's entirety in cache,
    key calculation; cache key calculation is selective; so for
    instance: If you change a variable in your project.conf, it will
    only effect the cache keys of elements which use that variable
    and cause their build commands to have changed as a result.

  * The user config does not effect cache key calculation under any
    circumstances.


As for the granularity of configuration raised in Ed's reply, I am
fairly ambivalent about this; I would recommend that we have a way to
configure with only a single URL, but also allow finer granularity if
that makes sense for the technical implementation.


Cheers,
    -Tristan