carvel-dev / carvel-dev/carvel
imgpkg-003 Rename images when copying bundles
- Dominant language
- HTML
- Stars
- 408
- Forks
- 148
- PR merge metrics
- No merged PRs in 30d
Description
@joaopapereira commented on [Tue Mar 09 2021](https://github.com/vmware-tanzu/carvel-community/pull/22)
A proposal based on the following issues:
https://github.com/vmware-tanzu/carvel-imgpkg/issues/60
https://github.com/vmware-tanzu/carvel-kbld/issues/79
---
@cppforlife commented on [Thu Apr 08 2021](https://github.com/vmware-tanzu/carvel-community/pull/22#issuecomment-815906327)
one late constraint ill throw that i just thought of... we should ensure that registry replication can be used with this feature. ie if bundle that uses images.location gets replicated to a different registry, ideally images.location should work in the context of that new registry (assuming that all relevant dependent images were also replicated).
---
@jorgemoralespou commented on [Tue Apr 13 2021](https://github.com/vmware-tanzu/carvel-community/pull/22#issuecomment-818708500)
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.?
---
@braunsonm commented on [Wed Jun 23 2021](https://github.com/vmware-tanzu/carvel-community/pull/22#issuecomment-867291326)
Any update on this? Would still be great to see.
Contributor guide
Research direction
Start by reviewing the linked imgpkg issue 60 and kbld issue 79, then read the discussion on community pull request 22. Clarify how image renaming during bundle copies should interact with registry replication and how the source, destination, and copy strategy should be recorded. Done requires an agreed design before implementation.
Written by the indexing model from the issue text.
Assessment
- Domain
- infrastructure, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100