search

vmware-labs / distribution-tooling-for-helm

Helm Distribution plugin is is a set of utilities and Helm Plugin for making offline work with Helm Charts easier. It is meant to be used for creating reproducible and relocatable packages for Helm Charts that can be moved around registries without hassles. This is particularly useful for distributing Helm Charts into airgapped environments.
Apache License 2.0
71 stars 12 forks source link

unwrap/relocate option to allow values.yaml relocation to a different custom registry/repository #93

Open machecazzon opened 3 days ago

machecazzon commented 3 days ago

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

For my current use case using Google Artifact Registry (GAR)

With this unwrap happens to go against writer repo but I would like to have values.yaml (only) relocated and pointing not to the writer repo but the reader repo so that no further "overrides" are required to consume the chart images

I have made some local modifications to have this working with one additional flag in relocate / unwrap commands e.g --values-repository

helm dt charts relocate test-chart1 acme.com/federal --values-repository acme.com/read
helm dt unwrap kibana-10.4.8.wrap.tgz acme.com/federal --yes --values-repository acme.com/read

Then i can just consume the chart from the reader repo and chart values registry / repository are pointing to acme.com/read instead of acme.com/federal as a result of --values-repository being set to that value.

helm pull oci://acme.com/read/kibana --version 10.4.8

Is this something that could be added into the tool or any other recommendation on how to best achieve this?

Thanks

Describe the solution you'd like

Have an option to customise the relocation command for chart values and be able to set a different repo for the values.

Describe alternatives you've considered

No response

Additional context

No response

machecazzon commented 3 days ago

One thing I've noticed is that probably will want to modify Images.lock (and perhaps chart annotations as well) in order o that a future wrap from the "reader" repo pulls images over the reader as well.

Right now seems to work fine modifying Images.lock to the --values-repository value

mpermar commented 2 days ago

This is a good use case @machecazzon and reasonably common I believe. I think it makes sense what you are doing but I would approach it slightly differently. In my mind, what want dt to do is business as usual but just being able to customize the target repository for the push command.

So for example, to me it makes sense something like:

helm dt unwrap kibana-10.4.8.wrap.tgz acme.com/read --push-repository=acme.com/federal --yes

And that in essence is just the same as the tool does today but with a new parameter to customize the write repository.

The other command that would need to be changed is images push. And I'm thinking verify could need some tweak to skip verification if somehow the read repository does not have access, but I believe skipping that was already supported although I'm writing this from the top of my head.

It looks like you already have some code. That's good because we don't have much capacity right now to take requests but I think we would more than happy this change. It's a good use case.

machecazzon commented 1 day ago

Thanks @mpermar for the guidelines. Yes I have some code working with my first implementation and i am good with it so far but will definitely try rework it and follow the approach you recommend and push something.

I had a look into doing it more and less that way when I first attempted to have a fix but the code path changes looked to be more evolved and not as easy as i did so I decided to turn left and not right.

Perhaps next week I am able to have something that I am happy to contribute. Thanks