Skip to content
This repository has been archived by the owner on May 15, 2024. It is now read-only.

Add option to use RIBS as Motion blob store #26

Merged
merged 1 commit into from
Jul 20, 2023
Merged

Conversation

masih
Copy link
Member

@masih masih commented Jul 19, 2023

Implement an experimental option to use RIBS as Motion blob.Store. The implementation uses a flat-file directory to store an index of Motion blob.ID to IPFS blocks stored by RIBS.

RIBS would then accumulate the stored information and makes deals in the background. The SP selection and wallet configuration is hard coded in RIBS. The FileCoin wallet is instantiated automatically if it does not exist at ~/.ribswallet. Making this configurable requires changes in RIBS.

Retrieval API implements an io.ReadSeekCloser which allows range reads over a list of CIDs.

Offloading onto S3 compatible APIS, like AWS S3 and CloudFlare R2 is supported by RIBS and activated if specific environment variables are set. See: https://github.com/FILCAT/ribs/blob/0d5f0580effc112b01fe676f080bdbf1c2c7568a/rbdeal/car_offload_s3.go#L28

The RIBS storage is disabled by default. It is enabled by setting the option --experimentalRibsStore.

This implementation is experimental: it should not be used in Production environment. It is implemented to facilitate experimentation and scoping of the Motion project.

Copy link
Contributor

@hannahhoward hannahhoward left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Various thoughts and suggestions. I agree this may be a good way to get us to a milestone 2 that ISVs can play with quickly.

blob/ribs_store.go Show resolved Hide resolved
blob/ribs_store.go Show resolved Hide resolved
blob/ribs_store.go Outdated Show resolved Hide resolved
blob/ribs_store.go Outdated Show resolved Hide resolved
return nil, err
}
}
if err := batch.Flush(ctx); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I notice you're not storing the UnixFS intermediate tree (that would produce a RootCID for the whole file). I dunno if that matters.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't believe it matters until we start picking apart what RIBS does internally. Right now at the level of abstraction we are working with in this PR there are just chunks in form of IPFS blocks and their order.

Implement an experimental option to use RIBS as Motion `blob.Store`. The
implementation uses a flat-file directory to store an index of Motion
`blob.ID` to IPFS blocks stored by RIBS.

RIBS would then accumulate the stored information and makes deals in
the background. The SP selection and wallet configuration is hard coded
in RIBS. The FileCoin wallet is instantiated automatically if it does
not exist at `~/.ribswallet`. Making this configurable requires changes
in RIBS.

Retrieval API implements an `io.ReadSeekCloser` which allows range
reads over a list of CIDs.

Offloading onto S3 compatible APIS, like AWS S3 and CloudFlare R2 is
supported by RIBS and activated if specific environment variables are
set. See: https://github.com/FILCAT/ribs/blob/0d5f0580effc112b01fe676f080bdbf1c2c7568a/rbdeal/car_offload_s3.go#L28

The RIBS storage is disabled by default. It is enabled by setting the
option `--experimentalRibsStore`.

This implementation is experimental: it should not be used in
Production environment. It is implemented to facilitate experimentation
and scoping of the Motion project.

Disable 32-bit tests due to RIBS dependencies.
@willscott
Copy link
Collaborator

may be worth making the wallet extensibility change to ribs. i suspect it will be accepted, but we'd probably want to set that through our own API rather than having it change over time

@masih
Copy link
Member Author

masih commented Jul 20, 2023

may be worth making the wallet extensibility change to ribs. i suspect it will be accepted, but we'd probably want to set that through our own API rather than having it change over time

Yup I just got write access to ribs repo and doing that now.
Is that a blocker for getting this PR merged you think Will?

@willscott
Copy link
Collaborator

lets still default to merging quickly, and happy to see this merged.
but it's probably something we put behind a feature flag / "mark experimental" until we feel like we can support it behind the commmon motion interface

@masih
Copy link
Member Author

masih commented Jul 20, 2023

put behind a feature flag / "mark experimental"

The flag that enables it (disabled by default) is --experimentalRibsStore. Aside from that is there anything specific you have in mind?

@masih masih merged commit 27bcb41 into main Jul 20, 2023
17 checks passed
@masih masih deleted the masih/smoking_ribs branch July 20, 2023 10:54
@masih masih self-assigned this Jul 20, 2023
@TorfinnOlsen TorfinnOlsen added this to the M1.0 Motion Testable API milestone Jul 21, 2023
@TorfinnOlsen TorfinnOlsen added M2.0 Motion API Storage to Filecoin MVP This is included within the MVP labels Jul 25, 2023
hannahhoward added a commit that referenced this pull request Aug 17, 2023
Implement an experimental option to use Singularity as Motion
blob.Store.

A singularity blob store for now is a local store + a singularity
connector

For a put operation, the file is saved to the local blob store, then the
local file is added to Singularity for scanning (as an item). The
returned ID is the ID generated by singularity, rather than the UUID of
the file (note: this changes the ID type to a raw string -- currently
singularity uses integer indexes for each item -- @xinaxu maybe has an
opinion about whether Singularity might either convert IDs to UUIDs or
add a UUID at least for Item -- alternatively, we can make a single
motion ID -> singularity primary key mapping in a file held in memory).

For a get operation, the id is sent to Singularity to retrieve metadata
about the file, and then the file is retrieved from the local store.
(for real retrieval with Filecoin, we could have the GetItem call to
Singularity also hydrate the local store, though this may not be the
most performant option)

Note that all this really does so far is start creating entities within
Singularities database and scan files into Items & ItemParts.

I haven't attempted to start data prep workers or make filecoin deals.

Also, currently the singularity connector is implemented with a direct
connection to an SQLite DB setup for Singularity, but could also be
implemented over the singularity API.

Per the thinking in
#24, what may make
most sense is to get #26 fully working to allow partners to try storing
deals on Filecoin, while we continue to build this solution out and
harden/productionize Singularity's deal making.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
M2.0 Motion API Storage to Filecoin MVP This is included within the MVP
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

4 participants