search

brancz / locutus

Apache License 2.0
61 stars 13 forks source link

Hiding CRD boilerplate / implementation detail from the locutus configuration #37

Open bwplotka opened 3 years ago

bwplotka commented 3 years ago

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:

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

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:

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.