616fa4476f
Whether chunking is involved or not, is an implementation detail of each Blobstore. Consumers of a whole blob shouldn't need to worry about that. It currently is not visible in the gRPC interface either. It shouldn't bleed into everything. Let the BlobService trait provide `open_read` and `open_write` methods, which return handles providing io::Read or io::Write, and leave the details up to the implementation. This means, our custom BlobReader module can go away, and all the chunking bits in there, too. In the future, we might still want to add more chunking-aware syncing, but as a syncing strategy some stores can expose, not as a fundamental protocol component. This currently needs "SyncReadIntoAsyncRead", taken and vendored in from https://github.com/tokio-rs/tokio/pull/5669. It provides a AsyncRead for a sync Read, which is necessary to connect our (sync) BlobReader interface to a GRPC server implementation. As an alternative, we could also make the BlobReader itself async, and let consumers of the trait (EvalIO) deal with the async-ness, but this is less of a change for now. In terms of vendoring, I initially tried to move our tokio crate to these commits, but ended up in version incompatibilities, so let's vendor it in for now. Change-Id: I5969ebbc4c0e1ceece47981be3b9e7cfb3f59ad0 Reviewed-on: https://cl.tvl.fyi/c/depot/+/8551 Tested-by: BuildkiteCI Reviewed-by: tazjin <tazjin@tvl.su> |
||
---|---|---|
.. | ||
docs | ||
protos | ||
src | ||
build.rs | ||
Cargo.toml | ||
default.nix | ||
README.md |
//tvix/store
This contains the code hosting the tvix-store.
For the local store, Nix realizes files on the filesystem in /nix/store
(and
maintains some metadata in a SQLite database). For "remote stores", it
communicates this metadata in NAR (Nix ARchive) and NARInfo format.
Compared to the Nix model, tvix-store
stores data on a much more granular
level than that, which provides more deduplication possibilities, and more
granular copying.
However, enough information is preserved to still be able to render NAR and
NARInfo (handled by //tvix/nar-bridge
).
More Information
Check the protos/
subfolder for the definition of the exact RPC methods and
messages.
Interacting with the GRPC service manually
The shell environment in //tvix
provides evans
, which is an interactive
REPL-based gPRC client.
You can use it to connect to a tvix-store
and call the various RPC methods.
$ cargo run &
$ evans --host localhost --port 8000 -r repl
______
| ____|
| |__ __ __ __ _ _ __ ___
| __| \ \ / / / _. | | '_ \ / __|
| |____ \ V / | (_| | | | | | \__ \
|______| \_/ \__,_| |_| |_| |___/
more expressive universal gRPC client
tvix.store.v1@localhost:8000> service BlobService
tvix.store.v1.BlobService@localhost:8000> call Put --bytes-from-file
data (TYPE_BYTES) => /run/current-system/system
{
"digest": "KOM3/IHEx7YfInAnlJpAElYezq0Sxn9fRz7xuClwNfA="
}
tvix.store.v1.BlobService@localhost:8000> call Get --bytes-as-base64
digest (TYPE_BYTES) => KOM3/IHEx7YfInAnlJpAElYezq0Sxn9fRz7xuClwNfA=
{
"data": "eDg2XzY0LWxpbnV4"
}
$ echo eDg2XzY0LWxpbnV4 | base64 -d
x86_64-linux
Thanks to tvix-store
providing gRPC Server Reflection (with reflection
feature), you don't need to point evans
to the .proto
files.