proposal: Integrate with beyondstorage/go-storage to add multiple storage backend supports

[Xuanwo]

Background

BeyondStorage is an open-source community focused on providing cross-cloud, no vendor lock-in data services. And go-storage is a storage abstraction that can operate the data across different storage services like s3, gcs, azblob, oss, even ipfs. Service Integration Tracking records the updates.

zot is cool but lacking different storage backends support (as far as I know).

Proposal

So I propose to integrate zot with beyondstorage/go-storage to add multiple storage backend supports.

• Add config support

we have rootDirectory for now, maybe we can support add a new field or allow connection string here like:

"rootDirectory": "s3://bucketname/path"

• Migrate I/O operations to go-storage

---

Thanks for reading and any comments are welcome!

[rchincha]

@Xuanwo thanks for bringing go-storage [1] to our attention. We will look at it.
Our solution to remote storage has been to use fuse drivers [2].

[1] https://github.com/beyondstorage/go-storage
[2] #179

[rchincha]

@Xuanwo just to add, we recently added support for multiple subpaths (and by extension multiple storage backends) [1]

[1] https://github.com/anuvu/zot/blob/master/examples/config-multiple.json#L7

[rchincha]

@Xuanwo would the go-storage project [1] have any benchmarking numbers etc comparing and contrasting with s3fs-fuse project [2] and goofys [3]?

References:
[1] https://github.com/beyondstorage/go-storage
[2] https://github.com/s3fs-fuse/s3fs-fuse
[3] https://github.com/kahing/goofys

[Xuanwo]

We will have a benchmark on this case.

[Xuanwo]

We tested the overhead of go-storage versus native SDK (we reach this tests via implement a service with no-op), the result shows that our abstriction adds up to 20ns/op. (PR beyondstorage/go-storage#685)

goos: linux
goarch: amd64
pkg: github.com/beyondstorage/go-storage/v4/tests
cpu: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
BenchmarkStorage_Stat
BenchmarkStorage_Stat-8   	45983168	        21.99 ns/op
PASS

So we can treat go-storage as nearly the same as using native SDK directly.

Both s3fs-fuse and goofys are built upon native SDK with the abstriction of POSIX alike API, they must be much slower than using native SDK.

If there is a need to real benchmarking numbers, we will set up an env that write/read/list files via go-storage and fuse for a bench.

What's your idea about that?

[rchincha]

@Xuanwo for our container builds use case (in production), we serve a parallel mix of small/large sizes of read/write workload. It would be great if we can get a sample app using go-storage project with results similar to this [1].

Also noticed, you are working on improving your code coverage [2] and couldn't find anything about running lint [3] in your ci/cd pipeline.

References:
[1] https://docs.openstack.org/developer/performance-docs/test_results/container_repositories/registry2/index.html
[2] https://codecov.io/gh/beyondstorage/go-storage/branch/master
[3] https://github.com/golangci/golangci-lint

[rchincha]

We are making progress on this issue with PR #216.

We can re-evaluate once beyondstorage/go-storage code quality becomes provably higher.