Rejected change to storageConfig.CassandraDataVolumeClaimSpec even with cassandra.datastax.com/allow-storage-changes annotation #854
Description
What happened?
Good day team! We were planning to expand and increase our Cass storage (pvc) from initially set value in the CassandraDatacenter crd (from 10Gi to 50Gi). However there seems to be an admission webhook to prevent on-the-fly change to increase/expand storage on the manifest yaml.
We found one of the PRs to set the annotation of 'cassandra.datastax.com/allow-storage-changes' to true and expecting to be able to handle storage changes already, but looks like changes are still blocked by the admission webhook. It this really the expected behavior?
As of this writing, there is a current drift with our cass manifest (stating 10Gi) while we've already increased the underlying PVCs to 50 Gi. We wanted to check if there is a more sophisticated way in order for our configs to be synced. If there is any way the manifest CRD can be changed to 50Gi so it would be uniform.
Appreciate any feedback, thank you!
What did you expect to happen?
We found one of the PRs to set the annotation of 'cassandra.datastax.com/allow-storage-changes' to true and expecting to be able to handle storage changes already, but looks like changes are still blocked by the admission webhook. For now, we've adjust manually the underlying PVCs to accommodate storage growth.
How can we reproduce it (as minimally and precisely as possible)?
[1] A spawned Cass cluster from initial storage size via CassandraDatacenter crd then try to perform an increase via code change. Expecting for PVCs to also expand (with allowVolume expansion).
[2] Already expanded PVC that has drift with the CRD manifest. Sync the manifest yaml to the expanded value of PVC
cass-operator version
1.21.1
Kubernetes version
v1.30.14
Method of installation
Operator
Anything else we need to know?
No response