PoC: add a ‘grafana’ config block to the Kuadrant CR (a Grafana integration, not a Grafana installation)

[david-martin]

Similar to the Kiali CR https://kiali.io/docs/configuration/p8s-jaeger-grafana/grafana/
We can do something similar with the Kuadrant CR, and show up links to grafana dashboards in the console plugin, but only if the kuadrant dashboards exist in grafana (needs grafana auth)

For example, if we show some metrics panels for the platform engineer (using QueryBrowser), we can have a 'View in Grafana' button that links to our big PE dashboard.

[Boomatang]

If I am understand the this correctly, it would be the user that is adding the links within Kuadrant CR. Not the kuadrant operator trying auto add the links.

My question is how does the console plugin get told to show the links?

I am wondering is this something the console plugin can handle on its own and not require the kuadrant-operator or the kuadrant CR. If the console plugin UI was served from the kuadrant operator then this is the right place for it, but as that is not the case I don't think it is the right place.

For PoC testing, I am guessing a ConfigMap could be used so as not to need updating the APIs.

[david-martin]

it would be the user that is adding the links within Kuadrant CR

Yes. From a personas point of view, that would be the 'platform engineer' that maintains kuadrant as part of the platform for themselves and app developers.

My question is how does the console plugin get told to show the links

@jasonmadigan leaning on you to correct me here.
It could be looked up in the CR directly (at client render time, via the browser making a resource API call).
Similar if the information was in a configmap.

If the console plugin UI was served from the kuadrant operator

Not directly. The operator creates an nginx deployment that serves the files
https://github.com/Kuadrant/kuadrant-operator/blob/main/controllers/consoleplugin_reconciler.go

as that is not the case I don't think it is the right place

I think it could be argued that it is the right place (in the Kuadrant CR) from a usability perspective.
A central place for this kind of configuration.

I am guessing a ConfigMap could be used so as not to need updating the APIs

I don't mind doing a poc with a configmap, but I would argue for having something that is more 'nailed down' API wise and can be validated via CR fields at creation/update time. Using a configmap in a kube environment where you have CRD capabilities feels akin to using annotations on resources (again, can't be validated really) to have some unforseen consequence without any status of if it worked or not.

[david-martin]

Adding to the above,
I think reading a configmap from the console plugin could make sense to decouple it from the kaudrant-operator, and also have a nice side-effect of easier dev (no dep on the kuadrant CR during dev).
I do stand by the above comment about validation of the fields in the CR, so perhaps the kuadrant-operator/CRD is doing validation and converts that into the configmap that the console-plugin needs.