@timoreimann,

Mind if I get some feedback on the above before continuing?

Re: the location: one interesting question in this context is how the new Helm chart will relate to the static Kubernetes release manifests we currently maintain below the releases/ directory. Not sure if there's a canonical approach on how to go about it, personally I have a seen both of the following in the wild:

1. A Helm chart is used to generate a default set of release manifests (that is committed to the repo)
2. Only a Helm chart exists, and users are expected to run it to generate release manifests on their own

I'm slightly leaning towards (1) in order to not make Helm a hard requirement to install CCM, at least not for now. In that vein, it could make sense to move the charts/ directory below releases/ so that the two are more co-located. @vyas-n any thoughts / prior experiences on your end?

Re: the initial two variables: that looks good to me. 👍

(The full Helm adoption should probably cover using Helm for the release as well, meaning we'd want to update our Github Actions workflows. That's not something we need to do in this PR though, and it can also be done by someone else.)

Thanks @timoreimann,

The placement of the helm chart code tends to be developer preference since the resulting artifact is usually hosted separately from the code repository anyway.

I'll go ahead and move the charts folder into the releases directory, create a starter Readme.md, and add some validation in the GitHub Actions CI 👍

@vyas-n sounds good, thanks!