Decouple Helm chart release from Karpenter release

[stevehipwell]

Tell us about your request
I'd like the Helm chart release to be decoupled from the Karpenter binary release as there are completely different concerns for each; this would be an idiomatic pattern in the CNCF ecosystem and is used by other AWS components. In addition to the decoupling this would allow for a better versioning strategy for the chart, I know that with the 0.x.y SemVer version currently in use any change is technically a breaking change but it'd be nice to control these separately.

I don't think it matters which existing AWS release pattern is picked; publish to eks-charts like aws-node-termination-handler or self hosted like aws-ebs-csi-driver. Although in the self hosted model I'd like to see a switch to using the chart-releaser so the chart packages are hosted in GH releases rather than directly in the repo.

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
I'd like to know that the Helm chart can be independently updated from the Karpenter binary and that the chart version is a valid SemVer representation.

Are you currently working around this issue?
I'm currently treating all chart releases as breaking.

Additional context
I'm happy to open a PR to do this work, either as part of #1145 (which could do with this) or separately.

Attachments
n/a

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[ellistarn]

I'd really love a Karpenter github org where all of these decoupled components can live (e.g. website, chart, core, cloudprovider?)

[stevehipwell]

@ellistarn you don't need a separate repo for the chart at least. I'd happily open a PR as a POC to show how it can be decoupled. If you want some examples, I've worked on External DNS and Metrics Server; both of which have a slightly different approach built from the same components.

[ellistarn]

🤔 I'm recalling the reason we wanted to do this was to host both the chart and website using GH Pages. The website is now on Netlify, so it's perhaps less critical now.

Totally supportive of using chart releaser. We intentionally avoid hosting in eks-charts for neutrality reasons.

[stevehipwell]

I'll open a PR for the release decoupling once #1145 has been merged.

How does the website release process currently work?

[stevehipwell]

Also how does the binary get released?

[spring1843]

Also how does the binary get released?

https://github.com/aws/karpenter/blob/main/.github/workflows/release.yaml
https://github.com/aws/karpenter/blob/main/hack/release/release.sh

[jonathan-innis]

@stevehipwell We've discussed on this a bit internally. I think the summary is that we don't want to have to reason about separate app and chart versions and would prefer to just make the versions match always. If we are just making a chart update, we will just increment both versions.

[stevehipwell]

@jonathan-innis ok that's your decision to make and is likely fine while you're pre v1. Just remember that once you hit v1 a SemVer major chart change would require the same from the binary and all of the pain that causes a Go repo.