Add make it possible to disable editing of a dashboard from a grafanadashboard CRD about grafana-operator

[theSuess]

I was planning on asking the Grafana team directly, but it looks like you were quicker. I've labeled this as upstream issue and we can reopen the issue once this gets implemented in Grafana

[HubertStefanski]

Hey, @boris-smidt-klarrio

But this means that after the next sync the changes are gone.

I'm not sure how to respond to this, isn't this the intended behaviour? Imho, that's exactly how the operator should behave, the Dashboard CR is the declared state of the dashboard that the operator intends to maintain. User changes should not be saved because they aren't the source of truth.

Your UI-based changes should only live as long as the remaining time to the next periodic reconcile. It's expected that UI changes will not be persisted after the dashboard controller re-syncs the dashboards across all instances.

The Operator only has knowledge of changes on the Grafana API when it reaches its next reconcile, it doesn't actively react to changes on the API in real-time.

My recommendation here would be to decrease the reconcile period for the dashboards you want to be "always true". So they get updated more frequently. Other than that, RBAC based permissions on the Grafana instance would be the way to go, albeit we don't support that yet through the Operator (at least not as a separate CR)

[boris-smidt-klarrio]

@HubertStefanski i think we have a misunderstanding here. I indeed want the dashboards to be overwritten with the CRD.
But when i use a provider, like the sidecar which scrapes configmaps i can enable the flag allowUiUpdates: false
In that case when you want to save a dashboard you will get the following message:

But when i use a dashboard CRD it will just allow you to save the dashboard.

So it seems the grafana-operator doesn't mark the dashboards as 'provisioned'

[HubertStefanski]

@boris-smidt-klarrio thanks for clarifying, I wasn't aware that this was a Grafana setting, In that case I think it makes sense to extend the GrafanaDashboard CRD Spec to accommodate this 👍

[boris-smidt-klarrio]

https://github.com/grafana/grafana/blob/f11b10a10cefcb12e6825f6ed9a20cf77d8dcc39/pkg/api/dtos/dashboard.go#L34-L35
Good news it seems the dashboard metadata.Provisioned needs to be set.
It might even be best to add it as a default true.

[boris-smidt-klarrio]

The bad news is that this isn't exposed over the client library used in this project
https://github.com/grafana/grafana-openapi-client-go/blob/main/models/dashboard_meta.go
But it is in the new project which isn't released yet (except latest)

[theSuess]

While working on #1462 I took a closer look at how to implement this, and it turns out that the provisioned field can only be set when using file based provisioning on the Grafana side. This means that we cannot set this field via a CR (at least not with how the operator currently works)

As an alternative, you can set the editable property of the dashboard spec to false. This will at least warn the user before editing the dashboards using the UI

[boris-smidt-klarrio]

@theSuess So if you set the Provisioned flag in the call to create a dashboard what would happen?

Instead of closing the ticket wouldn't it be better to create a feature request upstream to allow to set the provisioning in the API call?

[boris-smidt-klarrio]

Oke i'll try to assist as much as i can 👍 Thank you for investigating the provisioned feature a bit deeper.