-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add WithMount
method to support cross repository blob mounting
#632
Conversation
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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.
LGTM
@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
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.
@ktarplee Sorry for the late review as I was OOF.
|
||
opts := oras.CopyOptions{} | ||
// Enable cross-repository blob mounting | ||
opts.WithMount("source", dst.(registry.Mounter), nil) |
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.
What will happen if other target instead of dst
is passed to WithMount
?
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What will happen if someone call WithMount
twice?
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 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if someone reuse oras.CopyOptions
?
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be ideal if we would reuse the CopyOptions. Currently, only PackOptions is not re-usable.
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.
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 <[email protected]>
Signed-off-by: Kyle M. Tarplee <[email protected]>
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 |
Adds MountFrom and OnMounted to CopyGraphOptions. Allows for trying to mount from multiple repositories. Closes #580 I think this is a better approach than my other PR #632 Signed-off-by: Kyle M. Tarplee <[email protected]>
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.