HoustonPutman commented on PR #712: URL: https://github.com/apache/solr-operator/pull/712#issuecomment-4172977862
Ok, good and bad news here: **Good news**: I got a local expandable-PVC setup working using the [RawFile PV project from open-ebs](https://github.com/openebs/rawfile-localpv). **Bad news**: This PR doesn't work because of the way that PVC expansion works, at least for this storage provider. The way we do it in the operator, we increase the request for all PVCs manually, then wait for them to be updated and have the new capacity. Then we issue a rolling restart so that the pods get the new storage that has been allocated to them. However this storage provider, and possibly all of them, require a pod to be restarted before the PVC's storage status gets updated to the new value. So we stall out because the Solr-operator is waiting on the PVC's statuses to be updated, and the Storage-class operator is waiting on the Pods to be updated. We need to investigate if all storage classes operate this way, and if so change the logic to do a rolling restart when the PVCs are in `FileSystemResizePending` condition. Then at the end make sure all the PVCs are the right size. This is definitely more complex than the current logic. Also in newer versions of Kubernetes, there are better ways of monitoring the PVC to see what is happening: https://kubernetes.io/blog/2025/09/19/kubernetes-v1-34-recover-expansion-failure/ These new PVC fields are beta in 1.32 and GA in 1.34, and off by default in all versions before 1.32. Since the Solr Operator supports many more versions than that, I'm hesitant to bump up the required version by so much just to make use of these. But it would make the code better IMO and more resilient when used across many different storage providers. Lots to think about, and certainly not decisions I want to make myself. @janhoy , would you be able to test in your setup to ensure that your storage provider behaves the same way? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
