-
Notifications
You must be signed in to change notification settings - Fork 272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changing storageClassName in CR does not change the PVC resource #992
Comments
The underlying |
Thanks for the response! I think using a validating webhook for this field makes sense if you decide not to support this functionality |
I think it'd be an interesting feature at some point but it's not a simple one. It'd require a new statefulset with new PVCs with new PVs and transferring data from old volumes to the new volumes (or perhaps a blue-green migration on the RabbitMQ level). And on top of that - all the possible issues that can occur in the process (failures, out of disk issues, etc). Here's a blog post explaining how to do that for Percona MySQL https://www.percona.com/blog/2021/04/20/change-storage-class-on-kubernetes-on-the-fly/ to give an idea |
@hoyhbx Just as Michal commented above, allowing updating storage class name is rather complicated and underlaying infrastructure will play a factor . The team has decided not to implement this feature for the time being. |
Hi all @ChunyiLyu @Zerpet @mkuratczyk , Kubernetes recently is having a new feature support This feature enables us to reject the storageClassName change elegantly without implementing a validating webhook, we can add a marker to the field in types.go: We can create a PR fixing this using |
Describe the bug
I was trying to change the
persistence/storageClassName
field in my rabbitmq-cluster's CR, but changing thepersistence/storageClassName
has no effect on the PVC used by the statefulSet.The
persistence/storageClassName
field was initially not specified so the operator used the default storage class "standard". Then I created a new storage class following instruction here https://github.com/rabbitmq/cluster-operator/blob/main/docs/examples/production-ready/ssd-gke.yaml, and changedpersistence/storageClassName
fromnull
tossd
. This change failed silently.To Reproduce
Steps to reproduce this behavior:
kubectl apply -f https://github.com/rabbitmq/cluster-operator/releases/latest/download/cluster-operator.yml
kubectl apply -f https://github.com/rabbitmq/cluster-operator/blob/main/docs/examples/production-ready/ssd-gke.yaml
persistence/storageClassName
tossd
and applyExpected behavior
The PVC with the desired storage class being created to replace the old PVC.
Screenshots
If applicable, add screenshots to help explain your problem.
Version and environment information
Addition context
This bug is caused because the operator only reconciles the PVC's storage capacity, but does not reconcile the storageClassName here:
cluster-operator/controllers/reconcile_persistence.go
Line 15 in d657ffb
Possible fix is to create the desired storage type and migrate the data over. Or report an error message like PVC scaling down here:
cluster-operator/internal/scaling/scaling.go
Line 51 in d657ffb
The text was updated successfully, but these errors were encountered: