I think we will need this sooner rather than later because in conjunction with automatic PVC resize you can come up to pretty strange results which can lead to unpredictable cluster issues.

If you scale down, resize and scale up again you will have PVC with different size and we can only imagine how the database and cluster will fail once some of these PVCs get full.

$ k get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-73d8eeea-21dd-44ad-a4e0-71f82d809c40 10Gi RWO Delete Bound test/datadir-cluster1-pxc-1 standard-rwo 23m
pvc-8b3f9eab-e2b1-4e5c-aad2-305a22dedf3b 6Gi RWO Delete Bound test/datadir-cluster1-pxc-3 standard-rwo 21m
pvc-d45a5a9f-4198-4509-9a4f-0a6f92ed134c 10Gi RWO Delete Bound test/datadir-cluster1-pxc-2 standard-rwo 22m
pvc-edfafefb-48b4-4d4f-b8d7-cd64fe3683ae 6Gi RWO Delete Bound test/datadir-cluster1-pxc-4 standard-rwo 20m
pvc-f1e23823-c523-4b6b-9040-65e2a188722a 10Gi RWO Delete Bound test/datadir-cluster1-pxc-0 standard-rwo 24m

$ k get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
datadir-cluster1-pxc-0 Bound pvc-f1e23823-c523-4b6b-9040-65e2a188722a 10Gi RWO standard-rwo 25m
datadir-cluster1-pxc-1 Bound pvc-73d8eeea-21dd-44ad-a4e0-71f82d809c40 10Gi RWO standard-rwo 23m
datadir-cluster1-pxc-2 Bound pvc-d45a5a9f-4198-4509-9a4f-0a6f92ed134c 10Gi RWO standard-rwo 22m
datadir-cluster1-pxc-3 Bound pvc-8b3f9eab-e2b1-4e5c-aad2-305a22dedf3b 6Gi RWO standard-rwo 21m
datadir-cluster1-pxc-4 Bound pvc-edfafefb-48b4-4d4f-b8d7-cd64fe3683ae 6Gi RWO standard-rwo 20m

$ k get pxc
NAME ENDPOINT STATUS PXC PROXYSQL HAPROXY AGE
cluster1 cluster1-haproxy.test ready 5 3 25m