✨PersistentVolumeClaim support UWS status update

[wondywang]

User Story

As a user, I want to update the spec.resources.requests.storage of PVC, but I found that after updating requests.storage, status.capacity.storage is not updated synchronously, resulting in an exception when kubectl get pvc.

Detailed Description

Anything else you would like to add:

Should we consider updating the pPVC status synchronously to the pPVC?

/kind feature

[Fei-Guo]

The question is who updates the status field? If it is updated by the controller running in the KCM, then no synchronization is needed. If it is updated by the CSI driver running in the super cluster, then synchronization is needed. I vaguely remember once we populate PV object in the VC, the pvc status is updated correctly. But I may be wrong here.

[wondywang]

Yes，At present, the PVC status.capacity is updated by the CSI driver (maybe by kubelet) after allocating storage space. and now after the spec.requests.storage of the PVC is updated in the VC, it is synchronized to the super, and then the PVC status on the super is updated by the CSI driver, but the status in the VC has not been updated.

[Fei-Guo]

Sure. Then adding pvc uws makes sense. Btw, I did not get this part " an exception when kubectl get pvc." . What is the error?

[wondywang]

Sure. Then adding pvc uws makes sense. Btw, I did not get this part " an exception when kubectl get pvc." . What is the error?

$ kubectl get pvc data0-1 -n confluent
NAME            STATUS   VOLUME                   CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
data0-1         Bound       d-2zexxxxxxxxxxxxxx   1000Gi           RWO            storageclass-name                13d

It will show like this, capacity is displayed incorrectly. But in fact, the storage of PVC has been resized to 1200Gi.