refactor(tvix): move castore into tvix-castore crate
This splits the pure content-addressed layers from tvix-store into a `castore` crate, and only leaves PathInfo related things, as well as the CLI entrypoint in the tvix-store crate. Notable changes: - `fixtures` and `utils` had to be moved out of the `test` cfg, so they can be imported from tvix-store. - Some ad-hoc fixtures in the test were moved to proper fixtures in the same step. - The protos are now created by a (more static) recipe in the protos/ directory. The (now two) golang targets are commented out, as it's not possible to update them properly in the same CL. This will be done by a followup CL once this is merged (and whitby deployed) Bug: https://b.tvl.fyi/issues/301 Change-Id: I8d675d4bf1fb697eb7d479747c1b1e3635718107 Reviewed-on: https://cl.tvl.fyi/c/depot/+/9370 Reviewed-by: tazjin <tazjin@tvl.su> Reviewed-by: flokli <flokli@flokli.de> Autosubmit: flokli <flokli@flokli.de> Tested-by: BuildkiteCI Reviewed-by: Connor Brewster <cbrewster@hey.com>
This commit is contained in:
parent
d8ef0cfb4a
commit
32f41458c0
89 changed files with 2308 additions and 1829 deletions
52
tvix/castore/protos/rpc_blobstore.proto
Normal file
52
tvix/castore/protos/rpc_blobstore.proto
Normal file
|
|
@ -0,0 +1,52 @@
|
|||
// SPDX-License-Identifier: MIT
|
||||
// Copyright © 2022 The Tvix Authors
|
||||
syntax = "proto3";
|
||||
|
||||
package tvix.castore.v1;
|
||||
|
||||
option go_package = "code.tvl.fyi/tvix/castore/protos;castorev1";
|
||||
|
||||
service BlobService {
|
||||
// In the future, Stat will expose more metadata about a given blob,
|
||||
// such as more granular chunking, baos.
|
||||
// For now, it's only used to check for the existence of a blob, as asking
|
||||
// this for a non-existing Blob will return a Status::not_found gRPC error.
|
||||
rpc Stat(StatBlobRequest) returns (BlobMeta);
|
||||
|
||||
// Read returns a stream of BlobChunk, which is just a stream of bytes with
|
||||
// the digest specified in ReadBlobRequest.
|
||||
//
|
||||
// The server may decide on whatever chunking it may seem fit as a size for
|
||||
// the individual BlobChunk sent in the response stream.
|
||||
rpc Read(ReadBlobRequest) returns (stream BlobChunk);
|
||||
|
||||
// Put uploads a Blob, by reading a stream of bytes.
|
||||
//
|
||||
// The way the data is chunked up in individual BlobChunk messages sent in
|
||||
// the stream has no effect on how the server ends up chunking blobs up.
|
||||
rpc Put(stream BlobChunk) returns (PutBlobResponse);
|
||||
}
|
||||
|
||||
message StatBlobRequest {
|
||||
// The blake3 digest of the blob requested
|
||||
bytes digest = 1;
|
||||
}
|
||||
|
||||
message BlobMeta {
|
||||
}
|
||||
|
||||
message ReadBlobRequest {
|
||||
// The blake3 digest of the blob or chunk requested
|
||||
bytes digest = 1;
|
||||
}
|
||||
|
||||
// This represents some bytes of a blob.
|
||||
// Blobs are sent in smaller chunks to keep message sizes manageable.
|
||||
message BlobChunk {
|
||||
bytes data = 1;
|
||||
}
|
||||
|
||||
message PutBlobResponse {
|
||||
// The blake3 digest of the data that was sent.
|
||||
bytes digest = 1;
|
||||
}
|
||||
Loading…
Add table
Add a link
Reference in a new issue