grafana multi-org and dashboard links

[Rotfuks]

When we have dashboards spread in multiple grafana organizations, the links to grafana dashboards that we have for instance in alerts may be broken.

ie, this link: https://grafana.gaggle.azuretest.gigantic.io/d/kube-builder-operators/kube-builder-operators
uses the defaut org, and becomes: https://grafana.gaggle.azuretest.gigantic.io/d/kube-builder-operators/kube-builder-operators?orgId=1
But as the dashboard is private, it will be in the Giant Swarm organization, so it should be: https://grafana.gaggle.azuretest.gigantic.io/d/kube-builder-operators/kube-builder-operators?orgId=2

We can't just add the orgId to the URL, as we have no guaranty of consistency of the orgIds across all installations.

Idea:
Is there a parameter that would match the org by name instead of by orgId?

Todo

• Push the discussion in upstream how to handle org-ids in a clean way
• Enforce the creation of the giantswarm org in second position behind shared org to enforce id 1 (shared org) and 2 (gaitnswarm org) for both.
• Change the links in the alerts to include the org id - blocked by Release the new Mimir Alertmanager #3752

[Rotfuks]

Soooo I feel like this is something we need to address at least for the giantswarm and shared organisations. If we want to link backstage to managed dashboards we need to make sure this works.

These are also the two main use cases I see at this point: Alerts and stuff going to giantswarm org dashboards and fully managed dashboards being linked in backstage.

Therefore imo we need to fix those two at least.

Is it possible to "hardcode" the creation order of the shared and giantswarm organisation to make sure those always have the same ids (1 and 2) across all installations to ensure the links to those two organisations dashboards always work?

For the rest we can add a disclaimer into the public docs I think.
What's your opionion here @QuentinBisson ?

[QuentinBisson]

So, no :D

I mean, we can be sure that the grafana organization named shared org will have org id 1
and that the giant swarm organization will be id 2 in the beginning but any restart might change this one.

So if we want to enforce some kind of id, maybe we should allow users to set the org id in a way? Or always make sure the giantswarm org is processed first in the operator?
That would not solve the issues for customers though but unless we have an UID provided upstream or we enable persistence well.

Unless we want to add a proxy that sets the correct header?

[Rotfuks]

That was the idea, that for any restart, we make sure the giantswarm org is processed first - or handled the same way as the shared org, to always get the id 2?

[QuentinBisson]

We theoretically could yes but as long as grafana does not offer a proper UID for datasources then this will also hit customers