I feel I've built something similar using fluxcd + cuelang. FluxCD allows having order through depends on and how you organize your Kustomization resource.
I still believe the FluxCD project needs a UI that matches what you can get from the cli. CLI has so many features that you might or might not get fully from the available UI's.
Show HN: Koreo – A platform engineering toolkit for Kubernetes
11–20 of 47 posts
Re: Show HN: Koreo – A platform engineering toolkit for Kubernetes
#12> Koreo is the engine that powers Konfigurate, a batteries-included developer platform for startups and scaleups.
Yaml is no go for me.
Gradually typed languages, with support of unkown values, like Nickel can be good.
Re: Show HN: Koreo – A platform engineering toolkit for Kubernetes
#13> Koreo is the engine that powers Konfigurate, a batteries-included developer platform for startups and scaleups. Yaml is no go for me. Gradually typed languages, with support of unkown values, like Nickel can be good.
But if Kore starts where Kustomize ends (selectors like, inheritance like, binding like things) and covers 100% of Kustomize. But builds on top (i see CEL usage). I can be intresting to use this instead of Kustomize.
Re: Show HN: Koreo – A platform engineering toolkit for Kubernetes
#14> Koreo is the engine that powers Konfigurate, a batteries-included developer platform for startups and scaleups. Yaml is no go for me. Gradually typed languages, with support of unkown values, like Nickel can be good.
[deleted]
Re: Show HN: Koreo – A platform engineering toolkit for Kubernetes
#15> Koreo is the engine that powers Konfigurate, a batteries-included developer platform for startups and scaleups. Yaml is no go for me. Gradually typed languages, with support of unkown values, like Nickel can be good.
But if Kore starts where Kustomize ends (selectors like, inheritance like, binding like things) and covers 100% of Kustomize. But builds on top (i see CEL usage). I can be intresting to use this instead of Kustomize.
twitter thread,
> However, the two tools are not mutually exclusive. In some cases it can make sense to use Kustomize in combination with Koreo!
Would be awesome Koreo make Kustomize no need. I feel insane getting into project where Helm, Kustomize and Koreo used at same time(they always do this).
So if Koreo and Helm only, would be nice gradual step. One bad yaml with other bad yaml.
Re: Show HN: Koreo – A platform engineering toolkit for Kubernetes
#16> Koreo is the engine that powers Konfigurate, a batteries-included developer platform for startups and scaleups. Yaml is no go for me. Gradually typed languages, with support of unkown values, like Nickel can be good.
But if Kore starts where Kustomize ends (selectors like, inheritance like, binding like things) and covers 100% of Kustomize. But builds on top (i see CEL usage). I can be intresting to use this instead of Kustomize.
If we're going to ditch Kustomize, let's ditch it for something that isn't YAML, because Kustomize has the virtue of being established.
Re: Show HN: Koreo – A platform engineering toolkit for Kubernetes
#17Timoni ticked so many boxes for me. Hoe does this compare?
It's YAML.
Re: Show HN: Koreo – A platform engineering toolkit for Kubernetes
#18> Koreo is the engine that powers Konfigurate, a batteries-included developer platform for startups and scaleups. Yaml is no go for me. Gradually typed languages, with support of unkown values, like Nickel can be good.
I feel like I should just be able to generate k8s configs from Typescript with Typeconf if I add all the types there, is anyone interested in this?
Re: Show HN: Koreo – A platform engineering toolkit for Kubernetes
#19Here's the tension I find with projects like these: App developer knowledge seems to end with a helm chart. Anything more complex than that, they won't be able to deliver themselves. For platform/k8s admins, these tools are more cumbersome than just writing a dedicated operator in go.
What advantages does this offer over rolling my own CRD and operator? Assume it takes me 4 hours to write an operator end to end.
Re: Show HN: Koreo – A platform engineering toolkit for Kubernetes
#20Just one more YAML bro I swear trust me bro just one more meta level will solve everything just one more yaml please I promise you it's not bad just write yaml it's simple and clean just some more yaml man just one more yaml file you will certainly not regret it just add one more yaml (Congratulations on the launch, looks interesting!)
I wrote the core engine behind this and your comment made me laugh pretty hard because I agree. I debated a lot about the best syntax and we experimented with various alternatives approaches. The core engine actually isn't YAML centric at all, in fact it doesn't use YAML—it is just data structures in and out.
We wound up exposing this as YAML purely because there's a lot of tooling out there for dealing with YAML. I am not sure if that's a good reason or not.... Writing the language server was quite nasty because of that choice! Our hope was that the language server and structural type checking (which is very simplistic at the moment) and testing framework can make it feel more like a real language and less YAMLy.