Pros:
- comes from someone with deep k8s experience
- has features for secrets and dynamic information based on k8s version and CRDs
- thinks about the full life-cycle and e2e process
Cons: (at the time)
- holds CUE weird, there are places where they overwrite values (helm style) which is antithetical to CUE philosophy. This was rationalized to me as keeping with the Helm mindset rather than using the CUE mindset, because it is what people are used to. I think this misses the big opportunity for CUE in k8s config.
- has its own module system that probably won't integrate with CUE's (as it stands today), granted CUE's module system wasn't released at the time, but it seems the intention is to have a separate system because the goal is to align with k8s more than CUE
- Didn't allow for Helm modules to be dependencies. This seems to have since changed, but requires you to use FluxCD (?)
I didn't ever adopt it because of the philosophical differences (me from CUE, stefan from k8s). I have seen others speak highly of it, definitely worth checking out to see if it is something you'd like. I have plans for something similar once an internal Go package in CUE is made publicly available (https://github.com/cue-lang/cue/commits/master/internal/core...). The plan is to combine the CUE dep package with OpenTofu's graph solver to power a config system that can span across the spaces.