On Mon, Feb 11, 2019 at 5:43 PM Jürg Billeter <
j bitron ch> wrote:
Hi Raoul,
On Mon, 2019-02-11 at 14:53 +0000, Raoul Hidalgo Charman via
BuildStream-list wrote:
> The service will implement the following RPCs, somewhat similar to to
> the current reference service:
> * GetArtifact: given a reference returns a single artifact proto, the
> service first checking whether buildtrees and log files are present and
> updating the proto.
As this is checking buildtrees and log files, I assume this will also
check whether all blobs of the main payload are available (calling
FindMissingBlobs on the CAS server) and otherwise return NOT_FOUND, or
do you have a different approach in mind?
I actually expect the Artifact service to only check if the the main payload is available and return NOT_FOUND otherwise. I don't expect it to do anything else, as the client needs to deal with the failure cases regardless. Specifically, if logs or buildtrees are there at the time of retrieval, doesn't mean they are going to be there later.
I also do not expect GetArtifact to modify the proto. It should return what is there, or return NOT_FOUND.
> * GetArtifacts: gives a list of references returns the artifact protos
> that are available. This will have an additional Boolean option for
> checking content as GetArtifact does, but without it will return
> artifact protos without updating them.
Do we really need/want this? What's the use case?
Besides possible scaling concerns, this would make it impossible to use
a single artifact server in a team where not everyone should have
access to all artifacts. For sensitive content, we would likely anyway
recommend setting up separate artifact servers, however, there may be
scenarios where not listing artifacts may suffice as isolation.
I prefer to keep it simple as well, and not have a GetArtifacts. I am assuming we can pipeline these requests quite well. We can revisit a specialized API when we need it.
Cheers,
Jürg
Cheers,
Sander
_______________________________________________
BuildStream-list mailing list
BuildStream-list gnome org
https://mail.gnome.org/mailman/listinfo/buildstream-list
