Make repository/registry replacement optional

[maxvt-tonal]

Hi and thanks for offering the tool to the public!

I am trying to fit it to a specific use case, and I'm concerned about the repository/registry replacement feature: to me it seems to assume both a very specific use case and a bitnami-specific convention of creating the Kubernetes image parameter from registry, repository, and image parts. Would you consider making repository/registry rewriting optional?

For the convention, the split between repository/registry/tag is not universally used and is not a Kubernetes primitive in the API. I've noticed this convention in many (if not all) bitnami charts, but it's nowhere to be seen in many other charts, and we don't use this convention currently.

For charts that don't use this convention, I wouldn't want automatic rewriting to happen--but it is mandatory to specify it and if we use these keys they will get replaced--regardless of whether the chart follows this convention or not.

For the use case, it seems assumed by the design of this tool that a sync operation would only work on charts having the same repository (since only one replacement string is possible), probably on only a few versions of the same chart at a time. This is not, in the general case, the situation -- a museum can contain many local and 3rd-party charts, referencing many different images and repositories. Syncing the entire museum in this case is unlikely to produce a functioning copy.

Perhaps this is tailored to fit a specific bitnami's workflow, but this tool would be more generally applicable (for example, if I want to make an exact backup; if I want to reuse a registry across two museums, or if different registries are used at the same time; if I want to process a batch of charts using different repositories) if this replacement functionality was made optional. Would you consider such a change?

[slushysnowman]

I'm having this issue at the moment, I'm looking to sync a ton of helm charts to our Harbor registry, and modify the images to be pulled from a proxy cache repo in Harbor. But the images all use different repos.

For example if you look at the values for this chart

Some images use k8s.gcr.io/provider-aws/ as repo, some use k8s.gcr.io/sig-storage/

In my .yaml for the sync I have:

target:
  containerRegistry: $REGISTRY
  containerRepository: k8s-nspaas/provider-aws
  repo:
    kind: OCI
    url: $REGISTRY

But this means all the image repos get modified to use provider-aws, which results in the helm chart failing to deploy as it's the wrong repo for some of the images.

Is there a way around this?

[marthydavid]

+1 for that.

In my use case I have configured containerd + harbor with pull through cache for the required registries so no need to relocate the images.

[yankay]

+1

[migmartri]

Hi @maxvt-tonal

It's true that charts-syncer was implemented around a set of conventions existing in the Bitnami Charts but a new mode of operation was added later on. This new mode adds support to a) relocation not only of the Helm charts but also its container images and b) custom rewrites definitions in the values.yaml file.

You can find some information here, but basically the way it works is by looking into an additional piece of metadata (.relok8s-images.yaml) inside your Helm Chart that defines how the FQDN of the images are mapped in the values.yaml.

Underneath it uses this other tool (relok8s) to make the relocation/rewrite. So if you manage to make your Chart work with relok8s, you can then use chart-syncer too.

Let me know if you happen to give it a try, I am eager to get your take on it.

Thanks!

[jotadrilo]

Hi @maxvt-tonal,

#153 should have provided a fix for this issue. Can you confirm it?

[maxvt-tonal]

Hi @jotadrilo, I won't get to test this in the near future, so feel free to close this issue if there's a code change incoming to improve the scenario.

[jotadrilo]

FTR, from v0.17.0, charts-syncer is compatible with this scenario.