Provide a helm chart that provides the Peering CRD's for downstream chart dependencies

[tylerauerbeck]

Problem

We currently have the need to pull in the peering CRD's contained in this repository as a dependency of our application deployment. We are using a helm chart to deploy our application, so would like to be able to pull in these dependencies as a seperate chart (i.e. a chart consisting of the two CRD's in this repository).

**Are there existing features close to solving this problem? Why don't they work? **

Because of how helm dependencies work, it doesn't appear that there is anyway to just source the manifests directly and it is expected that they are packaged as a helm chart themselves.

Proposal

We are currently maintaining a chart ourselves here: https://github.com/redhat-cop/helm-charts/tree/master/charts/kopf

We were interested in whether this is something the community would be interested in and if there is any interest in hosting this chart in this repository (or a seperator repository upstream)

As part of a chart that has these dependencies, we can do the following in Chart.yaml

dependencies:
  - name: kopf
    version: 0.1.0
    repository: https://redhat-cop.github.io/helm-charts

Checklist

• [ ] Many users can benefit from this feature, it is not a one-time case
• [ ] The proposal is related to the K8s operator framework, not to the K8s client libraries

[nolar]

Hello. Thanks for this proposal. Truth be told, I never used Helm, only read the docs, so I do not know what is the best way to organise charts and what are the typical conventions for naming/structuring the chart repos, therefore I have no opinion on this topic.

What I see from some sample charts from artifacthub.io, they all host their own repos probably built from/via GitHub Pages. I've got the domain name kopf.dev for Kopf, so probably can make https://charts.kopf.dev/ for charts.

This, in turn, probably implies a separate repo for these charts, incl. peering. It might be put into the GitHub org that I've reserved for Kopf but not populated with repos yet (this nolar/kopf repo will move there eventually; no specific plans yet — building an ecosystem and a community is hard).

I would prefer to keep this repo (currently, nolar/kopf) only for the core Python library for now, while keeping all specialised supporting repos for different environments separately. Though, I am not sure this is the right and/or the only way. Maybe "one repo to rule them all" is also a good approach.

What do you think? Any advice on the repo structure is welcome!

---

On a side-note: I plan to implement something like "Kopf SDK" with YAML generators, incl. Helm charts for Kopf-based operators. The peering crds can be made a part of those generated charts, side by side with the deployments, rbac, crds of the specific Kopf-based operators — or as a dependency (so that 2+ Kopf-based operators could co-exist with no conflict). The solution should take these plans into account.

[eshepelyuk]

jFYI

1. There is no need to use GH pages workaround for hosting Helm chart. They can be put into GH packges OCI container repo (as well as docker images) https://docs.github.com/en/packages/learn-github-packages/introduction-to-github-packages
2. Having separate repo for a chart / charts apart of main code is a good idea. Since chart usually has own release lifecycle - it is easier and rather clear to maintain them both from different repos.