More reusable and less effort template / API packaging

[bwplotka]

As @kakkoyun said:

However, I have long term concerns.

First of all these reviews are getting challenging. We need to define clear ownership of this component and what we would like to achieve. We need to build context and knowledge.

Second, jsonnet files for optional attributes are getting out of control. They are cumbersome and not easy to digest. We should come up with a better pattern.

And last we are getting reckless with the API, we just keep adding things to CRD. The existing API already seems archaic comparing our recent configuration. Moreover, we don't think about the future that we plan, we might need to rewrite the whole CRD to support other signals.

AC:

• ACM is able to use more from RHOBS templates
• We use Locutus (we can do GitOps + Operator job)
• Any user can easily reuse the configuration

One comment I heard was to make things opinionable, otherwise, you can make it work for everyone. Maybe we should be more opinionated but also allow experimenting. E.g a very strict and simple API, but has some extra fields that allow injecting Jsonnet or so.

Another idea is to split functionalities.

We want to represent the deployment topology of components, then their configuration then the Kubernetes specific options. Why we cannot have 3 abstractions instead of one combined. E.g If someone has special Kubernetes it should allow this person to use our templates while swapping Kubernetes logic around. Thinking loudly (:

[clyang82]

Thanks @kakkoyun @bwplotka to bring this topic and collect the comments.

You know that ACM is using operator to deploy observatorium ecosystem. as a product or mature solution, it may need to expose more properties in CRD to allow the user to do tuning in large scale environment. for example: more retention and duration parameters, etc.

I have concerns about the operator depends on deployments. Actually, I think the deployments should be generated by operator with pre-defined configurations. the user can use operator to deploy the observatorium or use deployment to deploy. in this way, we can

• Maintain only one repo without inconsistent issues.
• Promote operator to be adopt

[bwplotka]

Yes, that's the plan more or less!

The key part is the API part. If we want to reuse it, we need to find a good way to iterate over the API without too much boilerplate.