Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem (please be detailed as possible and provide log snippests): PVC expansion is not disabled for ocs-deviceset and mon PVCs. Expand PVC option is working and the change is reflected on the PVC and corresponding PV. eg: Capacity of ocs-deviceset-0-data-0-cmkmj, ocs-deviceset-1-data-0-vwlcd, rook-ceph-mon-b are increased. $ oc get pvc -n openshift-storage NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE db-noobaa-db-0 Bound pvc-25063200-787a-4ac9-82fb-4c197ca33a3a 60Gi RWO ocs-storagecluster-ceph-rbd 7h43m ocs-deviceset-0-data-0-cmkmj Bound pvc-af5e779a-4c0b-4ee6-96c3-f8c9339136eb 513Gi RWO gp2 7h43m ocs-deviceset-1-data-0-vwlcd Bound pvc-92928a39-9b0d-4ffd-80a0-fac019556ebc 900Gi RWO gp2 7h43m ocs-deviceset-2-data-0-5ghwx Bound pvc-10f469b5-9efd-44ce-910d-eba8b90d6eb1 512Gi RWO gp2 7h43m rook-ceph-mon-a Bound pvc-3dab2892-5f87-4b08-8f31-625d57c15b48 10Gi RWO gp2 7h46m rook-ceph-mon-b Bound pvc-d1c89be6-5382-43d1-80de-ed36ff623ec2 20Gi RWO gp2 7h46m rook-ceph-mon-c Bound pvc-0dde09ac-56f0-4cbb-9294-a18a2058386e 10Gi RWO gp2 7h45m $ oc get pv | grep openshift-storage pvc-0dde09ac-56f0-4cbb-9294-a18a2058386e 10Gi RWO Delete Bound openshift-storage/rook-ceph-mon-c gp2 8h pvc-10f469b5-9efd-44ce-910d-eba8b90d6eb1 512Gi RWO Delete Bound openshift-storage/ocs-deviceset-2-data-0-5ghwx gp2 8h pvc-25063200-787a-4ac9-82fb-4c197ca33a3a 60Gi RWO Delete Bound openshift-storage/db-noobaa-db-0 ocs-storagecluster-ceph-rbd 8h pvc-3dab2892-5f87-4b08-8f31-625d57c15b48 10Gi RWO Delete Bound openshift-storage/rook-ceph-mon-a gp2 8h pvc-92928a39-9b0d-4ffd-80a0-fac019556ebc 900Gi RWO Delete Bound openshift-storage/ocs-deviceset-1-data-0-vwlcd gp2 8h pvc-af5e779a-4c0b-4ee6-96c3-f8c9339136eb 513Gi RWO Delete Bound openshift-storage/ocs-deviceset-0-data-0-cmkmj gp2 8h pvc-d1c89be6-5382-43d1-80de-ed36ff623ec2 20Gi RWO Delete Bound openshift-storage/rook-ceph-mon-b gp2 8h However, the cluster capacity remains the same. $ oc exec rook-ceph-tools-5685c79ff4-b5st4 -- ceph status | grep usage usage: 18 GiB used, 1.5 TiB / 1.5 TiB avail This is tested in AWS platform. Couldn't test in VMware due to bug https://bugzilla.redhat.com/show_bug.cgi?id=1846373 This issue is not observed in BareMetal cluster. Error was thrown while expanding ocs-deviceset PVC. "An error occurred persistentvolumeclaims "ocs-deviceset-0-data-0-k6vhk" is forbidden: only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize" =================================================================================== Version of all relevant components (if applicable): OCP 4.5.0-0.nightly-2020-06-17-00150 OCS 4.5.0-449.ci Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? No Is there any workaround available to the best of your knowledge? No Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? 1 Can this issue reproducible? Yes Can this issue reproduce from the UI? Yes If this is a regression, please provide more details to justify this: Steps to Reproduce: 1. From console go to 'Storage' --> 'Persistent Volume Claims' and select an ocs-deviceset PVC. 2. Use 'Expand PVC' options from 'Actions' drop down to increase the PVC size. Actual results: PVC and PV size was updated to new value without any error. Expected results: PVC expand should not work for ocs-deviceset and mon PVCs. Additional info:
logs- http://rhsqe-repo.lab.eng.blr.redhat.com/OCS/ocs-qe-bugs/BZ-1848050/
As the PVC expansion operation, for ocs-deviceset and mon PVCs, is possible from the console, raising severity and marking as a blocker
Can we please have an explanation here, why ocs-deviceset and mon PVC's should not be expanded? and what are the side effects on OCS in doing so?
Hi Anmol, I think it's pretty clear. OCS doesn't support OSDs of different sizes. OSD and mon pvc expansion is not something the user should be able to do. The implications could be severe. So it should not be exposed via the console.
At this point nothing can be done from UI to fix this. Moving it to OCS operator to take a call. Its more of an architectural decision to allow it or not.
There's nothing that we can do here from the OCS Operator side. We just consume the StorageClasses we're given, we can't do anything to modify them. At best we can document a warning to just not do this.
To reiterate: this is the admin's responsibility, not ours. At best we could document a request that they only provide StorageClasses that explicitly disable expansion. Or, you know, just tell them to NOT expand them ever in the first place. At best this is a documentation effort. If we don't have at least a warning telling hte admin to never resize our consumed PVCs, we should add that. Moving it to the documentation component so we can determine if it can go in 4.5 or not.
(In reply to Jose A. Rivera from comment #10) > At best this is a documentation effort. If we don't have at least a warning > telling hte admin to never resize our consumed PVCs, we should add that. > Moving it to the documentation component so we can determine if it can go in > 4.5 or not. Hi Jose, As Martin pointed out, there are ongoing discussions in the email http://post-office.corp.redhat.com/archives/rhocs-eng/2020-July/msg00125.html Hence, it would be best to wait for the confirmation before accepting it as a doc fix.