Re: [BuildStream] BuildGrid and BuildStream 1.4 and API concerns

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

Hi,

On Sun, 2018-12-02 at 12:26 +0100, Jürg Billeter wrote:
[...]
> While there is a risk that incompatible tweaks will still be applied to
> REAPI v2, the upstream goal is that this won't happen anymore (until
> REAPI v3). And I hope OS and machine architecture values can be
> standardized by end of Q1/2019, well in time for BuildStream 1.6.

This is good news.

[...]
> For OS and machine architecture requirements it's clear that we can't
> expect all remote execution deployments to support all values. I.e.,
> BuildStream needs to be able to report an understandable error if the
> platform requirements of the project can't be met. This generally also
> applies to local builds (e.g. if user namespaces are not available).
>
> In my opinion, it would make sense to follow the same approach also for
> other execution environment requirements such as file attributes. I.e.,
> specify the requirements as REAPI platform properties and the execution
> service will return a FAILED_PRECONDITION error if the server/workers
> can't fulfill the requirements.
>
> While this obviously would still require server side upgrades for
> projects that have these additional platform/sandbox requirements, I
> think we can implement it in such a way that projects that don't need
> these features will still work with existing remote execution servers.
>
> E.g. in the case of multi-UID support I also expect that additional
> host features will be required for local builds (subuid support) and
> thus, this feature should anyway be opt-in.
>
> This approach should work for arbitrary future requirements even with
> existing remote execution servers. BuildGrid currently ignores the
> requirements specified in the Platform message but this is a bug¹ and
> hopefully fixed soon.

> From what I've understood so far, as far as requirements for remote
worker capabilities, there is a standardized API for requiring and
satisfying these arbitrary requirements, but also a desire for
standardizing the names of such capability requirements; which makes
sense for the sake of interoperability of services moving forward.

Standardizing on these capability names and values will inevitably mean
revisioning the specification I think.

My understanding is that on this front, we have a policy and strategy
in place to allow us to require capabilities in advance of these being
a part of the spec, where "arbitrary requirements" become well known
requirements, is this still true ?

This seems desirable as it allows us at least some leeway and
flexibility within what the spec defines.

> In conclusion, I think it may make sense to document remote execution
> as experimental for BuildStream 1.4 but the plan would definitely be
> for this to be temporary. I.e., I'd expect remote execution to be fully
> stable by BuildStream 1.6 and interoperable with other servers such as
> RBE.

This is a much more friendly statement than a message of indefinite
instability without any timeline.

Also, as usage of remote execution needs to be explicitly opt-in anyway
(by simple virtue of having to specify a service URL), I don't think
there is any need for any additional flags or settings to enable or
disable the feature, and as you put it "document remote execution as
experimental" seems sufficient.

It is a new feature, and should not have negative impact on users which
are not even using it.

That said, for the same documentation purposes; it would be good to
have a set of instructions in the documentation on how to try it out,
so people can test and contribute to the new feature - at the very
least it would be good to have a git tag from the BuildGrid repository
which we can use in documentation, for those who want to "setup and try
out BuildGrid" with 1.4.

Does this sound sensible ?

Cheers,
    -Tristan