feat: add WithMount method to support cross repository blob mounting#632
feat: add WithMount method to support cross repository blob mounting#632ktarplee wants to merge 2 commits into
WithMount method to support cross repository blob mounting#632Conversation
46b08cb to
c1b4ce3
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #632 +/- ##
==========================================
- Coverage 75.41% 75.36% -0.06%
==========================================
Files 59 59
Lines 5606 5647 +41
==========================================
+ Hits 4228 4256 +28
- Misses 1015 1024 +9
- Partials 363 367 +4 ☔ View full report in Codecov by Sentry. |
|
@Wwwsylvia Any feedback on this approach? |
|
@ktarplee I'm busy with other stuffs these days, might take a closer look into this a bit later. Sorry for the inconvenience. 😟 |
c1b4ce3 to
59f6b8f
Compare
There was a problem hiding this comment.
I think this approach works and looks concise. @shizhMSFT Do you have any concerns?
345e9d5 to
024ea12
Compare
|
Why does |
024ea12 to
d26ffea
Compare
3a4bc30 to
45a1cb8
Compare
oras-go/registry/repository.go Lines 113 to 124 in f296072 |
|
I need some more time to review this and do some integration tests. |
45a1cb8 to
583be41
Compare
There was a problem hiding this comment.
I've tested this against ACR, zot and distribution.
The blobs can be mounted as expected in ACR and distribution, while they get skipped in zot. Looks like zot deduplicates blobs across repositories.
LGTM with a few nit suggestions.
BTW can we have the PR title start with "feat:"?
|
@qweeah Can you also help to review this and check if it meets the needs of ORAS CLI? |
583be41 to
d5cc4c2
Compare
WithMount method to support cross repository blob mounting
|
@shizhMSFT Please take a look when you have a chance. |
Please expect delayed review since I’m currently OOF. |
|
LGTM although IANAM (Tried to implement an index creation command based on d5cc4c2 and it looks good, see |
WithMount method to support cross repository blob mountingWithMount method to support cross repository blob mounting
|
|
||
| opts := oras.CopyOptions{} | ||
| // Enable cross-repository blob mounting | ||
| opts.WithMount("source", dst.(registry.Mounter), nil) |
There was a problem hiding this comment.
What will happen if other target instead of dst is passed to WithMount?
There was a problem hiding this comment.
Let's say the true destination target is dst but instead they pass in dst2. The blobs would be mounted or copied to dst2 but the manifest would be copied to dst and fail due to missing blobs.
There was a problem hiding this comment.
Can we avoid that situation in the first place with a better API design?
|
|
||
| opts := oras.CopyOptions{} | ||
| // Enable cross-repository blob mounting | ||
| opts.WithMount("source", dst.(registry.Mounter), nil) |
There was a problem hiding this comment.
What will happen if someone call WithMount twice?
There was a problem hiding this comment.
This is a fun one. I think it would work and not produce an error (but I have not tried it). Let's call the preCopy functions preCopy1, preCopy2, preCopy3. The last one is the one created by the last call to WithMount. The first thing that would happen is the call to preCopy3 which would attempt a mount. Let's assume the mount failed, then getContent would get called (defined by preCopy3) and it would call preCopy2. preCopy2 was created by the first call to WithMount so it will try to mount the blob with that source repo. Let's assume it also fails, then getContent would call preCopy1. Then getContent (from preCopy2) would return errdef.ErrUnsupported (to be renamed) and the blob would be copied. Then getContent (from preCopy3) would return errdef.ErrUnsupported (to be renamed) and the blob would be copied again. So it seems like the blob would be copied twice with this design. Not fatal but not ideal either.
There was a problem hiding this comment.
We could add a field to CopyOptions, something like tryingMount bool. In WithMount() we can check that tryingMount is false (else panic) and then set it to true. Then if the programmer makes the error to call WithMount twice they get a reasonable error.
|
|
||
| tagName := "latest" | ||
|
|
||
| opts := oras.CopyOptions{} |
There was a problem hiding this comment.
What if someone reuse oras.CopyOptions?
There was a problem hiding this comment.
The CopyOptions after a WithMount would only be usable when the same source and destination are not changed. That is not ideal. A shallow copy of the oras.CopyOptions before calling WithMount() solves this problem. That is how I use this in my code.
There was a problem hiding this comment.
It would be ideal if we would reuse the CopyOptions. Currently, only PackOptions is not re-usable.
There was a problem hiding this comment.
We could change the signature of the WithMount() to return a modified copy of the receiver. It would not modify the receiver so opts below could be reused. It would then be used like so:
desc, err := oras.Copy(ctx, src, tagName, dst, tagName,
opts.WithMount("source", dst.(registry.Mounter), nil))I think that would reduce the misuse and make it more obvious what it does.
Implements a WithMount method on CopyGraphOptions Also allows for getContent to return ErrUnsupported to fall back to default behavior. Signed-off-by: Kyle M. Tarplee <kmtarplee@ieee.org>
Signed-off-by: Kyle M. Tarplee <kmtarplee@ieee.org>
bc912ca to
4becd16
Compare
|
I have an idea to improve the API design of this and allow for trying to mount from multiple source locations. I will work on that very soon. The worst part about this design is that it is too limiting. For example, imagine someone is copying from
I think some of the design issues highlighted above with the |
|
Closing this in favor of #665 |
This includes everything from #631 but adds more (debatable) changes.
Closes #580
I realize I still need to add tests but I wanted to see if this approach is acceptable first.