Hiding CRD boilerplate / implementation detail from the locutus configuration

[bwplotka]

This is part of https://github.com/observatorium/rndr goals, but @brancz asked me why some of that feature cannot be part of Locutus. Why not, let's discuss 🤗

Triggered by valid offline @s-urbaniak question:

just a gut observation: your api entrypoint is what locutus calls a trigger which references an "observable" API. In kubernetes this is a custom resources (expressed as Go types) so it is a different concern than rendering, no?

That's very good question. I skipped trigger and kind of replaced it by api in rndr, because:

• Trigger (one off, interval, watch) is runtime specific option. We want to make sure we are not tied to runtime reactiveness on the tool side. Tigger is literally only a configuration to the generated operator. But there are other options like just generating raw YAML in right ordering for your own GitOps tools or even generating helm chart.

• I believe tools like locutus/rndr should take non-CRD definition directly (proto / Go) and automatically generate CRD if needed. This allows non-Kubernetes and non Operator use cases (as mentioned above). We should hide boilerplate of CRD as the crd type changes very often, it's not human readable and leaks Kubernetes details. Why not asking for definition directly and generate CRD on tool/locutus side?

NOTE: By non operator model I mean generating resources, but this does not mean that specific operator is part of those resources (prometheus-operator, receiver-operator etc.

I think this is main difference and reason why different tool focused on generation deployable resources vs operating might clearer (: WDYT?

[bwplotka]

I think it's bit weird to reshape locutus. I think those two goals:

A) Generating renderables
B) Deploying renderables (e.g as operator)

Are two distinct features that's why rndr as A (while using same renderers as Locutus) and pure locutus for B makes sense.

It does not mean everything could be part of same project 🤗

[brancz]

1. I think the "non-CRD" thing you're talking about already exists. Take a look at this example. It's not a CRD at all, it's just any kind of config you want (in this case json as that's what the jsonnet renderer wants, but could be anything for any renderer). Locutus is intentionally built so we can add more renderers to satisfy more use cases, and I'm happy to add more.

2. I think I might have chosen defaults poorly in the beginning. I think changing --render-only to be true by default would make more sense. The idea was always to allow the use case that I think you're describing, where a first run of locutus would just generate raw yaml + a rollout spec, and a second run (probably by CI) would actually apply the raw yaml according to the rollout spec.

If you think it would make it clearer, I'm also happy with separating these into subcommands. Part of the reason why the main.go is the way it is right now is because I always wanted locutus to be easily used as a library if the out of the box actions for rollouts for example are not sufficient, so you could just copy the minimal main.go and add your own action.

[bwplotka]

Generally make sense, thanks for the quick response. This to me sounds like a nice separation of concerns 👍🏽

+1 on render-only being a separate command. I understand the vision for making sure library-first works best, but do you think we should invest time to make main.go part of Locutus solid as well, or would you rather ask e.g us to do it in separate projects (e.g like rndr)? I feel those commands tiny improvements could help with adoption overall. Maybe what you are looking for is some example main.go that will be minimal? 🤔

However, I still think, especially with the library capabilities of Locutus that there is a space for tools that will replace the need of creating hacky scripts that are necessary for reliable locutus usage.

What do I mean? Let's look at the existing project that uses Locutus: https://github.com/observatorium/operator In order to make all works, few things has to be created:

• .go files for CRD definition with some generated deep copy things
• Makefile script to generate actual CRDs
• Boilerplate hack
• Non trivial mult-layer Docker file to run Locutus
• Makefile script to build Dockerfile properly
• E2e tests
• Non trivial entry point for locutus when you want to use .jsonnet. (Started Proposal: Simplify the Jsonnet renderer entry point. #38 for discussion)
• If we even created cool generator from that will generate jsonnet object + validation from Go/proto then we have to manually hook that up in our jsonnet outside of Locutus (bit separate topic more related to https://github.com/protoconfig/protoconfig)

Those are things non trivial to create and maintain. For single project with smart people (like you @brancz), it will be just a few days of work, but in spectrum of adoption and sustainability: This will be a bit of blocker. And I would love to use similar for Thanos, and literally, every projects that runs in cloud (:

And yes all of the above could done via some tool that generates those Makefile scripts and e.g basic layout, but this could be hard to maintain over time. It would be amazing to embed this into single tool long term like: https://github.com/observatorium/rndr which allows hiding a lot of this boilerplate from the project that can finally focus JUST on solid jsonnet deployments for various use cases. And someday... also not worrying of someone asking for helm, X, and Y and simply have a single source for generating all of this. I think that's all we want, no? 🤗

So we could hide:

• Generation of CRD from definitions (proto / Go), when kubernetes operator is specified
• Generation of docker image with Locutus command "instrumented", when kubernetes operator is specified
• Generation of helm chart (possible only with special renderer plugin) when kuberenetes helm is specified.

This is why rndr started. What do you think? Do you think it's not for optimizing for if it's a single effort? I feel that long term maintenance and having all projects that want to use locutus in some way or another redoing all of this is no longer single effort 🤗

cc @paulfantom @s-urbaniak @kakkoyun for awareness.