support specifying existing volume in grafana dataStorage

[Iridias]

Description

In order to reference an existing volume (e.g. for a specific blob/file-storage) it must be possible to specify the volumeName in the PVC. The PVC will be created using the attributes in Grafana.spec.dataStorage, so I added a new attribute volumeName that will be used when creating the PersistentVolumeClaimSpec

Type of change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [X] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• [X] This change requires a documentation update
• [ ] I have added tests that prove my fix is effective or that my feature works
• [ ] I have added a test case that will be used to verify my changes
• [X] Verified independently on a cluster by reviewer

Verification steps

• Create a PersistentVolume on your Cluster and make sure, that the ReclaimPolicy is Retain (e.g. by following this guide: https://docs.microsoft.com/en-us/azure/aks/azure-files-volume#mount-file-share-as-a-persistent-volume)
• Update the CRD for Grafana on your Cluster
• Change your Grafana.yaml to reference the created volume (for an Example see deploy/examples/persistentvolume/Grafana-existingVolume.yaml)
• Apply the changes to the cluster and wait for the grafana-deployment POD to come up
• check that the automatically created PVC "grafana-pvc" is bound to the previously created Volume kubectl get pvc -n your-namespace

[NissesSenap]

What is the need for this feature @Iridias? Why not let the operator manage the PV? You can already define a storage class what else do you need?

There probably is a good reason but it would be good to define it.

[Iridias]

What is the need for this feature?

When we're "updating" one of our clusters, we're in fact rather setup a new one, deploy everything on it and switch the routing (all automated of course). But this leads to the situation, that everything that is not stored on a volume/storage outside the cluster, will be lost. And unfortunately, the dynamic storage-provisioner of AKS (Azure Kubernetes Service) will always generate a random UID for the storage - so you can't target an existing azure-storage with a PVC! You must create the PV manually in order to do that and reference that PV in the PVC!

What happens when a user defines a grafana CR without the volume name specified, and then the CR is updated with a new name, will the old pvc be deleted and replaced with a new one?

I would assume, that the PVC will be updated, but the previously created PV will be deleted - as the default reclaim-policy is "Delete". Have not tested it tough.

[NissesSenap]

LGTM, thanks allot for your contribution @Iridias, I did a minor change in the example so it works out of the box with the ingress config.