Is Timoni With CUE a Helm Replacement?

[@DevOpsToolkit]

Do you think Timoni (and CUE) can replace Helm for your apps?

[@tonygilkerson]

Yes or rather I hope so. As for 3rd party charts I am still motivated to address them as well. I vendor all our 3rd party charts and I have thought about running helm template to make a kustomize or kpt package from the manifests but I am concerned the upgrade and maintenance would be too much but I it is not off the table. If you have any thought about how you might covert a 3rd part app into a Timoni package I would love to hear it. --- great stuff!

[@DevOpsToolkit]

@tonygilkerson conversion is not a problem. Keeping up with future upgrades is the issue.

[@tonygilkerson]

@@DevOpsToolkit I agree but I already modify the charts and therefor go through a diff-review process each upgrade so I am willing to put in the work, therefore I am interested in knowing how to perform the conversion. I want to convert a Helm chart to a Timoni module that my users can then consume and apply any set of values at deploy time (I don't use my Charts I have "users"). The problem I see is that Helm charts will omit entire sections of manifests or even entire manifests when certain values are "disabled" ... Therefore, how do I convert the helm chart to Timoni module and have that module contain both the enabled and disabled option? The only way I can think to do it is to generate a different module for each permutation, yuck!

[@DevOpsToolkit]

@tonygilkerson CUE has import command to convert from yaml. I haven't tried it with Timoni but I'm guessing that once you have it a cue it should not be much additional work.

[@s1treyrr]

I will check out CUE import from my existing manifests! What’s one more layer 😅

[@ytdlgandalf]

To answer the title, i sure hope so. This is such a breath of fresh air

[@c_kemper]

Last weeks cliff hanger was worth it :) Great overview and summary as usual!

[@MikaelFridh]

Hiding Helm completely behind Grafana Tanka and a small jsonnet wrapper made me stop worrying about Helm. Fully upstream vendored helm chart, allowing custom values to be sent in to the helm generator while still allowing custom overrides in jsonnet gives me all the flexibility I need.

[@bryanhunt3099]

Huge tanka / Jsonnet fan, could never understand how helm became the de-facto “standard”

[@bryanhunt3099]

Huge tanka / Jsonnet fan, could never understand how helm became the de-facto “standard”

[@mhamzarazzaq530]

always love your content, great stuff to watch.

[@chastriq]

CUE is neat, I do like it, but developing non-trivial CUE structures is still a sweet-sour experience. The error message you often get is useless due to how the logical/unification engine works, and so far there's not been any features added to CUE that would make this better.

[@phillipsma]

I'm curious if you have heard of KCL and tried it? Would love to see a comparison video, pros and cons etc, with the other yaml template options we have.

[@DevOpsToolkit]

I tried it and I'm using it. It's on my to-do list for a subject of one of the upcoming videos.

[@phillipsma]

Awesome ​@@DevOpsToolkit

[@DirkJanssen-dpj]

great video! helm has a first mover advantage, as you say, but i think it currently benefits more from the network effect: we are all using it because everybody else is using it. for timoni to catch on, it needs to have enough compelling advantages to break through the inertia. you make a good case that it does..

[@DevOpsToolkit]

For third party apps it stands no change precideñy because of the network effect. First party apps are easier to penetrate.

[@az6876]

Thanks, very interesting. But do you know if it's possible to use Timoni directly from Terraform? I have searched online but it seems not possible at the moment.

[@DevOpsToolkit]

Rimini outputs yaml and yaml can be applied with terrsform. Now, if the question is whether you can use terrsform to execute timing that will produce yaml which you can apply with terrsform, the answer is yes, through the exec finction. Still, don't waste time with terrsform for managing kubernetes resources. Use argo CD or flux.

[@az6876]

@@DevOpsToolkit Thank you for the response. By company policy I am required to use Terraform. I admit I am not familiar with Argo and Flux. I will investigate ;)

[@dirien]

very good video! I agree, I would like to see more alternatives to helm getting adopted also from third party providers! Timoni and cue looks like the escape hatch we need!

[@cheebadigga4092]

Thanks!! That's awesome!

[@manikantareddyp1594]

Hi can you please do video on "mirrord" an alternative to telepresence

[@DevOpsToolkit]

That request is quite a coincidence since I'm having it on my short list 🙂

[@manikantareddyp1594]

@@DevOpsToolkit great.. thanks

[@DevOpsToolkit]

Done :) kzbin.info/www/bejne/gZbahpmBe7Wfg7M

[@SimonBoyer-o5j]

I think what could drive Timoni adoption for 3rd parties is if it catch the eyes of platform teams in bigger companies. There, they often rewrite helm charts anyway so it matches their specific requirements, why not do it with Timoni instead? And if enough people are doing that, I would expect some Timoni modules to pop up in public repos. It's a big if, but let's be optimist!

[@DevOpsToolkit]

Here's the idea. Combine Timoni with ChainGuard images.

[@cowgod77]

Great video. Timoni looks very promising and I'm definitely going to kick the tires on it. I hate working with Helm. Thanks!

[@danielnazareth8707]

as someone using argocd to install and maintain apps, how would argocd deploy a timoni image?

[@DevOpsToolkit]

