-
Notifications
You must be signed in to change notification settings - Fork 0
fix: offer to use collection instead of tenant #19
fix: offer to use collection instead of tenant #19
Conversation
89a1e23
to
9bd9685
Compare
View stack outputs
|
I don't understand what "buckets" means in this context. |
tenant: string | ||
// identifier of the collection for the tenant `did:web:web3.storage` | ||
// spade relies on collections to identify different replication constraints. | ||
collection: string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not have both?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest naming things we store under names that makes senses to us, and then mapping them at the points where we interface with spade. This would be "storefront" for us right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the bucket that Spade reads from us. In other words, this is the interface...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be worth to read https://github.com/web3-storage/dealer/blob/main/docs/architecture.md#spade-integration + the issue where we iterated on format in calls with Spade team #7 (comment)
@alanshaw
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ok got it!
Previously we were building assuming that we could use one bucket and set the
tenant
ID as the way to integrate with Spade. This approach would also be tricky in future scenarios where we wanted to have the ability to have different configurations per SLA things (in case it materializes).Talking with @jcace (SEE) about
storefront
property and whether we could rely on a friendly name (e.g.did:web:web3.storage
) instead of an internal ID, we concluded that Spade would require a different bucket per tenant. However, each tenant MAY have different collections with different Replication Constraints.We were asked to have different buckets per tenant, and swap
tenant
intocollection
. For now, we will also actually just have one tenant, so we can figure out later how could we have dynamic tenant world without needing to manually provision a bucket.