Open Vad1mo opened 2 years ago
Hey folks. We are actively researching ways to address this issue. Stay tuned 👍
I was looking at it as well, and my conclusion and recommendation from Helm guys was to use Chart Hooks.
What is your approach to it @iliapolo?
@Vad1mo To address this specific issue I believe we don't need Chart Hooks. We just need cdk8s to be able to generate the necessary chart files along with the manifests it produces. Possibly using chartify or helm-x, or maybe just rolling our own.
We are thinking of something like: cdk8s synth --format helm
Regarding publishing cdk8s constructs as helm charts, we don't have concrete plans to support that. If Chart Hooks can help here, maybe we can reconsider, need to dive deeper to understand.
Awesome!
@Vad1mo To address this specific issue I believe we don't need Chart Hooks. We just need cdk8s to be able to generate the necessary chart files along with the manifests it produces. Possibly using chartify or helm-x, or maybe just rolling our own.
- Chart Hooks have also some downside, eg. lifecycle, cleanup etc,
- chartify or helm-x have the challenge, they only exist as binaries or golang code.
Writing a Chart wrapper around the manifests in JS should be not that complicated and has zero external dependencies. This would provide a remarkable convenience.
We are thinking of something like:
cdk8s synth --format helm
I am uncertain if you plan to output packed or unpacked format here. It might be worth to find out if they are use case for an optional flag cdk8s synth --format helm --packed
The zipped export can be uploaded to an OCI registry as a static chart if needed.
Regarding publishing cdk8s constructs as helm charts, we don't have concrete plans to support that. If Chart Hooks can help here, maybe we can reconsider, need to dive deeper to understand.
IMHO, a static chart in OCI would only make sense in a GitOps workflow, allowing Argo or Flux just pick the chart and deploy it. Creating a dynamic chart is IMHO a complex endeavor.
Hi, @iliapolo just fyi, helm itself could be used as Go SDK.
Description of the feature or enhancement:
Currently, cdk8s is synthesizing to Kubernetes manifests only, like
helm template
would do it. Setting some labels and metadata. However, it is not possible yet to take advantage of Helms full potential.As a "package manager" Helm is a great tool, but the templating is horrible, so this is where cdk8s and Helm package manager would be a match made in heaven.
Use Case:
Deploy the synthesized cdk8s manifests as a Helm Chart. This is not about t is not about generating a Helm Chart itself that you might publish. This won't work unless you have cdk8s as a templating language for Helm. The proposal is following how chartify and helm-x are using it to deploy manifests as Helm Chart, so you get all the benefits of Helm as the package manager.
Proposed Solution:
integration of helm-x or yet better chartify into cdk8s.
Unlike other proposals, this does not need any changes to Helm
Other:
The ideal approach, of course, would be if Helm would support templating engines other than html/template for example cdk8s.
Related to:
https://github.com/cdk8s-team/cdk8s/issues/21
https://github.com/cdk8s-team/cdk8s/issues/867
https://github.com/cdk8s-team/cdk8s/issues/848
[ ] :wave: I may be able to implement this feature request
[ ] :warning: This feature might incur a breaking change
This is a :rocket: Feature Request