Skip to content
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

copy/single: accept custom *Options and wrap arguments in copySingleImageOptions #2050

Merged
merged 3 commits into from
Jul 21, 2023

Conversation

flouthoc
Copy link
Contributor

After #2048 there is no room for copy/multiple to pass custom options to copySingleImage while processing each instance, following PR introduces that functionality again and wraps options to simpler struct.

Needed by: #1987

@flouthoc
Copy link
Contributor Author

@mtrmac @vrothberg PTAL

copy/single.go Outdated
@@ -30,6 +30,7 @@ import (
// imageCopier tracks state specific to a single image (possibly an item of a manifest list)
type imageCopier struct {
c *copier
options *Options
Copy link
Collaborator

Choose a reason for hiding this comment

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

copier already contains an options pointer. Why is a separate option struct passed around now?

If imageCopier has two sets of options, there should be a very good documentation for when to use which ones.

I guess that two options pointers are unnecessary; if imageCopier should deviate from the global options in some way, make that deviation a part of the new singleImageOpts.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I’m sorry, the motivation was clearly explained in a commit message.

Yes, in that case, let’s make only the compression format difference new fields in copySingleImageOptions, instead of a full copy, with the intent ambiguities (and, much less important, the overhead of having to make a copy of the large copy.Options struct).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should copySingleImageOptions include only compression fields or entire DestinationCtx, for instance see copy/single.go its using DestinationCtx directly at lot of places, I'm thinking of including a custom DestinationCtx in copySingleImageOptions and then in imageCopier as well so other helpers can use it.

Copy link
Contributor Author

@flouthoc flouthoc Jul 21, 2023

Choose a reason for hiding this comment

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

I am not sure if DestinationCtx should reflect custom compression at all places in copy/single.go or not. Maybe I need to verify that ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nvm I think DestinationCtx is not needed only compression should be enough.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Just the compression parameters, I think. Practically, copy/multiple.go does not need to create a copy of DestinationCtx just like it shouldn’t need to create a copy of Options.

It does make sense to reason that if SystemContext contains compression choices, and we are passing SystemContext to transports, then we should update the SystemContext with the chosen compression — but transports do not care (and must not care! they must write the data in PutBlob without modification for the manifest to be valid); SystemContext.Compression… is only used in c/image/copy, so creating an updated clone is, I think, unnecessary.


The history is that c/image was originally just code in a Skopeo CLI tool, where IIRC CLI parameters were just global variables. When we split c/image into a separate project, we shuffled those values to a single global SystemContext rather than restructure the option passing completely.

Nowadays, basically SystemContext exists primarily so that c/image/copy can be generic code which doesn’t know much about transports options, and callers can still set options for the transports; I’m trying to (very slowly) move isolated c/image subpackages away from using SystemContext for options, compare e.g. signature/simplesigning[1]. In that sense, passing the compression choice in DestinationCtx and not directly in Options is plainly not something we would do nowadays.


[1] (but also, see how much more code doing it the modern way is, compared to just adding a field to SystemContext)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

SGTM

copy/single.go Outdated Show resolved Hide resolved
copy/single.go Outdated Show resolved Hide resolved
copy/copy.go Outdated
@@ -251,7 +251,11 @@ func Image(ctx context.Context, policyContext *signature.PolicyContext, destRef,

if !multiImage {
// The simple case: just copy a single image.
single, err := c.copySingleImage(ctx, c.unparsedToplevel, nil, false)
singleImageOpts := copySingleImageOptions{unparsedImage: c.unparsedToplevel,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Non-blocking: In the three callers, I think inlining the struct constructor would be a tiny bit more readable — it would be clear that the data is single-use and readers wouldn’t have to worry about future uses of singleImageOpts.

@flouthoc
Copy link
Contributor Author

I'll rebase on final review.

copy/single.go Outdated Show resolved Hide resolved
copy/copy.go Outdated Show resolved Hide resolved
copy/single.go Outdated Show resolved Hide resolved
Create a wrapper around arguments of `copySingleImage`

Signed-off-by: Aditya R <arajan@redhat.com>
After containers#2048 there is no room for copy/multiple to pass custom compressionFormat to copySingleImage
while processing each instance, following PR introduces that functionality again and wraps options
to simpler struct.

Signed-off-by: Aditya R <arajan@redhat.com>
If its a regular copy callers might not set `compressionFormat` and
`compressionLevel` in such case still honor compression which is set in
DestinationCtx from copier.

Signed-off-by: Aditya R <arajan@redhat.com>
Copy link
Collaborator

@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

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

Thanks! LGTM.

@@ -40,6 +40,12 @@ type imageCopier struct {
requireCompressionFormatMatch bool
}

type copySingleImageOptions struct {
requireCompressionFormatMatch bool
compressionFormat *compressiontypes.Algorithm // Compression algorithm to use, if the user explicitly requested one, or nil.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
compressionFormat *compressiontypes.Algorithm // Compression algorithm to use, if the user explicitly requested one, or nil.
compressionFormat *compressiontypes.Algorithm // Compression algorithm to use, if the caller explicitly requested one, or nil.

for future reference

type copySingleImageOptions struct {
requireCompressionFormatMatch bool
compressionFormat *compressiontypes.Algorithm // Compression algorithm to use, if the user explicitly requested one, or nil.
compressionLevel *int
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
compressionLevel *int
compressionLevel *int // only used if compressionFormat is set

@mtrmac
Copy link
Collaborator

mtrmac commented Jul 21, 2023

Thanks again!

@mtrmac mtrmac merged commit 30c87d4 into containers:main Jul 21, 2023
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants