Bug 1870334
| Summary: | Ceph-CSI should allow providing a different size for creating Clone PVC/restore PVC | ||
|---|---|---|---|
| Product: | [Red Hat Storage] Red Hat OpenShift Data Foundation | Reporter: | Neha Berry <nberry> |
| Component: | csi-driver | Assignee: | Yug Gupta <ygupta> |
| Status: | CLOSED DEFERRED | QA Contact: | Jilju Joy <jijoy> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.6 | CC: | ebondare, edonnell, etamir, hchiramm, madam, mrajanna, muagarwa, ndevos, ocs-bugs, odf-bz-bot, srangana, ygupta |
| Target Milestone: | --- | Keywords: | AutomationBackLog, FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | 4.10.0-113 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-02-01 13:17:11 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1882359 | ||
|
Description
Neha Berry
2020-08-19 19:15:53 UTC
Neha, thanks for opening this bug as a followup for our discussion. I would like to share couple of thoughts here: First of all, this scenario was communicated ( we will be supporting same size restore) since EPIC readout. This will be documented as well. We had also provided this requirement to UI team since start and the only reason for them to not enable till now was, the code is general one for OCP and OCS drivers. We will check on what extra we can do here from CSI driver: But, I would like to request couple of experiments from your end: 1) Can you try the same for CephFS now with OCS 4.6 build ? -> it should work 2) Can you also try editing or patching the PVC to match the size of parent PVC when its pending and while you have this error ? (In reply to Humble Chirammal from comment #4) > Neha, thanks for opening this bug as a followup for our discussion. > > I would like to share couple of thoughts here: > > First of all, this scenario was communicated ( we will be supporting same > size restore) since EPIC readout. This will be documented as well. We had > also provided this requirement to UI team since start and the only reason > for them to not enable till now was, the code is general one for OCP and OCS > drivers. > > We will check on what extra we can do here from CSI driver: > > But, I would like to request couple of experiments from your end: > > 1) Can you try the same for CephFS now with OCS 4.6 build ? -> it should > work > 2) Can you also try editing or patching the PVC to match the size of parent > PVC when its pending and while you have this error ? I can try it in a day or two. thanks I tried cloning with a bigger size than original for CephFS today, it worked without any issues. (In reply to Humble Chirammal from comment #4) > Neha, thanks for opening this bug as a followup for our discussion. > > I would like to share couple of thoughts here: > > First of all, this scenario was communicated ( we will be supporting same > size restore) since EPIC readout. This will be documented as well. We had > also provided this requirement to UI team since start and the only reason > for them to not enable till now was, the code is general one for OCP and OCS > drivers. > > We will check on what extra we can do here from CSI driver: > > But, I would like to request couple of experiments from your end: > > 1) Can you try the same for CephFS now with OCS 4.6 build ? -> it should > work As per #comment6, this works. > 2) Can you also try editing or patching the PVC to match the size of parent > PVC when its pending and while you have this error ? For pending rbd PVC, editing the requested storage does not work. $ oc patch PersistentVolumeClaim test-clone-pvc-clone -p '{"spec": {"resources": {"requests": {"storage": "5Gi"}}}}' The PersistentVolumeClaim "test-clone-pvc-clone" is invalid: * spec: Forbidden: spec is immutable after creation except resources.requests for bound claims core.PersistentVolumeClaimSpec{ AccessModes: []core.PersistentVolumeAccessMode{"ReadWriteOnce"}, Selector: nil, Resources: core.ResourceRequirements{ Limits: nil, - Requests: core.ResourceList{ - s"storage": {i: resource.int64Amount{value: 5368709120}, s: "5Gi", Format: "BinarySI"}, - }, + Requests: core.ResourceList{ + s"storage": {i: resource.int64Amount{value: 10737418240}, s: "10Gi", Format: "BinarySI"}, + }, }, VolumeName: "", StorageClassName: &"ocs-storagecluster-ceph-rbd", ... // 2 identical fields } * spec.resources.requests.storage: Forbidden: field can not be less than previous value Thanks Jilju, yeah so we are getting expected result. :). Its blocked to have a lesser value once we have the size, thats what the actual blocker for recovering from failed resize too. however wanted to double confirm this at very first provisioning. The CephFS result is actually temporary till we have a core fix in CephFS on size of clone attribute. Once its available we will be disabling it just to make sure we have parity between our RBD and CephFS driver. We will also explore if we could support this for both. But, I dont want to introduce any confusion here or our current plan is to stick with the requirement listed or agreed at start of the feature planning which is nothing but we wont be allowing volume restore/clone on bigger size. Humble, have we reached on some consensus here? Should we close this as WONT_FIX or move to next release if there is some plan to do this in future. Targetting this to OCS 4.7 or beyond as we need to get the support from the upstream kube side. Madhu, should we add doc_text for this know issue? Still dependent on upstream kubernetes changes, can't be fixed in 4.9 Yug, it seems that the Cinder CSI-driver does a resize in NodeStageVolume() now. This looks like something that we can do as well. See https://github.com/kubernetes/cloud-provider-openstack/pull/1563 for details. Sure. |