Implement spec.uid for GrafanaDashboard

[Baarsgaard]

Followed the same pattern as #1686 for the CustomUID.
As discussed in the weekly sync, spec.uid or metadata.uid will always overwrite dashboardModel.uid.

Thanks to the existing Status.UID update detection, existing dashboards are automatically migrated to using metadata.uid by the operator.

Local procedure for testing

make start-kind
make deploy
kind export kubeconfig --name kind-grafana

# Test resources
kubectl apply -f https://raw.githubusercontent.com/grafana-operator/grafana-operator/master/examples/basic/resources.yaml
kubectl apply -f ../test-dashboard.yaml

# Check status:
# dashboards
#   - default/dashboard-uid/dashUID
kubectl get grafanas -A -o yaml

# Build and apply image to cluster
make ko-build-kind
IMG=ko.local/grafana/grafana-operator make deploy
kubectl patch deploy -n grafana-operator-system grafana-operator-controller-manager-v5  --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/imagePullPolicy", "value":"IfNotPresent"}]'

# Check status:
# dashboards
#   - default/dashboard-uid/dashUID -> specUID
kubectl get grafanas -A -o yaml

../test-dashboard.yaml

apiVersion: grafana.integreatly.org/v1beta1
kind: GrafanaDashboard
metadata:
  name: dashboard-uid
spec:
  instanceSelector:
    matchLabels:
      dashboards: "grafana"
  uid: specUID
  resyncPeriod: 10s
  json: >
    {
      "id": null,
      "uid": "dashUID",
      "title": "Simple Dashboard",
      "tags": [],
      "style": "dark",
      "timezone": "browser",
      "editable": true,
      "hideControls": false,
      "graphTooltip": 1,
      "panels": [],
      "time": {
        "from": "now-6h",
        "to": "now"
      },
      "timepicker": {
        "time_options": [],
        "refresh_intervals": []
      },
      "templating": {
        "list": []
      },
      "annotations": {
        "list": []
      },
      "refresh": "5s",
      "schemaVersion": 17,
      "version": 0,
      "links": []
    }

• Chainsaw tests for immutability of spec.uid
• Chainsaw tests for expected status on Grafana instance
• Add documentation around spec.uid

[kcolford]

is it possible for this to only override the uid if a uid is not already configured? some collections of dashboards already have a uid in them and then link to each other through that but other dashboards have no uid at all and it would helpful to make sure that the uid can be deterministic if the dashboard's uid isn't present 🤔

[Baarsgaard]

Just to sum up the behaviours:

1. Current: spec.json?.uid > metadata.uid
   Allows modifying dashboard UID as well as overwriting metadata.uid with spec.json?.uid whenever.

2. This PR: spec.uid > metadata.uid
   Resulting UID is always immutable, spec.json?.uid is entirely ignored

3. Your suggestion spec.uid > spec.json?.uid > metadata.uid (I think?)
   spec.json?.uid is mutable only when spec.uid is not defined.

All of which has their drawbacks, notably:

1. UID collisions require downloading remotely sourced dashboards getting rid of the benefit of updates.
2. Linking between Dashboards need to have their UIDs hardcoded in the spec.uid to not break the links.
   Requires a delete and create of the resource to change the set UID
3. Same problem as 1 except the workaround is specifying the spec.uid with no other drawbacks to my knowledge, unless the links change?

Personally I don't see much difference between 2 and 3 except they introduce annoyances in two different use cases.
Additionally, there's a slightly higher maintenance burden of 3 due to extra tests and checks necessary.

Yes, it's possible, but I don't know if its the right direction to go in.