On Tue, Jan 15, 2019 at 5:39 PM Jürg Billeter <
j bitron ch> wrote:
[...]
We want the server to know which blobs are referenced by a particular
ref. This allows the server to influence cache expiry of blobs based on
GetReference requests. I.e., the server needs to be able to decode the
referenced object. And thus, I think only two options make sense: keep
using the directory proto-based approach with a generic service or
define a separate artifact-specific service where we can use the
artifact proto.
My vote would be with the latter. I would like us to think about artifact caching a lot more like we do about action caching. Instead of assuming you're talking to one service, you are actually dealing with two: ArtifactCache and CAS.
I would expect the ArtifactCache service to return Artifact protos.
In its implementation it could use FindMissingBlobs to ensure the Artifact has the non-optional content. If not it can remove the Artifact mapping and return that there is not Artifact for this cache key [ref]. That allows ArtifactCache and CAS to remain a bit more decoupled. With respect to giving guarantees of availability is a separate concern, and has more to do with CAS lifetimes and thus which CAS endpoint you are pointing to.
Whether the implementation of the service uses a direct mapping of artifact_cache_key: artifact to Artifact, or whether it stores the actual Artifact in CAS and uses a mapping of artifact cache_key to artifact Digest, I'm ambivalent on.
Cheers,
Jürg
_______________________________________________
BuildStream-list mailing list
BuildStream-list gnome org
https://mail.gnome.org/mailman/listinfo/buildstream-list
