Description
I'm a newbie checking out the clustered feature with an explicit group name, with version 0.5.
When creating an SmbShare with clustering, the operator created a small PVC called groupname-state. This gets mounted (at least in some containers) at /var/lib/ctdb/shared. It is a ReadWriteMany PVC (makes sense, of course).
This didn't work well for me, because I don't have a default storageClass that creates ReadWriteMany PVCs. (I guess I could have one -- I just hadn't set things up that way). So, I would need to specify a storageClassName for the PVC.
I tried editing the (operator-created) PVC to add the storageClassName, but of course that didn't work, because PVC's are immutable (at least as far as storageClassName goes).
I tried deleting the PVC so that I could recreate it, with the storageClassName added. I was able to delete it, but the operator always recreated it faster than I could. (Even with a kubectl delete pvc/... && kubectl apply -f ...)
So, ultimately what I needed to do was delete the SmbShare itself. I then was able to pre-create the PVC with the name that the operator would expect. (That is, precreate the PVC with the same name that the operator would create). I could then re-create the SmbShare, and the operator appears to have been happy to simply use the pre-created PVC.
That's a workaround, then, for anyone in a similar situation. Ultimately, it might be nice to make the storageClassName configurable for the groupname-state PVC, or (alternatively) allow the user to explicitly provide a pre-created PVC (like one can for the SmbShare files themselves).
I'll flesh out that suggestion if time permits, but I thought I'd mention the issue anyway, especially since the workaround might be useful to someone.