Custom dashboards

[Joel Takvorian]

Hi,

We started here [1] some discussions around the custom dashboards that come with Kiali.

Basically, the question of long term maintenance is on the table. There's a couple of dashboards that are currently outdated, wrt. the evolutions of the metrics in runtime frameworks. A suggestion is to try to find maintainers in the community, who use Kiali regularly enough and who run workloads with some of the given runtimes.

If no maintainers are found for a given runtime, perhaps the corresponding dashboard should be removed from Kiali operator.

I personally volunteer to maintain the vertx dashboards since I'm also a maintainer of vertx-micrometer-metrics.

Another option could be to reduce even more the scope of installed dashboards to keep only the ones strictly related to Kiali & service mesh (like Kiali+go, Envoy?)

Which brings another topic: be it in the short or long run, anyway, we will have "deprecated" dashboards (ie. not provided out of the box by Kiali operator anymore), we'll also have dashboards evolving with the versions of their target runtimes. What to do with the old dashboards? They can still be useful for people who are running old versions of runtimes. I think it could be interesting to create a repository to stockpile old / unsupported dashboards. Something like "kiali-custom-dashboards" ; 

This repo would have no connection with Kiali operator, meaning that the operation has its own set of dashboards to install Kiali with by default. (or we could also imagine the operator picking a subset of dashboards directly from that repo; that could be a later step)

[1] https://github.com/kiali/kiali/issues/1622

[Joel Takvorian]

A little post-scriptum about custom dashboards, I'm currently updating my runtimes demo with newer versions of frameworks and so on; I'll put it under kiali-demos. Goal is to make it easy to test with known runtimes.

[John Mazzitelli]

> If no maintainers are found for a given runtime, perhaps the corresponding
> dashboard should be removed from Kiali operator.
> I personally volunteer to maintain the vertx dashboards since I'm also a
> maintainer of vertx-micrometer-metrics.
>
> Another option could be to reduce even more the scope of installed
> dashboards to keep only the ones strictly related to Kiali & service mesh
> (like Kiali+go, Envoy?)

...

> This repo would have no connection with Kiali operator, meaning that the
> operation has its own set of dashboards to install Kiali with by default.
> (or we could also imagine the operator picking a subset of dashboards
> directly from that repo; that could be a later step)

FYI: there is an option today (relatively recent addition) where the operator can be told which "built in" dashboards should be installed (or excluded) by default.

So we can ship with all of the dashboards, but by default only have the operator install some (or none) of them.

Today, the operator enables all of them:

https://github.com/kiali/kiali-operator/blob/master/deploy/kiali/kiali_cr.yaml#L196-L207

But we could set those includes/excludes to anything.

As an example, some molecule tests override the default to only install the kiali dashboard, but exclude the rest:

https://github.com/kiali/kiali-operator/blob/master/molecule/config-values-test/converge.yml#L45-L47

(the above tests the "excludes" priority over the "includes" - that's why you see go.yaml listed twice - it is excluded)

[Lucas Ponce]

Thanks Joel.

Yes, basically +1 on your comments.

Kiali should focus on the closest dashboards (Envoy it's part of Kiali's core, and instrument Kiali for troubleshooting is part of the plans).

For the CustomDashboards, I see this feature like an Extension, and I agree that we could try to simplify the way to maintain it, in other words, that update the dashboard of a runtime should involve ~0 knowledge about Kiali internals, and just a yaml descriptor updated and maintained by community.

I haven't thought about the best way to do this, if a new repo with the dashboards is good, I'm +1 on that, but I don't have a pros/cons for one or another implementation strategy.

On Wed, Feb 17, 2021 at 11:02 AM Joel Takvorian <jtak...@redhat.com> wrote:

--
You received this message because you are subscribed to the Google Groups "kiali-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kiali-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kiali-dev/CAJo5TFkBgvgB-jt9NUcv37U4YxR_b%2BiBDwzw2xrQxFjUf6eT1w%40mail.gmail.com.

[Alissa Bonas]

+1 to Joel and Lucas, sounds like a healthy approach to the custom dashboards to be treated as extensions.

To view this discussion on the web visit https://groups.google.com/d/msgid/kiali-dev/CAGUuq3Xnw-e_w6CefS1EGQRNMvC80dWftdxHesvzRfr4qvhJCA%40mail.gmail.com.

[Edgar Hernandez Garcia]

The option I like is to extract 3rd party dashboards and create a new repo for them. Thus, keeping the ones that are related to Kiali.

I think a dedicated repo will be less intimidating to any maintainer that volunteers. 

To view this discussion on the web visit https://groups.google.com/d/msgid/kiali-dev/CAOJV2uCemiKTddtP1%3DmYXKsKoAowbsouPGxb6VwZA%3DDJ4YjmWA%40mail.gmail.com.