refactor(tvix/store): remove ChunkService
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>
2023-05-11 14:49:01 +02:00
|
|
|
use super::utils::{gen_blob_service, gen_directory_service};
|
2023-02-27 13:03:53 +01:00
|
|
|
use crate::blobservice::BlobService;
|
|
|
|
use crate::directoryservice::DirectoryService;
|
|
|
|
use crate::import::import_path;
|
|
|
|
use crate::proto;
|
|
|
|
use crate::tests::fixtures::DIRECTORY_COMPLICATED;
|
|
|
|
use crate::tests::fixtures::*;
|
|
|
|
use tempfile::TempDir;
|
|
|
|
|
|
|
|
#[cfg(target_family = "unix")]
|
|
|
|
#[test]
|
|
|
|
fn symlink() {
|
|
|
|
let tmpdir = TempDir::new().unwrap();
|
|
|
|
|
2023-03-01 18:55:51 +01:00
|
|
|
std::fs::create_dir_all(&tmpdir).unwrap();
|
|
|
|
std::os::unix::fs::symlink(
|
|
|
|
"/nix/store/somewhereelse",
|
|
|
|
tmpdir.path().join("doesntmatter"),
|
|
|
|
)
|
|
|
|
.unwrap();
|
2023-02-27 13:03:53 +01:00
|
|
|
|
|
|
|
let root_node = import_path(
|
2023-03-01 18:55:51 +01:00
|
|
|
&mut gen_blob_service(),
|
|
|
|
&mut gen_directory_service(),
|
|
|
|
tmpdir.path().join("doesntmatter"),
|
2023-02-27 13:03:53 +01:00
|
|
|
)
|
|
|
|
.expect("must succeed");
|
|
|
|
|
|
|
|
assert_eq!(
|
|
|
|
crate::proto::node::Node::Symlink(proto::SymlinkNode {
|
|
|
|
name: "doesntmatter".to_string(),
|
|
|
|
target: "/nix/store/somewhereelse".to_string(),
|
|
|
|
}),
|
|
|
|
root_node,
|
|
|
|
)
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn single_file() {
|
|
|
|
let tmpdir = TempDir::new().unwrap();
|
|
|
|
|
2023-03-01 18:55:51 +01:00
|
|
|
std::fs::write(tmpdir.path().join("root"), HELLOWORLD_BLOB_CONTENTS).unwrap();
|
2023-02-27 13:03:53 +01:00
|
|
|
|
2023-03-01 18:55:51 +01:00
|
|
|
let mut blob_service = gen_blob_service();
|
2023-02-27 13:03:53 +01:00
|
|
|
|
|
|
|
let root_node = import_path(
|
|
|
|
&mut blob_service,
|
2023-03-01 18:55:51 +01:00
|
|
|
&mut gen_directory_service(),
|
|
|
|
tmpdir.path().join("root"),
|
2023-02-27 13:03:53 +01:00
|
|
|
)
|
|
|
|
.expect("must succeed");
|
|
|
|
|
|
|
|
assert_eq!(
|
|
|
|
crate::proto::node::Node::File(proto::FileNode {
|
|
|
|
name: "root".to_string(),
|
|
|
|
digest: HELLOWORLD_BLOB_DIGEST.to_vec(),
|
|
|
|
size: HELLOWORLD_BLOB_CONTENTS.len() as u32,
|
|
|
|
executable: false,
|
|
|
|
}),
|
|
|
|
root_node,
|
|
|
|
);
|
|
|
|
|
|
|
|
// ensure the blob has been uploaded
|
|
|
|
assert!(blob_service
|
refactor(tvix/store): remove ChunkService
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>
2023-05-11 14:49:01 +02:00
|
|
|
.has(&HELLOWORLD_BLOB_DIGEST.to_vec().try_into().unwrap())
|
|
|
|
.unwrap());
|
2023-02-27 13:03:53 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn complicated() {
|
|
|
|
let tmpdir = TempDir::new().unwrap();
|
|
|
|
|
|
|
|
// File ``.keep`
|
2023-03-01 18:55:51 +01:00
|
|
|
std::fs::write(tmpdir.path().join(".keep"), vec![]).unwrap();
|
2023-02-27 13:03:53 +01:00
|
|
|
// Symlink `aa`
|
2023-03-01 18:55:51 +01:00
|
|
|
std::os::unix::fs::symlink("/nix/store/somewhereelse", tmpdir.path().join("aa")).unwrap();
|
2023-02-27 13:03:53 +01:00
|
|
|
// Directory `keep`
|
2023-03-01 18:55:51 +01:00
|
|
|
std::fs::create_dir(tmpdir.path().join("keep")).unwrap();
|
2023-02-27 13:03:53 +01:00
|
|
|
// File ``keep/.keep`
|
2023-03-01 18:55:51 +01:00
|
|
|
std::fs::write(tmpdir.path().join("keep").join(".keep"), vec![]).unwrap();
|
2023-02-27 13:03:53 +01:00
|
|
|
|
2023-03-01 18:55:51 +01:00
|
|
|
let mut blob_service = gen_blob_service();
|
|
|
|
let mut directory_service = gen_directory_service();
|
2023-02-27 13:03:53 +01:00
|
|
|
|
refactor(tvix/store): remove ChunkService
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>
2023-05-11 14:49:01 +02:00
|
|
|
let root_node = import_path(&mut blob_service, &mut directory_service, tmpdir.path())
|
|
|
|
.expect("must succeed");
|
2023-02-27 13:03:53 +01:00
|
|
|
|
|
|
|
// ensure root_node matched expectations
|
|
|
|
assert_eq!(
|
|
|
|
crate::proto::node::Node::Directory(proto::DirectoryNode {
|
2023-03-01 18:55:51 +01:00
|
|
|
name: tmpdir
|
|
|
|
.path()
|
|
|
|
.file_name()
|
|
|
|
.unwrap()
|
|
|
|
.to_string_lossy()
|
|
|
|
.to_string(),
|
2023-03-16 00:01:30 +01:00
|
|
|
digest: DIRECTORY_COMPLICATED.digest().to_vec(),
|
2023-02-27 13:03:53 +01:00
|
|
|
size: DIRECTORY_COMPLICATED.size(),
|
|
|
|
}),
|
|
|
|
root_node,
|
|
|
|
);
|
|
|
|
|
|
|
|
// ensure DIRECTORY_WITH_KEEP and DIRECTORY_COMPLICATED have been uploaded
|
|
|
|
assert!(directory_service
|
2023-03-16 00:01:30 +01:00
|
|
|
.get(&DIRECTORY_WITH_KEEP.digest())
|
2023-02-27 13:03:53 +01:00
|
|
|
.unwrap()
|
|
|
|
.is_some());
|
|
|
|
assert!(directory_service
|
2023-03-16 00:01:30 +01:00
|
|
|
.get(&DIRECTORY_COMPLICATED.digest())
|
2023-02-27 13:03:53 +01:00
|
|
|
.unwrap()
|
|
|
|
.is_some());
|
|
|
|
|
|
|
|
// ensure EMPTY_BLOB_CONTENTS has been uploaded
|
|
|
|
assert!(blob_service
|
refactor(tvix/store): remove ChunkService
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>
2023-05-11 14:49:01 +02:00
|
|
|
.has(&EMPTY_BLOB_DIGEST.to_vec().try_into().unwrap())
|
|
|
|
.unwrap());
|
2023-02-27 13:03:53 +01:00
|
|
|
}
|