Upload should be idempotent about gdg HOT 6 CLOSED

There was a previous conversation about this. I found the code needed to ensure the IDs are preserved to be a bit too convoluted, though that can be somewhat iterated on. The biggest issue I found is that even IF you maintain the ID, then you still end up with a git delta of a version change. I would argue that your changes should be maintained in git, not grafana. You should choose what your source of truth is, grafana or git, and treat that as the primary way of versioning dashboards.

Doing an upload and redownload seem to be generate SOME delta, so making the code more complicated to preserve the sanctity of the git diff I don't think is worth it.

Preserving a dashboard history, I could see being worth while, though I'll have to look at the code again to see what's needed. Either ways though you'll always end up with a delta between upload/download. If there's a pattern that doesn't I'd be curious to know what that is.

from gdg.

Thanks for the earlier info, I missed it when quickly browsing for pre-existing issues.

Even for dashes in git only case, the current functionality doesn't work well as e.g. favourites are tracked by id, and due to that if you re-upload dashboards users lose their favourites (and id-based links).

I don't unfortunately have anymore access to the original code I wrote for $PREVJOB, but I think there was API call which just set overwrite flag on and supplied id+uuid and it mostly worked for us.

To make the no-change detection work with git, you want to normalize the dashboards (e.g. export only always in same way and ignore version changes). That can be done elsewhere, though, given the upload otherwise retains the data but with id changes Grafana behaviour changes and you cannot really work around that.

from gdg.

So, I can take another pass like I said, and per usual PRs are accepted, but as far as having a 0 diff as a goal; it's not the purpose of GDG. GDG is a tool that lets you manage entities (dashboards, libraryelements, connections) and allows you to have a consistent behavior between one instance of grafana and another.

The idea of having no delta in git is a nice to have but it's not really a strong motivation. Now, if there is a way of doing this easily and cleanly that doesn't make the code less maintainable or more complex that's fine. Doing things like ignoring the version number is not something I'd really put into GDG. The only way I can see doing that is disregarding the version number and having a static value. I'm not even sure what would happen if you upload version 1 when there's been 7 versions updated.

As far as Implementation goes, it's a lot easier to wipe everything and push what you have in your file system. After all the idea is that whatever is your backup storage should be what is in grafana. If anything else is in grafana in the watched folder it's supposed to be removed, and replaced with the data in git.

I don't mind adding complexity, we've done that before, but it should get us a net gain of some kind. your grafana history should ideally useless since git log <file.json> gives you all the changes that went with that dashboard, and the git diff being empty will not happen without some hacks.

from gdg.

Delta in git is not even the problem. It is the other user visible aspect ( when dash is deleted. It is removed from favorites ) which the upload step does even if it is really overwriting existing dashboard.

Anyway, as this is not that high priority problem for me either, we shall see if I get around to making PR for this.

from gdg.

Interesting, okay that's a legitimate issue. I never noticed that behavior. Let me think about it a bit and revisit this.

from gdg.

I'm not able to get the import endpoint to support this. Right now the options are to use /import or /dashboard/db. I'm sure /dashboard/db would work, but it drops support for libraryelements. /import currently isn't working for me.

I may revisit this later, and leave it open and as I said, I'll consider a PR.

from gdg.