[Feature] Modify database persistence spec test to deploy with supported storage provisioner.

[svteb]

Is your feature request related to a problem? Please describe. Running the database persistence spec test on a minikube cluster with standard storageclass fails. This is because of a regex that checks whether the current storageclass is amongst one of the recognized elastic storage provisioners. This "out-of-the-box" failing behavior could be misleading for developers attempting to verify their changes through spec tests.

Describe the solution you'd like I propose that before the database persistence task is run, the environment is checked for its current default storageclass. In case such storageclass is not considered elastic, the rancher.io/local-path storageclass (or a different storage provisioner) would get deployed, set as default and at the end of the test could be cleaned up. Potentially the helm chart of mysql (that is being tested for elasticity) could be somehow edited to achieve the desired properties (I don't know if this is possible).

Once this issue is addressed how will the fix be verified? The database persistence spec test will pass on a cluster without a manually deployed storageclass.

Additional context I didn't try this with kind or other cluster-creation tools, they may use some storageclasses that work by default but we should strive for some unified solution with spec tests. The recommendation of rancher.io/local-path storageclass as a default storage provisioner comes purely from the current spec regex (and also from the fact that I got it running by executing 3 commands):

ELASTIC_PROVISIONING_DRIVERS_REGEX_SPEC = /kubernetes.io\/aws-ebs|kubernetes.io\/azure-file|kubernetes.io\/azure-disk|kubernetes.io\/cinder|kubernetes.io\/gce-pd|kubernetes.io\/glusterfs|kubernetes.io\/quobyte|kubernetes.io\/rbd|kubernetes.io\/vsphere-volume|kubernetes.io\/portworx-volume|kubernetes.io\/scaleio|kubernetes.io\/storageos|rook-ceph.rbd.csi.ceph.com|rancher.io\/local-path/

There might be some reasons as to why this has not yet been implemented or is unfeasible, if so please let me know.

Check the comment, for next steps.

My current workaround:

kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml
kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
kubectl patch storageclass local-path -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

[svteb]

After a short discussion with @HashNuke some of my misconceptions were cleared up. The reason rancher.io/local-path storageclass is among the supported storageclasses for spec tests is due to the fact that it is the default KinD storage provider. Thus the spec test will pass even if non-elastic storage provisioner is used (with KinD).

The remediation for this ticket would then be to include the default storage providers of other popular cluster creation tools (minikube, k3s, microk8s).

[svteb]

After a short discussion with @HashNuke some of my misconceptions were cleared up. The reason rancher.io/local-path storageclass is among the supported storageclasses for spec tests is due to the fact that it is the default KinD storage provider. Thus the spec test will pass even if non-elastic storage provisioner is used (with KinD).

The remediation for this ticket would then be to include the default storage providers of other popular cluster creation tools (minikube, k3s, microk8s).

A small update to this: I've noticed that the bitnami mariadb and bitnami mysql will in fact not deploy with minikubes default storage provisioner. I don't know what exactly local-path does differently, but for now it seems to be the way to go. The same issue seems to occur with sample-cnfs/ndn-multi-db-connections-fail/cnf-testsuite.yml.

The new new remediation should be noting somewhere in documentation that certain storageclasses just don't work.