Closed wondywang closed 1 year ago
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.
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.
Sure. Then adding pvc uws makes sense. Btw, I did not get this part " an exception when kubectl get pvc." . What is the error?
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.
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