Grafana dashboard UID too long

[rouke-broersma]

Not sure if this is a problem just on my configuration but I'm getting the following error from grafana when deploying the dashboard through the helm chart:

logger=provisioning.dashboard type=file name=sidecarProvider t=2026-08-17T06:31:20.942905212Z level=error msg="failed to save dashboard" file=/tmp/dashboards/dashboard.json error="uid too long, max 40 characters"

The dashboard uid seems to be 42 characters, so it appears that this hits a grafana internal limit.

Ah I see, the dashboard uses "uid": "{{ include "xpumd.fullname" . }}-dashboard". This should probably just be a static uid, there is no reason to have a dynamic uid imo.

[marquiz]

@rouke-broersma thank you for reporting the issue. Will be fixed in the next release

[eero-t]

the dashboard uses "uid": "{{ include "xpumd.fullname" . }}-dashboard". This should probably just be a static uid, there is no reason to have a dynamic uid imo.

For normal services, dynamic UID is better as there may be different instances (with different settings) on the same cluster. That's clearly less of an issue for DaemonSets like XPUMD, but still a potential corner-case issue (e.g. real version monitoring the cluster GPUs vs. test version with mock driver running on CPU nodes). I'm not sure whether truncating is better option than fixed UID though, as there may still be name conflicts after truncation...

[rouke-broersma]

In that case I don't think the dashboard would be deployed by way of the Helm chart because I don't believe the dashboard has any per-chart settings currently so each dashboard would show the exact same information. Only way to have different information would be different versions. How about a semi static uid containing the chart version for the staging or dev use case , plus a dashboard name override value if all else fails.

[marquiz]

What if we just hash the fullname (like xpumd.fullname | sha256sum | trunc 40? I think Chart.Version would work, too. Or a static value. Something simple that is guaranteed to work...

[eero-t]

I see, the dashboard uses "uid": "{{ include "xpumd.fullname" . }}-dashboard".

-dashboard suffix is rather redundant addition to a dashboard UID, that at least can be dropped.

What if we just hash the fullname (like xpumd.fullname | sha256sum | trunc 40?

I think clearer would be truncating just the xpumd.fullname [1] for UID. I don't know any other SW with the same xpumd name, so having that within first 40 chars of the resulting UID should make it fairly unique already.

(If that is not unique, sha256sum does not necessarily help as somebody else might have the same idea for the matching string too.)

I think Chart.Version would work, too.

Version number itself is not unique enough, and I don't know why user would run different XPUMD 2.x versions in the same cluster, with their own dashboard versions.

---

[1] from template:

{{- define "xpumd.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- if contains $name .Release.Name }}
{{- .Release.Name | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}
{{- end }}

[rouke-broersma]

You suggested this as one reason the uid cannot be static and should be computed

(e.g. real version monitoring the cluster GPUs vs. test version with mock driver running on CPU nodes)

This is why I suggested using the version number. I assume a test version would have a prerelease version number so wouldn't conflict with real version.

[marquiz]

This is why I suggested using the version number. I assume a test version would have a prerelease version number so wouldn't conflict with real version.

So like

"uid": "xpumd-{{ .Chart.Version }}"

Should work as a semi-static ID. Thoughts @eero-t ?

[eero-t]

"uid": "xpumd-{{ .Chart.Version }}"

Should work as a semi-static ID. Thoughts @eero-t ?

Nope. I think user expects XPUMD Helm chart update to update also the dashboard, instead of Helm chart adding a new dashboard.

(Its title would also need to be different then too, otherwise Grafana dashboard list would have 2 identical items.)

Mock driver uses different Helm settings for XPUMD, so that install should have a different release name too...

[eero-t]

I mean, there needs to be something installation specific that the user gives, because we have the use-cases:

• User installs & updates XPUMD version (main use-case) => all things should update (happily we don't have CRDs as Helm does not handle those well)
• Multiple XPUMD instances in the same cluster with different configs (corner case) => things should separated & identified as user specified

[marquiz]

Nope. I think user expects XPUMD Helm chart update to update also the dashboard, instead of Helm chart adding a new dashboard.

So grafana imports the dashboard from the configmap but doesn't remove it when the configmap goes away?

[eero-t]

Another issue is length of XPUMD configMap object names:

• dashboard: {{ include "xpumd.fullname" . }}-dashboard
• daemon config: {{ include "xpumd.fullname" . }}-config

They are otherwise good, but they can break K8s object name restriction as template helpers limit only xpumd.fullname to 63 chars:

• https://github.com/intel/xpumanager/blob/main/xpumd/charts/xpumd/templates/_helpers.tpl

=> fullname should be truncated to length which has space for these too suffixes?

(And that limit should be documented in the chart readme.)

[eero-t]

Nope. I think user expects XPUMD Helm chart update to update also the dashboard, instead of Helm chart adding a new dashboard.

So grafana imports the dashboard from the configmap but doesn't remove it when the configmap goes away?

Ah sorry, I checked my notes and I had confused this with Helm CRD handling (Helm not removing old ones on update). 🤦

Yes, Grafana should remove dashboard (with some delay) when configmap goes away, so xpumd-<version> should be fine. But I think title should also include version, as that will notify user that dashboard was updated.

[eero-t]

Sight, another 🤦

Another issue is length of XPUMD configMap object names:
* dashboard: {{ include "xpumd.fullname" . }}-dashboard
* daemon config: {{ include "xpumd.fullname" . }}-config
They are otherwise good, but they can break K8s object name restriction as template helpers limit only xpumd.fullname to 63 chars:

These are fine; resource limit is 253 chars, xpumd.fullname is limited to 63 chars because it's used also for labels, which have smaller limit: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/

[rouke-broersma]

Multiple XPUMD instances in the same cluster with different configs (corner case) => things should separated & identified as user specified

I don't think this is an issue today because the dashboard doesn't have any config except for datasource. The only potential difference between one dashboard install and another is due to it's version, so version number is the only currently relevant configuration difference.

But I think title should also include version, as that will notify user that dashboard was updated.

I have never seen this done before but fine by me.

Another issue is length of XPUMD configMap object names

I don't think configmap object names are used for anything?

[eero-t]

I don't think this is an issue today because the dashboard doesn't have any config except for datasource. The only potential difference between one dashboard install and another is due to it's version, so version number is the only currently relevant configuration difference.

I wasn't really thinking of dashboard config, but the source attributes (and new metric names) used in queries. Currently they don't differentiate between installations, but they could (namespace, service name etc specified in Helm chart).