Add Streamshub Console Helm charts proposal

[jankalinic]

This PR adds a proposal for introducing official Helm support for the StreamsHub Console operator and Console CR.

[aswinayyolath]

This is a great addition to the ecosystem! Regarding the CRD management strategy, since CRDs in the crds/ directory are ignored during helm upgrade, there’s a risk of version drift where hte new operator expects a schema (or a new stored version) that isn't present in the cluster.

[aswinayyolath]

given that the Kustomize proposal previously flagged this limitation, should we formalize a strategy for CRD lifecycles? Options like a dedicated crds sub-chart or a job-based upgrade hook might help ensure that the operator's reconciliation logic doesn't fail after a routine helm upgrade.

[jankalinic]

Valid concern, and one that the Kustomize proposal also surfaced. Would be good to align it to stay consistent here.

[aswinayyolath]

Helm dependencies (Chart.yaml) can only point to other charts, not specific K8s CRs like a Kafka/KRaft CR...tp achieve the flow described, the umbrella chart would likely depend on the strimzi-kafka-operator chart, while the Kafka CRs themselves would be templates within the umbrella chart's templates/ directory.

[aswinayyolath]

This distinction is important for how we'll need to pass values down to the subcharts to ensure the operator is ready before the Kafka resources are reconciled

[jankalinic]

You're right that Chart.yaml dependencies can only reference other Helm charts, not raw Kubernetes CRs. The phrasing "declare Helm dependencies on ... " might be misleading, if that's the case i can re-phrase it. What i actually meant was:

• The umbrella chart (if it exists in the future) declares a dependency for example on the strimzi-kafka-operator Helm chart
• The Kafka CRs themselves live an example templates inside the umbrella chart.

[aswinayyolath]

Another thing that came to mind is that helm only processes CRDs from the top-level chart's crds/ directory. CRDs defined in subcharts are silently skipped during install. So if the umbrella chart declares streamshub-console as a subchart dependency, the Console operator's CRDs won't be installed automatically.

[aswinayyolath]

A common solution is to hoist all CRDs into the top-level umbrella chart's crds/ directory, or use a dedicated CRD loader job. Worth thinking through before the umbrella chart design is finalised, as it affects how the dependency structure would need to be laid out.

[jankalinic]

Good point, and one that could easily catch us out if we don't design for it right away for console (before going for the umbrella chart).

If the Console operator chart is used as a subchart of the umbrella chart, its crds/ directory will be silently ignored on install — meaning the Console CRDs won't be present when the operator tries to reconcile.

The two main options to resolve this are:

1. Put CRDs into the umbrella chart's crds/ directory — straightforward, but means duplicating CRD definitions across charts and keeping them in sync manually
2. Dedicated CRD loader job — a pre-install hook Job that applies CRDs via kubectl apply, giving more control but adding complexity

A possible third option worth considering is dedicated streamshub-crds sub-chart (similar to the pattern used by cert-manager chart), which can be installed independently from the operator chart. This keeps CRD lifecycle explicit and avoids silent skipping.

This might to be something we should decide and agree on before the umbrella chart design is create — it directly affects the dependency and install ordering.

[jankalinic]

Having reviewed the the Kustomize PR and discussions, it may be worth revisiting whether the umbrella chart is the right direction. The CRD lifecycle limitations raised there and here - upgrade skipping, subcharts and the maintenance of keeping the stack in sync across components apply here as well and add some complexity. I will try to dig deeper and try to figure out more about the Helm limitations regarding CRDs.

I think it's worth an open discussion on whether the umbrella chart belongs in this proposal, or whether it should be deferred until we have a clearer answer to those challenges.

[tomncooper]

I think this is a good idea and would make the console more accessible.

My main comment is that I think discussion of an StreamsHub umbrella chart should be removed. That should be a separate proposal in my opinion.

I think you should have a separate section on CRD management and in discussing the various options you could reference the implications of each on using this chart as a sub-chart in some potential future umbrella chart.

My personal opinion is that Helm is not well suited to managing multiple operators and a deployment system with more fine grained control would be better. However, that is a discussion for a dedicated StreamsHub Umbrella Chart proposal.

[tomncooper]

this shouldn't be a new line?

[tomncooper]

My personal view is that this proposal shouldn't discuss an umbrella chart in detail, that is really for a separate proposal. The only part I think is relevant to mention an umbrella chart is with respect to the CRD management and how different options relate to potentially being used as a sub-chart.

[tomncooper]

As I said above, I think the version numbering of the chart should not be linked to the Console version, however there should be a clear mapping documented on the release page and in the documentation.

[tomncooper]

My view is that this chart should be managed from within the console repository (just like Strimzi). Ideally there would be system tests that test the helm chart build with new versions of the Console. That way it will be easier to make sure the helm chart is kept up to date with new releases.

[tomncooper]

This is kind of my pet theory, but I think that the chart version should not be linked to the operator version, they will diverge at some point (when you need fixes in the chart only) and so you might as well start from the position that they are separate to save confusion later.

[tomncooper]

CRD management in Helm is......interesting. Personally, I think we should stick with the same approach as Strimzi (using the /crds directory) initially. This requires specific user intervention for upgrades but that is an established pattern.

I know you have mentioned a StreamsHub umbrella chart in this proposal, but I really feel that Helm is uniquely unsuited to managing multiple operator installations. I think a far better solution would be something that allows for more fine grained control, like a meta-operator (but perhaps OLM or ansible have better options).

I do think you should have specific section on CRD management and that you should discuss the various options in relation to this chart potentially being used as a sub-chart.