Use monaco in a K8s operator

[jkleinlercher]

Since developers describe their application infrastructure in K8s resources, it would be great if they could describe their dynatrace configuration also in K8s resources. Then you can use the very same pipeline and tooling for the monitoring configuration as for the k8s infrastructure.

Describe the solution you'd like
Application developers describe their monitoring configuration in K8s objects (special Dynatrace CRDs).
A K8s operator uses the monaco tool to implement the reconciliation loop.

[jkleinlercher]

@markuslackner would you like to participate?

[jkleinlercher]

Gitops engine could be the base: https://github.com/argoproj/gitops-engine

[markuslackner]

I looked a little bit into the code of this project. Some thougths:

I think its a little bit difficult to reuse this code for an operator. It uses a file/directory based input structure and generates the calls for the rest apis. In a operator you have to provide this files based on the request (create/update/delete) and call monaco.

Would it not be easier to call the APIs directly (without monaco)? Ideally we could extract an api client (like https://github.com/xanzy/go-gitlab for gitlab) and the api client is used in monaco and an operator.

What about starting a new project based on https://github.com/operator-framework? @Dynatrace What do you think about this?

[markuslackner]

Gitops engine could be the base: https://github.com/argoproj/gitops-engine

@jkleinlercher I don't think the gitops engine is needed. The operator gets called by kubernetes and can then take the appropriate actions.

[didiladi]

Hey, @jkleinlercher and @markuslackner. Thank you for this issue. You are right, monaco reads its input from a file structure. After all, monaco automates the deplyment of Dynatrace configs located in a configuration repository.

However, one of the design goals of monaco is also to provide a common way of interacting with Dynatrace APIs. We encapsulate all the inconsistencies of the APIs behind the DynatraceClient interface. It is located in its own package and can be used by various other tools written in go. The intention is to have a single dedicated place where we need to cope with special cases of certain APIs, instead of having multiple tools which solve the same problem. We would love to hear your feedback on that.

Recently, @merlindorin showed us the dynatrace operator he was working on for renault-digital, but I'm not aware of the status there. Fyi @kristofre

[merlindorin]

hi everyone, the operator was a proof of concept... I'm waiting for some go struct in order to import them and generate kubernetes controllers. A Dynatrace client with a types switch will be able to handle the inconsistencies.

@jkleinlercher I can take 30min to share the code if you want to have a look. It's more a quick poc with a hope of some effort of the dynatrace api description in go (I really don't want to maintain that myself) rather a production grade controller.