-
Notifications
You must be signed in to change notification settings - Fork 547
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
Allow cosign save
to reuse save directory to help dedupe shared layers.
#3239
base: main
Are you sure you want to change the base?
Conversation
adjust load to handle multi-image index from save fix image index bug - save and load fix image ref trunc issue export oci.layout constants to use with oci.remote slightly clean up test Signed-off-by: Adam Martin <[email protected]>
Co-authored-by: Jacob Blain Christen <[email protected]> Signed-off-by: Adam Martin <[email protected]>
Co-authored-by: Jacob Blain Christen <[email protected]> Signed-off-by: Adam Martin <[email protected]>
Signed-off-by: Adam Martin <[email protected]>
Signed-off-by: Adam Martin <[email protected]>
Codecov Report
@@ Coverage Diff @@
## main #3239 +/- ##
==========================================
- Coverage 30.37% 30.36% -0.01%
==========================================
Files 155 155
Lines 9835 10117 +282
==========================================
+ Hits 2987 3072 +85
- Misses 6402 6587 +185
- Partials 446 458 +12
|
Signed-off-by: Adam Martin <[email protected]>
642f107
to
274c2a3
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.
Hey @amartin120 thanks for contributing this! I had a couple thoughts:
- Instead of a
--registry
flag on load, maybe it would make sense to take a regex on the image name? That way you could say something like "load all the images" or "load all the images from a specific registry" - Would you mind adding an e2e test similar to this one to test this new functionality?
I wasn't able to find anything specific in the oci-layout spec which says that storing multiple images in index.json
is valid. If you have any pointers for that it would be helpful. Otherwise though, I read through this github thread and it seems reasonable to me.
Let me know if you have any questions. Thank you!
Hello @priyawadhwa. Thanks for the feedback!
I'm looking at this from a scenario where I'm ...
So with that I kind of need to specify the registry when the load command is called. Does that help? I'll get to work on those e2e tests a.s.a.p. |
@amartin120 thanks for the explanation, I think I misunderstood before what the We have this environment variable we use to signal pushing signatures to a different registry called WDYT of reusing that instead of the flag? |
I'll take a look at |
@priyawadhwa I apologize for the delay. We could still reuse Hopefully I'm understanding things correctly here. Thanks for your patience. |
Signed-off-by: Adam Martin <[email protected]>
Signed-off-by: Adam Martin <[email protected]>
Signed-off-by: Adam Martin <[email protected]>
Signed-off-by: Adam Martin <[email protected]>
@amartin120 no worries, I think we can just go ah we can keep the flag since it seems more accurately named and more intuitive. I can take a look at this once CI is green! |
@priyawadhwa Thank you. I may need some help with the CI. Both of the failing stages look like timeouts as opposed to true failures. Am I reading the logs right? |
@amartin120 I think the linter is picking up some things that need to be fixed! If you go through the files on this PR it should be visible in the Github UI:
|
Strange. Those were not showing on the PR when I responded originally. Maybe a Github hiccup at the time? Maybe I was just blind? The logs just showed timeouts. Oh well. I'll work on this today now that I can see them. Thanks again for the patience. |
Signed-off-by: Adam Martin <[email protected]>
Oh, hey! All checks are all passing. Any objections to merging this @priyawadhwa? |
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.
Thanks for your patience, I left a few comments!
Short: "Load a signed image on disk to a remote registry", | ||
Long: "Load a signed image on disk to a remote registry", | ||
Example: ` cosign load --dir <path to directory> <IMAGE> OR cosign load --dir <path to directory> --registry <REGISTRY>`, | ||
//Args: cobra.ExactArgs(1), |
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.
nit: we should probably delete this
// WriteSignedImageIndexImagesBulk writes the images within the image index. | ||
// Bulk version. Uses targetRegistry for multiple images/sigs/atts. | ||
// This includes the signed image and associated signatures in the image index | ||
func WriteSignedImageIndexImagesBulk(targetRegistry string, sii oci.SignedImageIndex, opts ...Option) error { |
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 wonder if we could refactor the copy command here, which will handle copying over the image and any signatures/attestations associated with it, rather than having to do it manually here.
Right now the copy
takes a source image and a destination image as a string. We could look into pulling out the copy logic into a reusable function which takes a SignedEntity
and passing through to that here?
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.
Good thoughts. Let me look into this more.
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.
My only concern for the copy command logic is the usabiltiy in an air-gapped situation where cosign may not be able to reach the source image in its original registry/repo. Will the copy
mechanics work if the SignedEntity
is what's on local disk via cosign save
?
Apologies if I'm way off here. I'm just making sure that I understand.
Signed-off-by: Adam Martin <[email protected]>
Signed-off-by: Adam Martin <[email protected]>
This PR is almost a year old with no activity. Bumping for visibility to see if we can get some traction. This is a much needed feature to help bloat when using multiple images. |
Summary
When using
cosign save
with dozens, or in my case, hundreds of images, the storage consumption can really add up with each image requiring their own directory. There's potentially a case where images can share layers so this change allows for thecosign save
function to be able to reuse a directory from a previous save and just build on theindex.json
along with an additional annotation for each entry to aide with the correspondingcosign load
.From there, I've modified
cosign load
to have a new optional flag--registry
where you can specify a registry to load all of the images to from a single directory. In cases where you are only dealing with a single image, the load command would function exactly how it does today where you just provide the remote reference via the cli.Release Note
cosign save
to append the index.json if pointed at a--dir
used in a previous save.org.opencontainers.image.ref.name
annotation to the index.json for clarity and to help withcosign load
in cases where the directory is reused.cosign load
to have an optional flag called--registry
that can be used in cases where the index.json from a save contains multiple images. This handles being able to control where the images get loaded to in the case where providing a single ref via the CLI no longer makes sense. If you don't provide the--registry
flag, thecosign load
command will continue to function as it does today.Documentation
Example usage:
cosign save image1:v1.0 --dir ~/saves
cosign save image2:v1.0 --dir ~/saves
cat ~/saves/index.json
cosign load --dir ~/saves --registry your.registry.com