Modify replica struct to better describe deal spanning #153
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #153 +/- ##
==========================================
- Coverage 31.70% 30.82% -0.89%
==========================================
Files 5 5
Lines 738 743 +5
==========================================
- Hits 234 229 -5
- Misses 469 479 +10
Partials 35 35
|
api/model.go
Outdated
| ID string `json:"id"` | ||
| Replicas []Replica `json:"Replicas,omitempty"` | ||
| ID string `json:"id"` | ||
| Replica *Replica `json:"Replicas,omitempty"` |
There was a problem hiding this comment.
🤔 this should continue to be a slice right? A blob may have multiple replicas.
There was a problem hiding this comment.
That seems correct. I was a bit confused by the relationship between deals and pieces. I think something needs to change here
Does each deal map to a separate replica, or a separate piece, or either? So if a blob is spread across multiple pieces, are those pieces in separate deals? If so, then I need to know how to determine if separate deals from getFileDealsRes are for different replicas or for different pieces in the same replica.
There was a problem hiding this comment.
something needs to change here
Right, the work here is to set up stepping stones for further changes across the workflow.
Does each deal map to a separate replica, or a separate piece, or either?
Mapping of replica:deal:piece is 1:1:1 for blobs that fit within a sector (32GiB currently). But as soon as blobs become larger, then the mapping of replica to deal looks something like this 1:1..*, and mapping of deal to piece (for the time being) continues to be 1:1.
Cc @xinaxu We should think about large blob support and mapping of Singularity primitives to Motion as part of work items beyond Beta.
This PR changes a replica to be composed of a slice of pieces, each with a different status, verification time, etc. as per #65.
Fixes #65