I tend to output it to yaml and store it in git repo. I believe that only yaml is readable enough for everyone to understand it. Now, how we get it that yaml is a different story (e.g. helm, Timoni, ytt, cdk8s, etc.).

[@kostyazgara3481]

@@DevOpsToolkit So, you are suggesting generating yaml outputs before pushing new manifests to Git? Is it the only way to deploy my application using ArgoCD and Timoni? In my humble opinion tools like Helm or Kustomize are more natively integrated into other tools and in this case, timoni looks very raw to be adopted at this moment. What do you think? Does it worth supporting extra logic just to apply timoni to the project?

[@DevOpsToolkit]

@kostyazgara3481 i tend to often keep raw yaml no matter how it is generated. Since building images is a part of ci pipelines, pushing yaml should not be a problem (one more command). That being said, Timoni is now supported natively in Fluz and it's only a plugin away from argo CD if raw yaml is not a good option.

[@liciomatos]

@@DevOpsToolkitbut, in ArgoCD, the helm are only generating the template and applying the manifests individually, right? Using Timoni with ArgoCD should do the same, otherwise, you had to put a action before the ArgoCD to generate the manifests. I don’t like this approach for a IDP. Maybe i am missing something

[@DevOpsToolkit]

@liciomatos action is necessary since you need to build an image and change argo CD app manifest with a new tag.

[@yrosaguiar]

you could use kustomize

[@surtrootsurtroot3360]

Good tool, but not enough to adopt or even try. Firstly, I agree with your action points, but they require a lot of effort for implementation, and I can assume that it could be the hardest way to move from helm. It will be the same situation as we saw in the IaS war between Pulumi and Terraform. So my assumption is that whoever was first will win.

[@DevOpsToolkit]

I do tend to agree with that. Helm is bad, in part because it was first so there was nothing to compare it with. However, being first also means that companies invested in it and investments once made are rarely going away unless there are very big pain points that often have to affect business. So yeah, Helm is here to stay but that does not mean that we should not be looking for better alternatives.

[@kdietz65]

Hmmm. Okay, so as a vendor of one such third-party app, should I stick with Helm due to wide adoption and familiarity, or should I distribute my app using Timoni?

[@DevOpsToolkit]

As a vendor, you should create helm charts. That's a must and everything else is optional. The reason is simple; adoption.

[@s1treyrr]

It would be awesome if cue and timoni could extend helm charts so that we can make our first party modifications to third party apps and write them in cue.

[@SiCrip09]

Is timoni mod push . similar to helm package?

[@DevOpsToolkit]

It is 🙂

[@DevOpsToolkit]

Essentially, cue is a replacement for helm templating while Timoni is a replacement for helm commands.

[@Moronicsmurf]

Idempotent immutable infrastructure can never be guaranteed with imperative languages.. There should never ever be imperative languages included in a infrastructure deployment that should be declarative and idempotent..

[@DevOpsToolkit]

I agree. But languages can generate declarative desired state.

[@dreamcat4]

You know it's very funny story Victor, that all of those months ago I bring up CUE language, (which not it seems is becoming more towards actual adoption)... so today I see your video and say hey! What's this CUE like again? ... better go check it again. So I ask Google: hey google! "cue vs jsonnet" ? To spit out some frame of reference to compare against... But then the 3rd seach result now is: KCL. With this article: "Faster than Jsonnet, CUE, and HCL, We Made ... - Dev Genius". So there we have it. CUE isn't yet fully adopted by the industry. But is already been given some successor as KCL / Kusion. I have no idea how this industry keeps functioning, other than to do some exodus some moving from AWS to Azure it seems... OK so i am looking forwards to your upcoming video or commentary / analysis on KCL / Kusion! (hopeful for 1 day, that we might eventually get to the final templating language, and stop, that can become some sort of a major part / majority share industry standard).

[@pm71241]

Tanka

[@pm71241]

@BananaInCondom It still has it's rough edges, but nothing really structural. And the foundation on jsonnet is elegant and powerful.

[@Fabian-_-]

I use it and I love it, the only thing missing from Jsonnet are maybe types and/or validation. There are some efforts in this direction but these are just POCs unfortunately. Other than that its awesome

[@dirien]

uhh! never!

[@zenobikraweznick]

I was like, what ? a CEMENT ? :)

[@TomJordan741]

The next question is if someone has tackled a conversation utility from a Helm Chart to a Timoni package. That would help bootstrap third party app adoption.

[@DevOpsToolkit]

If you use helm template to convert into yaml, you can convert yaml to cue. That would mean that you'd need to add variables manually. It works, but it's not effortless. Timoni might come up with a more streamlined process.

[@TomJordan741]

@@DevOpsToolkit , that sounds good. One hole in my knowledge is how to convert Helm Hooks. For example, the helm hooks used by the Sentry helm chart. The reason I mentioned the Sentry chart is that I recently was using the helm template to export the Manifests and stopped when I realized that I couldn't apply the generated hook Manifests when I applied the others. I'm going to have to revisit that soon for my own edification.

[@DevOpsToolkit]

I'm not using Sentry myself so I'm not sure which hooks it uses. Can you give me an example? I'm asking that because a) Timoni tends to have better order when applying resources and b) GitOps tools like Argo CD tend to have a mechanism how to define sync ordering. Those two are common reasons for using hooks so they might not be needed anymore.