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

relocate directly to target registry wihout intermediate bundle #80

Open
migmartri opened this issue Jul 31, 2024 · 3 comments
Open

relocate directly to target registry wihout intermediate bundle #80

migmartri opened this issue Jul 31, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@migmartri
Copy link
Contributor

Is your feature request related to a problem? Please describe.

I am relocating a Chart and its associated container images to a target registry via the wrap/unwrap flow.

Is there any way to do the same but without requiring to pull first the images to a local tarball? the dt relocate command seems to just rewrite the references not push the container images.

Describe the solution you'd like

Relocate source -> target in one command without pulling data to an intermediate wrapped tarball.intermediate-wrapped

Describe alternatives you've considered

No response

Additional context

No response

@migmartri migmartri added the enhancement New feature or request label Jul 31, 2024
@mpermar
Copy link
Contributor

mpermar commented Jul 31, 2024

There is no such single command indeed. Yes, it would be nice to have a dt move or something like that that runs the complete flow. As you noticed, relocate only does the rewiring. I guess we haven't do it because charts-syncer works well for the team but contributions are welcomed!

Alternatively, it should be easy to have an alias that just runs the few commands together pull, relocate, push...

@migmartri
Copy link
Contributor Author

migmartri commented Aug 4, 2024

Thanks, @mpermar, for the response.

I guess we haven't do it because charts-syncer works well for the team but contributions are welcomed!

So, does the Charts syncer perform the relocation of both the chart and container images without an intermediate wrap file?

Alternatively, it should be easy to have an alias that just runs the few commands together pull, relocate, push..

Thanks, but there are other motivations for this issue. The problem is that we run this command multiple times per day, but we do not release that often, so technically, these relocation processes should be quick no-ops.

But today, because of how wrap/unwrap seems to work (and please correct me if I am wrong), we are performing a multi-GB download + compression process to uncompress and discard it most times. This translates a bigger compute, disk, and networking footprint in our GitHub actions billing.

It feels like the tool could have a direct source-destination mode that could, from top of my head:

    1. Download the chart
    1. Resolve the images, either from lock file or dynamically through annotations and such as you do today.
    1. Check if the image exists in the destination repo and push it otherwise (nitpick: if I remember correctly, it's possible to stream between two registries).
    1. there is no need to create a tarball
    1. Re-package the chart and push it (I believe you might not be able to know if the chart exists since, if I remember correctly, the digest changes on each helm package)

The new steps for this direct mode are 3 and 4, an optimization that should take a process that takes minutes today to seconds.

In any case, this is not a blocker for us. We might end up resolving/pushing the images ourselves and then calling relocate to rewire the chart manually. But it feels like a good addition to the already useful tool.

Thanks

@mpermar
Copy link
Contributor

mpermar commented Aug 24, 2024

I don't think there is any way to instruct a registry to push into other registry. Tools like crane make it look transparent but they are pulling the bits to memory before pushing. It could be a nice feature though. No question.

Right now we don't have the capacity to do it, but PRs are more than welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants