Hello community!
I’d like to gather your thoughts on the CHT’s current Helm charts and deployment scripts, as well as your usage of these tools, and explore what a more maintainable and community-friendly setup could look like.
A Helm chart inside the tests/helm folder, which is used to run integration tests on k3d.
A cht-deploy script inside the scripts/deploy folder that deploys cht-core instances using the medic/helm-charts repository.
Then, the medic/helm-charts repository contains a mix of charts for:
cht-core (v4.x)
User management
Observability
The Challenge
This mix has grown organically over time and includes some tightly coupled and specific use cases (e.g., cht-chart-4x includes hardcoded AWS EKS configurations). It’s functional, but it may not be the easiest for the community to reuse or contribute to, and it’s becoming harder to maintain.
What I Suggest
After reflecting on this (and discussing it with a few teammates), I’m wondering if a better approach would be to create a simplified, general-purpose Helm chart directly inside the cht-core repo. This chart could:
Be reusable both for tests and actual deployments.
Serve as a clean, minimal base chart that other use cases (like observability or user management) could layer on top of, if needed.
Be easier to maintain and align with core development.
Do you see value in moving toward a more unified and minimal Helm chart inside cht-core?
What would the path toward that look like, in your view?
Any lessons learned or challenges you’ve encountered when managing Helm-based deployments of cht-core?
This is at the idea level, and your input could really help shape the direction we take. I’d love to hear both from community members who have used the charts for deployments and from those who’ve contributed to maintaining them.
Do you see value in moving toward a more unified and minimal Helm chart inside cht-core?
I see a huge value in a unified minimal chart, but there are some nuances on where it should reside:
A pro of having the chart inside cht-core would be increasing the visibility, and making production deployment setups part of the mono-repo.
Some cons are we lose the helm repo that the current GitHub - medic/helm-charts repo provides us, and the chart-releaser functionality. Something else to think about is ensuring template modifications dont trigger a wide variety of tests if everything is inside cht-core.
Any lessons learned or challenges you’ve encountered when managing Helm-based deployments of cht-core?
Deploy script modifies underlying helm values and templates. Both should be separate and stand-alone.
Sometimes there are config, variable, template changes, or resource constraints that don’t make it into helm charts for production since the templates weren’t involved in testing or dev phases.
I believe one major flaw in having helm charts separate from cht-core is that there is no versioning, or versioning has to be handled by some additional mechanisms that are not straightforward (at least not to me). I’m thinking about a scenario where we add a new service in cht-core, or we remove one, and needing to update the helm charts to reflect the change. Even adding an additional environment variable, enough that the helm charts are not backwards compatible with other versions of the CHT.
I believe we should not invest in this effort, of maintaining backwards compatible helm charts.
I think the simplest way to achieve this is to release version-specific helm charts along with the cht-core release, possibly in the form of a zip attachment to the release document, just like we release docker compose files, and host the template helm charts in the cht-core repo.
Something else to think about is ensuring template modifications don’t trigger a wide variety of tests if everything is inside cht-core.
I believe this should not be an issue, running tests for helm charts, especially when they will get used as part of the e2e test suite for k3d.
Thank you all for the valuable feedback! I particularly agree with @diana suggestion about version-specific Helm charts — this approach would address several key issues we’ve been facing with the current setup.
I have created a ticket in the cht-core repository to plan the implementation of version-specific Helm charts. Lets continue the conversation there.
We’ll leave the existing medic/helm-charts/cht-core-4x as-is for backward compatibility, while focusing future work on the charts in cht-core.
