Can we improve containerd Helm values in cluster chart and how much time would it take?

[nprokopic]

This existing API is not really good, it's a bit hard to expand it now with local registry mirrors (will add more details from Slack thread).

global:
  components:
    containerd:
      containerRegistries: {}

The issue happens with containerRegistries value, so maybe instead of introducing a breaking change here, we could deprecate the old containerRegistries value and add a new one called just registries.

So this would be the new API:

global:
  components:
    containerd:
      registries: {}

And a cluster would use either new improved registries API (if it is set) or old containerRegistries (if new registries API is not set).

Naming this new Helm value registries is just an example. We should check the structure of containerd configuration file and then design an API nicely aligned with containerd config, so when you see containerd Helm values you can easily tell where and how those are used in containerd config file.

[nprokopic]

cc @uvegla

[uvegla]

I would also decouple authentication from the registry / mirror configuration. That is how the containerd config file is structured and my main issue I found now is that if you want to mirror multiple registries with a single (cache) registry, like lets say Zot - but could be anything - and lets say that (cache) registry is authenticated now the current structure implies that you should set the credentials section for each instance. If you do, it will be generated into the config.toml multiple times for the same registrys auth section and will result in an invalid containerd config failing to boot up the service and thus the whole node and cluster.

[weatherhog]

@uvegla we are watching this issue, is there a way forward or can this be closed?

[uvegla]

This should be Turtles board and implemented there as an improvement. I believe this is still valid.

[weatherhog]

moving this to @giantswarm/team-tenet as the successor of @giantswarm/team-turtles