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

[Finn Ball <finn ball codethink co uk>]

Hi,

On 26/11/2018 13:27, Tristan Van Berkom via BuildStream-list wrote:
> Hi Jürg,
>
> Thanks for replying here...
>
> On Mon, 2018-11-26 at 10:23 +0100, Jürg Billeter wrote:
> > Hi Tristan,
> >
> > On Mon, 2018-11-26 at 18:01 +0900, Tristan Van Berkom via BuildStream-list wrote:
> > > My question to the developers involved in BuildGrid is:
> > >
> > >    What is the status of API stability of BuildGrid regarding the
> > >    protocols and any parts which BuildStream will directly be
> > >    interfacing with ?
> > >
> > >    Are there any chances that changes in BuildGrid due to it's being
> > >    under development, could break BuildStream users ? I.e. can BuildGrid
> > >    be safely upgraded without breaking BuildStream and without requiring
> > >    lock-step upgrades of both BuildStream and BuildGrid ?
> > >
> > > I think the answers for this are already "BuildGrid's BuildStream
> > > facing APIs are already stable, since they are a standard grpc protocol
> > > that is not allowed to break it's API at all" and "No, upgrades to a
> > > deployed BuildGrid cannot break interfacing BuildStream clients".
> > While I believe this to be correct for the basic API, there is no
> > standardization yet for the platform attributes for the execution
> > environment. This is also currently not implemented on either side. In
> > BuildStream this is considered a blocker for 1.4, see #775 and !969.
> > For BuildGrid see #104.
> >
> > While this is not ideal, I expect it to be reasonable for BuildGrid to
> > support the platform attributes BuildStream 1.4 will use for the
> > foreseeable future, even if the eventual upstream standard may differ
> > in some details. I.e., BuildGrid should be able to easily support both,
> > in case they will not match.
> >
> > Assuming the standardization happens between BuildStream 1.4 and 1.6,
> > BuildStream 1.6 may no longer work with older BuildGrid, which I think
> > is acceptable as BuildGrid hasn't had a stable release yet.
> Ok so if I understand correctly, a *newer* version of BuildStream might
> require a *newer* version of BuildGrid, but an older version of
> BuildStream will not suffer from a new version of BuildGrid.
>
> This sounds perfectly fine, newer versions of BuildStream can always
> require new versions of dependencies, I think BuildGrid in this sense
> is an optional dependency and it is only important to bail out early
> and gracefully if the version of BuildGrid is not new enough for the
> new version of BuildStream.
>
> That said, even if BuildGrid does not have a stable release yet, and I
> don't think that is an issue, it should at least have a versioning
> scheme, or more accurately; BuildStream still needs to be able to find
> out if a new enough version of BuildGrid is in place.
>
> Make sense ?
A small note, the REAPI which BuildGrid implements doesn't, as far as I
can tell, use a proper versioning system[0]. It will be easier for us
to stick to an agreed version when that becomes stable too, otherwise
we will continue to support the copy of the API we have in our repo. For
now, I forsee only the `platform` attribute as some sticking point between
releases.

I think it would be best if BuildGrid implemented BuildStream's currently
proposed standard[1]. If between v1.4 and v1.6 release, the REAPI community
decide on an agreed system, we implement that for v1.6, which I'd hope were
based on BuildStream's proposal.

[0] 
https://github.com/bazelbuild/remote-apis/tree/master/build/bazel/remote/execution/v2
[1] 
https://mail.gnome.org/archives/buildstream-list/2018-November/msg00003.html
> Cheers,
>      -Tristan
>
> _______________________________________________
> BuildStream-list mailing list
> BuildStream-list gnome org
> https://mail.gnome.org/mailman/listinfo/buildstream-list

Thanks,
Finn