imgpkg-003 Rename images when copying bundles #22
Conversation
pivotaljohn
changed the title
Add title for some Use Cases with this proposal Add description of the Overrides section of the CopyWithRename structure Reply to some open questions Add one more reason for not having this implemented from the beginning
Add new matching capability Add implementation split into phases Add ECR Repository creation constraint Change names of the strategies to be easier to understand
Add a new Use Case to ensure `imgpkg` can tag images when copies them Add requirement for `kbld` to add annotations when creating ImagesLock Add functions to `ytt` starlark library to allow check for tags and retrieve the registry location for an image
Add more schema information about types and what fields are required Answer one question Update the name of the matchers to keep consistency with `kbld` Add note about not allowing `overrides` and `mappingFunctionYttStar` to be present in the same configuration
- Make more clear some restrictions - Rewords parts of the proposal - Correct some notation
This will remove the Registry information from the strategy configuration file
| strategy: MaintainOriginRepository | ||
| overrides: | ||
| - image: public-reg.io/exact-app@sha256:aaaaaaa | ||
| destinationRepo: myname/exact-app |
There was a problem hiding this comment.
I am a bit confused here based on the above discussions. Will this override result in the image being found at destination.io/myname/exact-app? What happens when a user copies with the destination as destination.io/my-namespace because of the above behavior? Would the image be located at destination.io/my-namespace/myname/exact-app or destination.io/myname/exact-app?
It feels like we have a partial definition of what constitutes the repo portion of a url, which is resulting in us having three different meanings for the term based on where it is used:
imageRepomatcher - should contain full url which has registry, namespace, and repodestinationRepo- shouldn't contain registry but is allowed to contain both namespace and repo- Preserved repo when using MaintainOriginRepository - only recognizes last portion of url as repo (drops namespace and registry which are included in above defs)
My understanding is that repo is the last segment of the url. For example, based on the terminology section, I would expect index.docker.io/_/nginx@sha256:... to have:
- registry: index.docker.io
- namespace: _
- repo: nginx
- image: sha256...
This understanding may be incorrect (and potentially harder to implement because ggcr doesn't have the idea of namespace iirc) but if it is, I think it should be clarified and made consistent wherever the terms are used or else users will have no way of knowing how we've chosen to define repo in a particular location.
There was a problem hiding this comment.
@ewrenn8 I made some changes to the verbiage of the full proposal and tried to make it consistent. Please check it out and if it looks good, please resolve this issue
- Add Use Case for the replicated registry - Add question about replicated registries
Change the way Destination field works
| ``` | ||
|
|
||
| When copying a Bundle to `destination.io/bundle` all OCI Images will be copied | ||
| to `destination.io/{Original Repository Name}` |
There was a problem hiding this comment.
Again, what's the command, and where's destination.io coming from?
There was a problem hiding this comment.
Now I see the examples below, but not the imgpkg command, so not so obvious.
|
|
||
| Function will remove all information from an OCI Image location and return the Image name. | ||
|
|
||
| Definition: `def imageName(image) -> string` |
There was a problem hiding this comment.
Interesting as above this is described as the Repository (although I find that name confusing and I like better image name).
|
Is there a way to capture in the ImagesLock file (or in a resulting file) the result of the copy so that it can be tracked? Source image, destination image and strategy used on copy.? |
- Add commands to show how to use the configuration file - Better explain the exact mathc by tag
- Add Image that helps with terminology - Convert strategy name `MaintainOriginRepository` to `RelativeToRegistryKeepNamespace`
joaopapereira
force-pushed
the
003-copy-bundles-with-rename
branch
from
39504bf
to
3350097
Compare
Strategies: - Copy all OCI Images to the new Registry and all paths are relative to Bundle Namespace and keeps Image Namespace - Copy all OCI Images to the new Registry and all paths are relative to Bundle Namespace
| `corp.gcr.io/projects/project-a/bank-app:v1` explodes into: | ||
|
|
||
| - **Registry** (`corp.gcr.io`): Server that will be used to store and retrieve OCI Images | ||
| - other examples: goharbor.io, gcr.io, index.docker.io |
There was a problem hiding this comment.
may be we should add foo.com/blah as another example of registry to indicate that it's not only hostname.
|
|
||
| **Note:** `overrides` and `mappingFunctionYttStar` cannot be present at the same time in a configuration. | ||
|
|
||
| #### Copy Strategies |
There was a problem hiding this comment.
i think it would be useful to have RelativeToBundleDashedFullImageName:
blah.com/some/ns/image-name would become registry.com/another-ns/some-ns-image-name
this would better help with cases where multiple unrelated images are called controller.
There was a problem hiding this comment.
It was mentioned that it could be useful to provide "portable" configuration (i.e. be able to use the same config for multiple imgpkg copy invocations, each targeting a different registry)...
Would we be able to detect when a copy fails because namespaces aren't supported? If so, we could get closer to that portability goal if RelativeToBundleKeepNamespace first attempts with the namespace, as is... and if it fails in a definitive way, could downshift to the dashed image name?
There was a problem hiding this comment.
I think that the fact that there's a new strategy RelativeToBundleDashedFullImageName almost similar to an existing one RelativeToBundle to me denotes that multiple variations of strategies will come, and not just to one, but to many, so eventually there will be a explosion of strategies to cope with this subtleties. I would recommend not adding so many strategies but adding additional configuration to the strategies, e.g:
apiVersion: imgpkg.carvel.dev/v1alpha1
kind: CopyConfig
strategy: RelativeToBundle
keep: Namespace|Image|Repositiry
dashed: Namespace|Image|Repository
So that with some additional attributes you can get multiple different strategies.
- Correct the ImagesLock yaml - Enumerate the strategies for better visibility - Start using ytt modules, instead of create things like regexMatch. Since we will have access to these module we can take advantage of all of them
joaopapereira
added
the
proposal
|
Any update on this? Would still be great to see. |
Updates to kapp example workflow content
A proposal based on the following issues:
carvel-dev/imgpkg#60
carvel-dev/kbld#79