Adapt chart after major kepler rewrite

[jklare]

Kepler has been recently undergone major changes as described in this announcement:

• https://github.com/sustainable-computing-io/kepler?tab=readme-ov-file#-major-rewrite-kepler-0100-and-above

In addition to rewriting the application code, a new Helm chart was added inside the Kepler repository itself here:

• https://github.com/sustainable-computing-io/kepler/tree/main/manifests/helm/kepler

Currently this Helm chart is released as tarball (named "kepler-helm-XXX") alongside every Kepler application release here:

• https://github.com/sustainable-computing-io/kepler/releases

I would propose to align the efforts here and transfer the newly written parts from the Kepler application repository to this repository. The advantages I currently see of doing that are:

• Decoupling the release process for the application and the Helm chart deploying it, allowing independent release cycles for both
• Easier code management (including reviews) due to splitting responsibilities for application code (written in go) and Helm chart development
• Simplification of the codebase, allowing users to either find the Kepler application code or the Helm chart itself

After an initial discussion on Slack (https://cloud-native.slack.com/archives/C05QK3KN3HT/p1754487614106789) with @sthaha, who wrote the new Helm chart, I did a quick test to see if a simple release process and the hosting of the Helm chart alongside the application code would be possible here (https://github.com/jklare/kepler/tree/jk-new-chart-releaser). Although this generally works, there are major issues when it comes to naming (in my fork, the release of the application and the release of the Helm chart would both be kepler-XXX, but I removed the workflow to release the application binary for testing), as well as the versioning itself.

Based on the suggestion of @SamYuan1990 I am opening this issue here to find a feasible way to maintain a Helm chart that works for the rewritten Kepler application while also releasing and hosting it in an easily accessible chart repository.
I am happy to assist in the transition of the Helm chart from the Kepler application repository to this one or in just getting this one updated to a state where it can deploy the new Kepler application. Obviously I am also open to other suggestions on how to improve the current situation and am happy to jump on a quick call to discuss and agree on the best options.

[sunya-ch]

@jklare Thank you for your investigation.

In my opinion, in addition to the versioning issue, having this repo updated (keep separate repo for helm) could be helpful in long run especially when considering integration of Kepler to other projects. Other projects (like Carbon Aware SDK or others down the line) can easily consume or contribute to the Helm chart without needing access or fetching to the main repo.

Before we move back and forth between using a monorepo (current solution: check PR #2220) and a separate repository (previous solution). I believe that we should first address the concerns that originally led us to consolidate into a monorepo — particularly issues like management overhead and potential inconsistencies, which were mainly due to a lack of dedicated maintainers. @sthaha Do you have issue elaborated somewhere?

If you have an idea for getting benefits of separate repo while addressing the concern we have, I would recommend to elaborate on it using the proposal format outlined here

[sthaha]

@jklare @sunya-ch ,

In the interest of keeping the helm charts in sync with the code changes in kepler, my opinion is to deprecate this repo in favor of using kepler repo itself as the helm repository. We are nearly there already (charts are released as tarballs) and IMHO, spend a bit more time and effort to improve the release workflow such that when kepler is released, the helm charts are updated as well ...

Decoupling the release process for the application and the Helm chart deploying it, allowing independent release cycles for both

This is exactly what I am trying to avoid by ensuring that the CI validates that the chart is always installable with every code/ config change we make. We definitely want to avoid the situation we have currently which is that the charts are not in sync.

This applies to kepler-operator as well ... When operator supports helm charts, we should have the operator repo as the helm repo for the operator until we have some workflow that is able to sync up all projects (kepler & operator for now) and release under a single repository.

[jklare]

@sthaha

Although I do not agree with the approach of using the same release cycle and process for the Kepler code and the Kepler Helm chart, I do not want to interfere with your process here. I think going with this combined approach will lead to quite a few issues along the way, e.g., whenever somebody wants to improve and patch the helm chart and have those improvements in a new release (e.g., when updating the manifests for new Kubernetes API versions), while not necessarily releasing a new version of Kepler itself, since there might not be any finished updates within Kepler at that point. I also agree with the points @sunya-ch made in terms of allowing people to consume the project.

To continue with your approach @sthaha , I would recommend clearly marking this repository as deprecated and unmaintained in favor of the new Helm chart within the Kepler code repository itself. In addition to that, I think it would be important to release the Kepler Helm chart to a chart repository instead of releasing it as a tarball to allow the community to consume it from there (e.g., with FluxCD).

[sthaha]

I think going with this combined approach will lead to quite a few issues along the way, e.g., whenever somebody wants to improve and patch the helm chart and have those improvements in a new release (e.g., when updating the manifests for new Kubernetes API versions), while not necessarily releasing a new version of Kepler itself, since there might not be any finished updates within Kepler at that point. I also agree with the points @sunya-ch made in terms of allowing people to consume the project.

"while not necessarily releasing a new version of Kepler itself, since there might not be any finished updates within Kepler at that point"

Thats never a state the project's release branch which is main (as of now) should be in. And even in that state the release workflow must allow a hotfix release.

To continue with your approach @sthaha , I would recommend clearly marking this repository as deprecated and unmaintained in favor of the new Helm chart within the Kepler code repository itself.

Agreed.. but do note that the bigger point is that helm charts must be in sync with kepler changes . We already accomplish that in kepler CI (thanks to @vprashar2929) . Now if there could be a workflow here in this repo that is able to take the released (or git tag) version of kepler (which already has the helm bundle) and update the charts here, I am totally fine with it. But the important point is that the source of truth of helm chart for kepler must be the kepler repo.