Create reusable libary for share code between tempo and loki operators

[rubenvp8510]

Is your feature request related to a problem? Please describe.

Currently there is some work for develop a tempo operator, because the similarities between tempo and Loki in terms of architecture and components some parts of the Loki code and ideas are used also on the tempo operator

Describe the solution you'd like

The idea here is to have a common GoLang library with the common code and use it in both operators, In this way we can reduce the maintenance work, if we need to fix something on the common code, we only need to fix it on the library

Some parts that could be reused:

• build in cert manager, mostly all certrotation package https://github.com/grafana/loki/tree/main/operator/internal/certrotation
• Utilities for the manifests
• We are handling the configuration using templates, in the same way as Loki operator does [see here]
• We might also reuse some component manifests, like ingester or distributor.

[rubenvp8510]

@periklis @pavolloffay WDTY?

[periklis]

m2c below,

Looking at the proposed packages that are supposed to land in a library, we have:

• certrotation: that is inspired by openshift/library-go but ours is easier to use ootb with controller-runtime. I still believe that openshift/library-go's needs a PR to decouple from lister/informer then we will be able to reuse it in our operators directly.
• manifests: usually this code is static and does not change much. At least we strive in Loki Operator to keep it in the purest minimum form without using conditionals. Any patch requires because of conditional is maintained in separate custom function that use mergo.Merge. These functions are designed for the Loki case thus I don't believe anything is reusable. Therefore what's left are some static builders that return the pure minimum manifests using client-go Structs. I believe reusing static struct in a separate library is not worth the effort considering that an extra library requires coordination and release management.

In general I am not a fan of libraries for code reuse only except if they centralize some real business rules. Generators, builders and constructors are better left close to where they are used as per changing them should be a low cost maintenance operation at all time. In addition some the returned structs like StatefulSets are framed to how we want to run them in Loki, eg PVC templates, restart strategy, container arguments. I believe all them would need to be parameters in library code which leaves almost nothing being reused.

I am sorry withdrawing the idea. my experience is that operators nowadays are already a thin layer around a great library namely controller-runtime and great tooling like kubebuilder. The operator implementation is more of declaring desired structs under some conditions, which is clearly just each operator core case and nothing more. I.e the implementation of the Loki Operator is just the desired state of deployments/statefulset/etc for a given CR state and some frature flag. The heavy lifting is done by controller-runtime. Thus the leftovers are just dedicated die Loki and barely reusable under healthy cost conditions.