You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Thanks for the feedback. This sounds like a reasonable fix/enhancement to me.
Unfortunately, I don't have much time to spend on this project lately so I can make suggestions and provide guidance but I won't have time to implement it. I highly encourage you to give it a try yourself (or anyone else interested in this) if you can!
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 asstorageClassName
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 akubectl 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 thegroupname-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.
The text was updated successfully, but these errors were encountered: