carvel-dev / imgpkg

Store application configuration files in Docker/OCI registries
https://carvel.dev/imgpkg
Apache License 2.0
263 stars 62 forks source link

add command to copy bundle referenced images to registry where bundle already resides #37

Open cppforlife opened 3 years ago

cppforlife commented 3 years ago

Describe the problem/challenge you have

Describe the solution you'd like

currently one would have to do the following:

this seems a bit repetitive. proposed steps:

i think having an explicit flag like --to-same-bundle is good to avoid confusion of now specifying anything for other from-to pairs.

Anything else you would like to add:

this "promotes" the use case for ensuring i have all materials for the bundle in my registry to first class.

this might be also useful to "repair" bundle in your registry if some references images got deleted.

ewrenn8 commented 3 years ago

I wonder if it makes more sense to have it as a flag on push, so user could just do something like: imgpkg push -b docker.io/... -f my-bundle --with-relocate

cppforlife commented 3 years ago

i was thinking about that, but id would prefer to keep push and copy distinct. seems like a good boundary to have.

joaopapereira commented 3 years ago

In this case, I tend to agree with @ewrenn8. Feels more natural that the operation you want to do when pushing your bundle is to concentrate the layers from a particular bundle under the same repository.

Also thinking about copy in itself not sure if the operation is the one we want to relocate the full bundle underneath a repository. Maybe we want a new operation called concentrate or centralize or condense not sure.

@cppforlife Did you come across a use case for this feature?

cppforlife commented 3 years ago

Did you come across a use case for this feature?

described in "Describe the problem/challenge you have". wanna ensure that that my app doesnt depend on images outside of my registry so they dont break production if they disappear.

Feels more natural that the operation you want to do when pushing your bundle

possibly. though this might be useful after you pushed a bundle as well as a distinct step. eg what if you "forgot" to push with that flag. including a flag on push is a convenience feature, but we need to make sure we have "core" feature that's available standalone.

Maybe we want a new operation called concentrate or centralize or condense not sure.

i was thinking it's part of copy command because that's what happens when we copy bundle to a different registry. it just happens that in this case we are "copying" to the same location.

danielhelfand commented 3 years ago

My thought is that the flag makes sense for both the push and copy commands and should be consistent for both. I personally prefer --with-relocation. The flag would only work with pushing/copying a bundle. I would think push would be the more common use case though.

At the very least, I think we should accept the issue and discuss the UX further.

cppforlife commented 3 years ago

--with-relocation

one note, we tried to avoid word relocation because we arent relocating anything (this is how we ended with "copy" word as a command).

voor commented 3 years ago

Comment from slack discussion on this issue:

(side note: now that we are also having dicsussions around copy config, im more convince that this should be a variation of copy command to avoid having to put all kinds of copy flags on push command)

This makes sense to me, since you are technically copying your config from your local directory to a repository along with the associated images.