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)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• 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
• 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

[hubeadmin]

Looks good to me initially, wdyt @pb82 @addreas @NissesSenap @weisdd ?

@Iridias Can you clarify one thing for me? (laziness on my part 😉 ) 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? How will data persistence work across these?
I'm just wondering whether there's going to be some data persistence issues across CR updates. Thanks!

Also many thanks for contributing to the project! 😄

[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]

Sounds very reasonable. We do the same thing but currently we don't store any data in PVC:s that is worth saving.

Put a minor comment.

[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.