You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@buildstream.apache.org by Jürg Billeter <j...@bitron.ch> on 2020/07/07 07:23:26 UTC
Re: BuildStream 2.0 planning: bst-artifact-server
On Wed, 2020-04-15 at 19:37 +0900, Tristan Van Berkom wrote:
> * Replacement of artifact cache server.
>
> Blocker.
>
> Our preference is to not maintain an artifact server, and to recommend
> better, more scalable CAS services in the REAPI space for this purpose.
>
> In the event that there is not yet a good replacement for the artifact
> cache server provided by a third party project in the REAPI space
> by the time we are ready to release, then then we will keep bst-artifact-server
> as a thin layer around buildbox-casd.
bst-artifact-server in BuildStream master still supports the
ReferenceStorage service used by BuildStream 1.x clients as convenience
to support 1.x and master clients with the same server.
However, as our goal for 2.x is anyway to replace bst-artifact-server,
maybe it's now time to drop this. Are there any objections to
completely removing support for the ReferenceStorage service in bst-
artifact-server master as part of the move towards the Remote Asset API
(WIP MR !1978¹)?
Cheers,
Jürg
¹ https://gitlab.com/BuildStream/buildstream/-/merge_requests/1978
Re: [BuildStream] BuildStream 2.0 planning: bst-artifact-server
Posted by Abderrahim Kitouni <a....@gmail.com>.
Hi,
Le jeu. 23 juil. 2020 à 13:06, Tristan Van Berkom
<tr...@codethink.co.uk> a écrit :
> I see a potential use case in the medium term for bst-artifact-server
> even after BuildStream 2 is released: it may be a hard(ish) requirement
> for users in a transitional period, for instance; I'm pretty sure we
> will see a period of at least 1 year where freedesktop-sdk will need to
> support both BuildStream 1 and BuildStream 2 (master on bst2 and bst1
> still required until stable is no longer supported).
I propose to use Remote Asset for this transition. As I mentioned in
my earlier reply, RA is almost a superset of ReferenceStorage and we
can make bst 1.x use RA for cache. I have implemented that in the
following MR
https://gitlab.com/BuildStream/buildstream/-/merge_requests/2000
I'd appreciate comments on this approach. I'm not sure about how to
configure it: the current implementation uses RA if available and
falls back to ReferenceStorage, without having extra configuration to
select either one. This makes it transparently work with both the old
artifact server and buildbox-casd.
If we go with this approach, I believe we can simply drop
bst-artifact-server as soon as 1.6 is released and recommend
buildbox-casd by default for bst2 (and other CAS/RA implementations as
they become ready). AFAICT, the only missing feature (except
ReferenceStorage) is TLS client certificate authentication, which I
think can be done with a reverse proxy. It would be interesting to
provide example configuration for a reverse proxy that works though.
Cheers,
Abderrahim
Re: [BuildStream] BuildStream 2.0 planning: bst-artifact-server
Posted by Tristan Van Berkom <tr...@codethink.co.uk>.
On Wed, 2020-07-22 at 11:25 +0200, Jürg Billeter wrote:
[...]
> However, if there is no suitable replacement in time for 2.0, it may
> make sense to move bst-artifact-server to a separate repository to make
> it clear we don't want to maintain bst-artifact-server long term as
> part of BuildStream core. In that separate repository I wouldn't mind
> keeping the ReferenceStorage server part for bst 1.x compatibility if
> there is interest.
>
> And if there is an interested maintainer we could have bst-artifact-
> server in a separate repository even if there is a suitable replacement
> in time for 2.0. This could be done at any time after the merge of
> !1978. Prerequisite is #1371.
>
> Based on the above my plan would be to keep ReferenceStorage server
> support in master for now, however, it will be dropped from the
> BuildStream core repository before 2.0. Either dropped completely or
> moved to a separate repository.
>
> Does this sound like a reasonable way forward to everyone?
This makes general sense to me.
I see a potential use case in the medium term for bst-artifact-server
even after BuildStream 2 is released: it may be a hard(ish) requirement
for users in a transitional period, for instance; I'm pretty sure we
will see a period of at least 1 year where freedesktop-sdk will need to
support both BuildStream 1 and BuildStream 2 (master on bst2 and bst1
still required until stable is no longer supported).
It seem unattractive to migrate to BuildStream 2 if you need to
maintain 2 completely separate infrastructures for artifact storage
during the transitional period where you will be needing both.
Given that this mostly means just splitting out some code into a
separate repository (and copy/pasting in the relevant installation
documentation into the new repository's README.md), I think it would be
wise to consider this separate repository creation as a blocker to
removing the bst-1 client support in current master.
Delaying this "split" is also a better strategy I think: the longer we
delay splitting out this bst-artifact-server with dual client support,
the less likely we are to need to patch this artifact server outside of
BuildStream.
Cheers,
-Tristan
Re: [BuildStream] BuildStream 2.0 planning: bst-artifact-server
Posted by Jürg Billeter <j...@bitron.ch>.
On Tue, 2020-07-07 at 10:24 +0200, Sander Striker via buildstream-list
wrote:
> On Tue, Jul 7, 2020 at 10:11 AM William Salmon <wi...@codethink.co.uk> wrote:
> >
> > Not supporting the bst1.x api would be very inconvenient for early
> > adopters who already use bst1.x
> >
> > Many members of the bst community that i know have there own bst cache
> > server that they define in there ~/.config/buildstream.conf
> >
> > Having to have to run two servers and two ~/.config/buildstream.conf and
> > all the added cli to use them would be a real faf, and add quite a lot
> > of real friction.
>
> Can we walk through the steps of what that will actually look like?
master already supports buildstream2.conf in addition to the
unversioned buildstream.conf to make it easier to use both bst1 and
bst2. I thus don't consider the config aspect a blocker.
>
> > I would be strongly in favor of keeping this as at least optional
> > behavior in the server until a good bit after bst2 is released as it is
> > unlikely that all downstream projects will just switch imitatively.
>
> -1. I'd like the 2.0 release to actually be a point where we can
> shed old APIs and interfaces. Keeping ReferenceServer in signs up
> for supporting it throughout 2.x.
I agree. The goal for 2.0 is to completely drop bst-artifact-server and
thus also drop the ReferenceStorage server support from the BuildStream
code base.
However, if there is no suitable replacement in time for 2.0, it may
make sense to move bst-artifact-server to a separate repository to make
it clear we don't want to maintain bst-artifact-server long term as
part of BuildStream core. In that separate repository I wouldn't mind
keeping the ReferenceStorage server part for bst 1.x compatibility if
there is interest.
And if there is an interested maintainer we could have bst-artifact-
server in a separate repository even if there is a suitable replacement
in time for 2.0. This could be done at any time after the merge of
!1978. Prerequisite is #1371.
Based on the above my plan would be to keep ReferenceStorage server
support in master for now, however, it will be dropped from the
BuildStream core repository before 2.0. Either dropped completely or
moved to a separate repository.
Does this sound like a reasonable way forward to everyone?
Cheers,
Jürg
Re: BuildStream 2.0 planning: bst-artifact-server
Posted by Sander Striker <s....@striker.nl>.
On Tue, Jul 7, 2020 at 10:11 AM William Salmon <wi...@codethink.co.uk>
wrote:
>
>
> On 07/07/2020 08:23, Jürg Billeter wrote:
> > On Wed, 2020-04-15 at 19:37 +0900, Tristan Van Berkom wrote:
> >> * Replacement of artifact cache server.
> >>
> >> Blocker.
> >>
> >> Our preference is to not maintain an artifact server, and to
> recommend
> >> better, more scalable CAS services in the REAPI space for this
> purpose.
> >>
> >> In the event that there is not yet a good replacement for the
> artifact
> >> cache server provided by a third party project in the REAPI space
> >> by the time we are ready to release, then then we will keep
> bst-artifact-server
> >> as a thin layer around buildbox-casd.
> >
> > bst-artifact-server in BuildStream master still supports the
> > ReferenceStorage service used by BuildStream 1.x clients as convenience
> > to support 1.x and master clients with the same server.
> >
> > However, as our goal for 2.x is anyway to replace bst-artifact-server,
> > maybe it's now time to drop this. Are there any objections to
> > completely removing support for the ReferenceStorage service in bst-
> > artifact-server master as part of the move towards the Remote Asset API
> > (WIP MR !1978¹)?
>
> Not supporting the bst1.x api would be very inconvenient for early
> adopters who already use bst1.x
>
> Many members of the bst community that i know have there own bst cache
> server that they define in there ~/.config/buildstream.conf
>
> Having to have to run two servers and two ~/.config/buildstream.conf and
> all the added cli to use them would be a real faf, and add quite a lot
> of real friction.
>
Can we walk through the steps of what that will actually look like?
> I would be strongly in favor of keeping this as at least optional
> behavior in the server until a good bit after bst2 is released as it is
> unlikely that all downstream projects will just switch imitatively.
>
-1. I'd like the 2.0 release to actually be a point where we can shed old
APIs and interfaces. Keeping ReferenceServer in signs up for supporting it
throughout 2.x.
> Especially if they have stable branches that will not want to swap but
> will need maintaining for a period of time. So quite a few members of
> our community will be likely to be running bst1 and bst2 for some time
> to come. But certainly until bst2 is released we will have lots of
> people using both.
>
I always get a bit concerned when I see terms like "many members..", "quite
a few members..", "lots of people" without knowing what that actually means
:/
> A compromise may be to have a bst2 version of ~/.config/buildstream.conf
> but that would still require users to run two cache servers..
>
How do these people invoke bst? Assuming they have a bst2 wrapper script,
it can point to a different config file?
Cheers,
Sander
>
> >
> > Cheers,
> > Jürg
> >
> > ¹ https://gitlab.com/BuildStream/buildstream/-/merge_requests/1978
> >
> >
>
Re: BuildStream 2.0 planning: bst-artifact-server
Posted by William Salmon <wi...@codethink.co.uk>.
On 07/07/2020 08:23, Jürg Billeter wrote:
> On Wed, 2020-04-15 at 19:37 +0900, Tristan Van Berkom wrote:
>> * Replacement of artifact cache server.
>>
>> Blocker.
>>
>> Our preference is to not maintain an artifact server, and to recommend
>> better, more scalable CAS services in the REAPI space for this purpose.
>>
>> In the event that there is not yet a good replacement for the artifact
>> cache server provided by a third party project in the REAPI space
>> by the time we are ready to release, then then we will keep bst-artifact-server
>> as a thin layer around buildbox-casd.
>
> bst-artifact-server in BuildStream master still supports the
> ReferenceStorage service used by BuildStream 1.x clients as convenience
> to support 1.x and master clients with the same server.
>
> However, as our goal for 2.x is anyway to replace bst-artifact-server,
> maybe it's now time to drop this. Are there any objections to
> completely removing support for the ReferenceStorage service in bst-
> artifact-server master as part of the move towards the Remote Asset API
> (WIP MR !1978¹)?
Not supporting the bst1.x api would be very inconvenient for early
adopters who already use bst1.x
Many members of the bst community that i know have there own bst cache
server that they define in there ~/.config/buildstream.conf
Having to have to run two servers and two ~/.config/buildstream.conf and
all the added cli to use them would be a real faf, and add quite a lot
of real friction.
I would be strongly in favor of keeping this as at least optional
behavior in the server until a good bit after bst2 is released as it is
unlikely that all downstream projects will just switch imitatively.
Especially if they have stable branches that will not want to swap but
will need maintaining for a period of time. So quite a few members of
our community will be likely to be running bst1 and bst2 for some time
to come. But certainly until bst2 is released we will have lots of
people using both.
A compromise may be to have a bst2 version of ~/.config/buildstream.conf
but that would still require users to run two cache servers..
>
> Cheers,
> Jürg
>
> ¹ https://gitlab.com/BuildStream/buildstream/-/merge_requests/1978
>
>
Re: BuildStream 2.0 planning: bst-artifact-server
Posted by Abderrahim Kitouni <a....@gmail.com>.
Hi,
Le mar. 7 juil. 2020 à 08:23, Jürg Billeter <j...@bitron.ch> a écrit :
> bst-artifact-server in BuildStream master still supports the
> ReferenceStorage service used by BuildStream 1.x clients as convenience
> to support 1.x and master clients with the same server.
>
> However, as our goal for 2.x is anyway to replace bst-artifact-server,
> maybe it's now time to drop this. Are there any objections to
> completely removing support for the ReferenceStorage service in bst-
> artifact-server master as part of the move towards the Remote Asset API
> (WIP MR !1978¹)?
I'd like to keep it a little while. As in have 1.94 release with
remote asset (and the junction rework which is also a breaking
change), and remove the reference storage in 1.95.
My idea for resolving this is to support remote asset in buildstream
1.6. Since remote asset can do what the reference storage is currently
doing, it should be fairly straightforward to add support for remote
asset on top of what we have already.
GetReference -> FetchDirectory
key -> uris (using some appropriate URN)
UpdateReference -> PushDirectory
keys -> uris (ditto)
digest -> root_directory_digest
Status is only used to query whether push is supported and can be
easily replaced.
What do you think?
Regards,
Abderrahim
Re: BuildStream 2.0 planning: bst-artifact-server
Posted by Thomas Coldrick <th...@codethink.co.uk>.
Hi,
Just wanted to throw in my 2¢ here.
On 07/07/2020 08:23, Jürg Billeter wrote:
> However, as our goal for 2.x is anyway to replace bst-artifact-server,
> maybe it's now time to drop this. Are there any objections to
> completely removing support for the ReferenceStorage service in bst-
> artifact-server master as part of the move towards the Remote Asset
> API (WIP MR !1978¹)? Cheers, Jürg ¹
> https://gitlab.com/BuildStream/buildstream/-/merge_requests/1978
I think it's correct to drop the ReferenceStorage service for the master
branch entirely once this change comes in, users wanting a bst-1.x
compatible
cache should use the bst-artifact-server from the 1.x branch.
To me, the messaging of "remote caching is incompatible between 1.x and 2.x"
is much clearer this way.
Cheers,
Tom