Clarify size of cloned / restored volumes #452

jsafrane · 2020-09-21T09:45:00Z

Add a few notes to CreateVolume about expected content of the volume after volume clone / snapshot restore.

Explicitly, when cloning a volume or restoring a snapshot to a bigger volume, the new volume may need NodeExpandVolume call to resize the filesystem (resize2fs, xfs_growfs, ...) to make the bigger capacity available to workloads.

Example: user clones 1GiB ext4 volume into a 2GiB volume. In CSI it looks like CreateVolumeRequest.CapacityRange = 2GiB. SP should clone the volume as it is, not changing the filesystem metadata. Depending on what CO wants, it may keep the new volume as it is (i.e. containers will see just 1GiB of usable space) or it may call NodeExpandVolume to make the whole volume available to the user.

msau42 · 2020-10-07T16:50:07Z

spec.md

@@ -725,7 +725,11 @@ Plugins MAY create 3 types of volumes:

 - Empty volumes. When plugin supports `CREATE_DELETE_VOLUME` OPTIONAL capability.
 - From an existing snapshot. When plugin supports `CREATE_DELETE_VOLUME` and `CREATE_DELETE_SNAPSHOT` OPTIONAL capabilities.
+  SP SHOULD create a volume that looks like exact copy of the original snapshotted volume at the time the snapshot was taken.
+  If the newly created volume is larger than the original volume and SP supports `EXPAND_VOLUME` node capability, CO SHOULD call `NodeExpandVolume` to make the extra space on the volume available to the workloads. 


Do we want to clarify that SP should return the size of the original volume? Also controller expand may also be called.

msau42 · 2020-10-07T16:50:24Z

cc @bswartz @gnufied

gnufied · 2020-10-07T17:05:00Z

spec.md

@@ -725,7 +725,11 @@ Plugins MAY create 3 types of volumes:

 - Empty volumes. When plugin supports `CREATE_DELETE_VOLUME` OPTIONAL capability.
 - From an existing snapshot. When plugin supports `CREATE_DELETE_VOLUME` and `CREATE_DELETE_SNAPSHOT` OPTIONAL capabilities.
+  SP SHOULD create a volume that looks like exact copy of the original snapshotted volume at the time the snapshot was taken.
+  If the newly created volume is larger than the original volume and SP supports `EXPAND_VOLUME` node capability, CO SHOULD call `NodeExpandVolume` to make the extra space on the volume available to the workloads. 


should we say "original volume" or say - VolumeContentSource ?

I think usage of volumeContentSource is correct but with an additional mention that snapshot or PVC as data source, because may be in future we may have more data sources which dont support restore or clone operation ?

humblec · 2020-10-07T17:05:03Z

Depending on what CO wants, it may keep the new volume as it is (i.e. containers will see just 1GiB of usable space)

@jsafrane but, if CSI driver respond success to this call without expanding or delivering bigger volume, from user POV, the PVC request satisfied however with a lesser size, Isnt it against the desired state ?

jsafrane · 2020-10-08T07:54:56Z

No, CO requested 2 GiB and SP MUST provide at least 2GiB. But it does not say anything about size of the actual filesystem on the volume. It may be (and IMO should) still be 1GiB. For filesystem volumes, containers will see only this 1 GiB filesystem.

bswartz · 2020-10-08T13:50:13Z

My opinion is that we should modify the wording to suggest that for new/empty volumes, the SP MUST ensure the filesystem is the correct size on creation, and for cloned/restored volumes the SP SHOULD correct the size on creation if it does not implement expand, but for SPs that do implement expand they MAY return the smaller size and leverage the CO's resize behavior to get the filesystem expanded.

msau42 · 2020-10-08T16:14:50Z

How will the CO know that a node expansion is still required if the SP returns the requested size?

bswartz · 2020-10-08T16:26:38Z

It wouldn't. The SP returning the incorrect size is the only way to signal that more work is needed. We just need to clarify that it's only valid to do that if the SP also supports expand (otherwise the CO can't take corrective action) and we should discourage doing that for new/empty volumes in the strongest language we can get away with.

Jiawei0227 · 2020-10-09T06:36:43Z

and for cloned/restored volumes the SP SHOULD correct the size on creation if it does not implement expand, but for SPs that do implement expand they MAY return the smaller size and leverage the CO's resize behavior to get the filesystem expanded.

Are you suggesting that if SP does not implement expand, it will return a smaller size of volume?

Jiawei0227 · 2020-10-09T06:43:02Z

spec.md

@@ -725,7 +725,11 @@ Plugins MAY create 3 types of volumes:

 - Empty volumes. When plugin supports `CREATE_DELETE_VOLUME` OPTIONAL capability.
 - From an existing snapshot. When plugin supports `CREATE_DELETE_VOLUME` and `CREATE_DELETE_SNAPSHOT` OPTIONAL capabilities.
+  SP SHOULD create a volume that looks like exact copy of the original snapshotted volume at the time the snapshot was taken.


No, CO requested 2 GiB and SP MUST provide at least 2GiB. But it does not say anything about size of the actual filesystem on the volume. It may be (and IMO should) still be 1GiB. For filesystem volumes, containers will see only this 1 GiB filesystem.

Isnt this conflict with the example above? We should clarify the content should be the exact copy but SP can return with a larger size of Volume, although only a portion of it might be used

Jiawei0227 · 2020-10-09T06:47:30Z

I think we should keep the current behavior of SP. The behavior change seems need to be done on the CO side.

CO should check if SP has expansion capability.

If has, CO MAY leverage the resize behavior of the SP and do a smaller size(1G) CreateVolumeRequest. And then, CO can apply a controller/node expansion operation on that volume.
If not, CO should keep the user request as it is and return the request size(2G) with a smaller file system(1G)

humblec · 2020-10-09T07:14:49Z

SP SHOULD create a volume that looks like exact copy of the original snapshotted volume at the time the snapshot was taken

@jsafrane afacit, this is not specific or not only applicable to snapshot , its equally applicable to volume data source /PVC too. So we should include that.

If the newly created volume is larger than the original volume and SP supports EXPAND_VOLUME node capability, CO SHOULD call NodeExpandVolume to make the extra space on the volume available to the workloads.

IMO, we should make this clarified in terms of : how CO interpret the volume returned from SP is larger than the original volume?.
Also, the expansion call is not limited to NodeExpansion and iic, we are implicitly mentioning here that, whatever required actions has to be performed by a SP driver on ControllerExpand has to be performed in a mandatory manner at time of restore call to a bigger volume or IOW, without any trigger from CO. Is that understanding clear?

I have an additional question: What about BLOCK volume modes and for volume types which dont require NodeExpansion? . All the operations are performed by the SP driver at createVolume has already performed, so above wording give a false impression saying CO will call NodeExpandVolume in this case. Isnt it ?

bswartz · 2020-10-09T12:01:22Z

Also, the expansion call is not limited to NodeExpansion and iic, we are implicitly mentioning here that, whatever required actions has to be performed by a SP driver on ControllerExpand has to be performed in a mandatory manner at time of restore call to a bigger volume or IOW, without any trigger from CO. Is that understanding clear?

ControllerExpand should never be necessary after creating a volume from a clone/snapshot, because any resizing that needs to be done on the controller can and should have been done as part of the CreateVolume call. The existing language is clear about that much at least.

I have an additional question: What about BLOCK volume modes and for volume types which dont require NodeExpansion? . All the operations are performed by the SP driver at createVolume has already performed, so above wording give a false impression saying CO will call NodeExpandVolume in this case. Isnt it ?

For raw block volumes, there should not be node work to complete the expansion. The only case when nodes need to be involved in raw block volume expansion is when the volume is in use at the time of expansion, and that doesn't apply for newly-created volumes because they can't be in use at creation time.

humblec · 2020-10-09T12:12:51Z

Also, the expansion call is not limited to NodeExpansion and iic, we are implicitly mentioning here that, whatever required actions has to be performed by a SP driver on ControllerExpand has to be performed in a mandatory manner at time of restore call to a bigger volume or IOW, without any trigger from CO. Is that understanding clear?

ControllerExpand should never be necessary after creating a volume from a clone/snapshot, because any resizing that needs to be done on the controller can and should have been done as part of the CreateVolume call. The existing language is clear about that much at least.

@bswartz I am/was not sure, all the storages support CLONE operation with a different size, Is that the case ? if thats how things are, we could discard that mention.

I have an additional question: What about BLOCK volume modes and for volume types which dont require NodeExpansion? . All the operations are performed by the SP driver at createVolume has already performed, so above wording give a false impression saying CO will call NodeExpandVolume in this case. Isnt it ?

For raw block volumes, there should not be node work to complete the expansion. The only case when nodes need to be involved in raw block volume expansion is when the volume is in use at the time of expansion, and that doesn't apply for newly-created volumes because they can't be in use at creation time.

Sure, I am on same page, my request was that, above wording kind of conveying a message that ( atleast to me) CO will issue NodeExpand call, regardless of the volume mode or regardless of NodeExpansion required flag for the volume provisioned by the SP.

bswartz · 2020-10-09T12:21:22Z

ControllerExpand should never be necessary after creating a volume from a clone/snapshot, because any resizing that needs to be done on the controller can and should have been done as part of the CreateVolume call. The existing language is clear about that much at least.

@bswartz I am/was not sure, all the storages support CLONE operation with a different size, Is that the case ? if thats how things are, we could discard that mention.

My theory is that, whatever the controller was going to do in response to the ControllerExpand() call, it has all the information it needs to performs the same operations during a CreateVolume() call, so there's zero value in asking the CO to make a ControllerExpand() in addition to the CreateVolume(). The existing spec wording says this unambiguously.

Personally I also think the existing spec wording implies that NodeExpandVolume() should also be unecessary, but I think it's vague enough that we can get away with changing it and that shouldn't break anyone.

humblec · 2020-10-09T12:30:53Z

ControllerExpand should never be necessary after creating a volume from a clone/snapshot, because any resizing that needs to be done on the controller can and should have been done as part of the CreateVolume call. The existing language is clear about that much at least.

@bswartz I am/was not sure, all the storages support CLONE operation with a different size, Is that the case ? if thats how things are, we could discard that mention.

My theory is that, whatever the controller was going to do in response to the ControllerExpand() call, it has all the information it needs to performs the same operations during a CreateVolume() call, so there's zero value in asking the CO to make a ControllerExpand() in addition to the CreateVolume(). The existing spec wording says this unambiguously.

imo, above is not really the case. That said, as an example, the provisioner secret which is part of the createVolume() could be different from the controller expand secret which comes in ControllerExpand call. Isnt it ?

Personally I also think the existing spec wording implies that NodeExpandVolume() should also be unecessary, but I think it's vague enough that we can get away with changing it and that shouldn't break anyone.

👍

bswartz · 2020-10-09T14:19:06Z

imo, above is not really the case. That said, as an example, the provisioner secret which is part of the createVolume() could be different from the controller expand secret which comes in ControllerExpand call. Isnt it ?

Yes the secrets could in theory be different, but CSI drivers get to define what secrets they need. If a driver needs an additional secret to expand that's not needed for create (hard to imagine how that would happen) then the CSI plugin just has to be deployed in such a way that both secrets are supplied to create. This is as easy as modifying the storage class.

IMO the vast majority of drivers don't use secrets at all, or if they do, it's the same secret for all controller operations.

saad-ali · 2020-10-14T17:06:53Z

Meeting Notes from CSI Meeting Oct-14-2020

@bswartz - What happens if resize capability not implemented by a plugin? Silently succeeding in that case seems wrong. Should we say that the call should fail?
@jsafrane - Can add wording for that. But can we do this in a backwards compatible way?
@bswartz - Current wording already says the expectation is that the new volume should be larger. It just doesn't clarify what to do on the node side.
@msau42 - CreateVolume should return old size? If the plugin reports the bigger size, how does k8s know that it needs to do NodeExpand? Does it always do it?
@jsafrane - Yes, it should be idempotent.
@msau42 - NodeExpand is signaled on the Kubernetes side by "Resize Pending" condition.
@jsafrane - On k8s side we can fake resize (since we know original size and new size).
@msau42 - So k8s external-provisioner would add all the correct conditions to trigger resize?
@jsafrane - Yes.
@bswartz - Why not return the small size?
@jsafrane - It's odd if CSI reports the wrong size. If we report the wrong size we would need to add a new capability to keep it clean.
@msau42 - Filesystem Resize Pending condition is on the PVC
@jsafrane - That is bad. But if we say CSI return smaller size -- it will break existing drivers. ControllerCreateVolume is pretty strict about what it should return.
@bswartz - It is not reasonable for controller plugin to resize the filesystem
geguileo - when I connect a block volume with FS, I check if the FS is smaller and I do FS resize. As part of NodeStage.
@bswartz - So you are saying take this out of k8s hand, and force the SP to handle it?
geguileo - Yep
@bswartz - That forces SP to know desired size at NodeStage time.
geguileo - Yes, but SP can pass parameters to keep track of that.
@bswartz - Sure, but they shouldn't have to, that's why NodeExpand exists.
geguileo - Some backends can only do expand from Node, not controller (maybe it is for that).
@msau42 - Also for online expansion case
@jsafrane - Makes drivers more complicated, and is incompatible.
@msau42 - Well existing drivers will continue to function as is right?
@jsafrane - During regular resize, no NodeExpand because it will be part of node publish?
@msau42 - What if we keep NodeExpand as is for regular resize, but new behavior for CreateVolume?
@jsafrane - That could get complicated, some volumes are resized on NodePublish, some on NodeExpand.
@bswartz - Maybe a new flag for SP to request a NodeExpandVolume if they want it and don't want to do extra work?
@jsafrane - Gets pretty complicated.
@xing-yang - Having driver return smaller size may be better?
@jsafrane - CreateVolume size has to be from capacity range.
@msau42 - What if k8s sends in smaller size.
@jsafrane - We could do that for those who do resize.
@bswartz - That would result in much less efficient process if storage backend is capable.
@jsafrane - If CO input to CreateVolume is a range of capacity, and if SP picks from range, but SP returns a lower size, what should CO think the range as the "real size"
@msau42 - CO should send in smaller size.
@jsafrane - It will work, it is just inefficient.
@msau42 - Functionality vs efficiency tradeoff?
@jsafrane - If a driver supports resize, we can handle on k8s side, but what if resize is not supported? Should it fail?
@msau42 - Ya, and what if SP does supports controller reisze but does support node resize?
@bswartz - That would result in a volume of size user didn't want, and we can't do anything.
@saad-ali - Maybe let's not align with resize?
@jsafrane - It would be odd to have a completely different way to invoke same thing.
@bswartz - Every time you publish having to do a resize check -- so you better make sure that check is reliable or you could slow down the publish path. If you get check wrong and call resize FS when you don't need to, that will be expensive. It makes me nervous leaving it up to SP.
@jsafrane - For XFS, check how many blocks on raw device, so it should be relatively cheap, not sure about other FS. I can check after meeting.
@jsafrane - Did we agree to put it on SP side?
@bswartz - I can agree with that, but wonder if we should do anything in the future to make it less painful.
@msau42 - First let's do the investigation to see how error prone this may be. After that, we can decide.
@bswartz - maybe some tests to CSI sanity and k8s E2E tests to ensure SPs are doing the right thing
@jsafrane - if driver is stupid and doesn't do anything what happens?
@msau42 - same behavior as today, and that should fail our new test since it will be spec incompatible.
@jsafrane - If I want to be spec compliant, and I can't resize FS automatically, I should fail the create call?
@bswartz - Yes.
@msau42 - No driver does that.
@jsafrane - Ceph does.
@bswartz - Yes, and we can add tests to make sure they do.
@saad-ali - Windows complexity?
@msau42 - Should sync with @ddebroy and Jing on this.
@jsafrane - Will that be just one control plane for windows and linux?
@msau42 - Today control-plane is Linux only. Node could be either. But I guess no limitation that control plane can't be windows (except k8s doesn't build Windows versions of sidecars), but none of the calls should be OS specific.

Action item: try and implement in driver to see how painful it is. Come back to next meeting to discuss.

ddebroy · 2020-10-16T16:44:55Z

Windows complexity?

Windows node plugins do have the ability to handle NodeExpandVolume. csi-proxy already surfaces the API to resize a file system on a volume. So if the plugin reports EXPAND_VOLUME node capability and accordingly gets invoked during publish, the above proposal should work out for Windows nodes.

Slightly off-topic from the conversation above: it appears, GCE PD resizer does not handle Windows nodes (please correct me if I am incorrect). In such scenarios, does the CSI node plugin report EXPAND_VOLUME node capability based on it's ability to handle it for Linux nodes only? cc @msau42 Jing

Will that be just one control plane for windows and linux?

Control-plane is indeed Linux only. Porting and supporting the various controllers to Windows is not a near term goal - although as Michelle mentions, it should probably all just work. I think it could be a higher priority if an initiative spins up to run the master nodes on Windows but I don't think there is such a need in the near term.

jsafrane · 2020-10-19T11:50:56Z

I implemented changes suggested in #452 (comment) in AWS EBS CSI driver: kubernetes-sigs/aws-ebs-csi-driver#595. Missing unit test and xfs support (only ext3/4 is implemented).

In the end, it's comparing size of a device (easy to get via blockdev --getsize64 <device>) and size of the filesystem (need to parse output of xfs_info and dump2fs). Maybe it would be even better to always call resize2fs / xfs_growfs after mount, it should be NOOP on a filesystem which already has maximum size.

I noticed that some drivers vendor kubernetes/kubernetes (AWS EBS, Cinder) and some copy its content (GCE PD) to get ResizeFs implementation . We should move it to a common place (kubernetes/mount?)

saad-ali · 2020-11-11T18:13:59Z

Discussed more in community meeting. See notes. Leaning towards having plugins implement this behavior but details TBD, will continue discussion at next meeting.

jsafrane · 2021-01-20T09:59:55Z

Updated this PR. From the meeting notes "if driver accepts CreateVolume from volume or snapshot that was smaller, and you respond successfully, it better be the the right size by the time NodePublish completes"

bswartz · 2021-02-11T00:33:34Z

spec.md

@@ -725,7 +725,13 @@ Plugins MAY create 3 types of volumes:

 - Empty volumes. When plugin supports `CREATE_DELETE_VOLUME` OPTIONAL capability.
 - From an existing snapshot. When plugin supports `CREATE_DELETE_VOLUME` and `CREATE_DELETE_SNAPSHOT` OPTIONAL capabilities.
+  The Plugin SHOULD create a volume that looks like exact copy of the original snapshotted volume at the time the snapshot was taken.


If feels to me like we could de-duplicate some of the language here and below, by including the requirements about resizing the filesystem in a later paragraph and referring to that twice in the list.

Also, why are we hedging with SHOULD? It feels like MUST would be appropriate here.

Replaced with MUST and moved to a separate paragraph below.

@bswartz PTAL

Jiawei0227 · 2021-02-12T20:08:49Z

I think this looks good.

spec.md

AndyXiangLi · 2021-02-15T22:49:14Z

spec.md

@@ -727,6 +727,9 @@ Plugins MAY create 3 types of volumes:
 - From an existing snapshot. When plugin supports `CREATE_DELETE_VOLUME` and `CREATE_DELETE_SNAPSHOT` OPTIONAL capabilities.
 - From an existing volume. When plugin supports cloning, and reports the OPTIONAL capabilities `CREATE_DELETE_VOLUME` and `CLONE_VOLUME`.

+If CO requests a volume to be created from existing snapshot or volume and the requested size of the volume is larger than the original snapshotted (or cloned volume), the Plugin can either refuse such a call with `OUT_OF_RANGE` error or MUST provide a volume that, when presented to a workload by `NodePublish` call, has both the requested (larger) size and contains data from the snapshot (or original volume).


what if the restored file system not supported for resize at this moment, should Plugin return the same error code?

already anwered by @jdef below, yes, OUT_OF_RANGE is IMO appropriate in this case too.

jdef · 2021-02-16T01:27:08Z

out-of-range can depend on the current state of the system. so if the current state doesn't allow for the snapshot due to capacity constraints, but later space might be freed up, then that seems in line w/ intended use for the error code. or .. was there another dimension to the question (that I'm not understanding)?

…

On Mon, Feb 15, 2021 at 5:49 PM Xiang Li ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In spec.md <#452 (comment)> : > @@ -727,6 +727,9 @@ Plugins MAY create 3 types of volumes: - From an existing snapshot. When plugin supports `CREATE_DELETE_VOLUME` and `CREATE_DELETE_SNAPSHOT` OPTIONAL capabilities. - From an existing volume. When plugin supports cloning, and reports the OPTIONAL capabilities `CREATE_DELETE_VOLUME` and `CLONE_VOLUME`. +If CO requests a volume to be created from existing snapshot or volume and the requested size of the volume is larger than the original snapshotted (or cloned volume), the Plugin can either refuse such a call with `OUT_OF_RANGE` error or MUST provide a volume that, when presented to a workload by `NodePublish` call, has both the requested (larger) size and contains data from the snapshot (or original volume). what if the restored file system not supported for resize at this moment, should Plugin return the same error code? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#452 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAR5KLFBWRZQDVIH5VLG6TDS7GQHXANCNFSM4RUKHMXQ> .

-- James DeFelice 585.241.9488 (voice) 650.649.6071 (fax)

bswartz

/lgtm

xing-yang · 2021-03-03T15:50:40Z

spec.md

@@ -1161,7 +1164,7 @@ The CO MUST implement the specified error recovery behavior when it encounters t
 | Source does not exist | 5 NOT_FOUND | Indicates that the specified source does not exist. | Caller MUST verify that the `volume_content_source` is correct, the source is accessible, and has not been deleted before retrying with exponential back off. |
 | Volume already exists but is incompatible | 6 ALREADY_EXISTS | Indicates that a volume corresponding to the specified volume `name` already exists but is incompatible with the specified `capacity_range`, `volume_capabilities`, `parameters`, `accessibility_requirements` or `volume_content_source`. | Caller MUST fix the arguments or use a different `name` before retrying. |
 | Unable to provision in `accessible_topology` | 8 RESOURCE_EXHAUSTED | Indicates that although the `accessible_topology` field is valid, a new volume can not be provisioned with the specified topology constraints. More human-readable information MAY be provided in the gRPC `status.message` field. | Caller MUST ensure that whatever is preventing volumes from being provisioned in the specified location (e.g. quota issues) is addressed before retrying with exponential backoff. |
-| Unsupported `capacity_range` | 11 OUT_OF_RANGE | Indicates that the capacity range is not allowed by the Plugin, for example when trying to create a volume smaller than the source snapshot. More human-readable information MAY be provided in the gRPC `status.message` field. | Caller MUST fix the capacity range before retrying. |
+| Unsupported `capacity_range` | 11 OUT_OF_RANGE | Indicates that the capacity range is not allowed by the Plugin, for example when trying to create a volume smaller than the source snapshot or the Plugin does not support creating volumes larger than the source snapshot. More human-readable information MAY be provided in the gRPC `status.message` field. | Caller MUST fix the capacity range before retrying. |


source snapshot -> source snapshot or source volume

When cloning a volume or restoring a snapshot, the resulting volume should be exact copy of the original volume. This includes any filesystem metadata. Therefore, when the new volume is larger than the original one, the new volume may need to resize the filesystem (ie call resize2fs, xfs_growfs, ...) to make the bigger capacity available to workloads.

xing-yang · 2021-03-03T20:10:56Z

spec.md

@@ -1161,7 +1164,7 @@ The CO MUST implement the specified error recovery behavior when it encounters t
 | Source does not exist | 5 NOT_FOUND | Indicates that the specified source does not exist. | Caller MUST verify that the `volume_content_source` is correct, the source is accessible, and has not been deleted before retrying with exponential back off. |
 | Volume already exists but is incompatible | 6 ALREADY_EXISTS | Indicates that a volume corresponding to the specified volume `name` already exists but is incompatible with the specified `capacity_range`, `volume_capabilities`, `parameters`, `accessibility_requirements` or `volume_content_source`. | Caller MUST fix the arguments or use a different `name` before retrying. |
 | Unable to provision in `accessible_topology` | 8 RESOURCE_EXHAUSTED | Indicates that although the `accessible_topology` field is valid, a new volume can not be provisioned with the specified topology constraints. More human-readable information MAY be provided in the gRPC `status.message` field. | Caller MUST ensure that whatever is preventing volumes from being provisioned in the specified location (e.g. quota issues) is addressed before retrying with exponential backoff. |
-| Unsupported `capacity_range` | 11 OUT_OF_RANGE | Indicates that the capacity range is not allowed by the Plugin, for example when trying to create a volume smaller than the source snapshot. More human-readable information MAY be provided in the gRPC `status.message` field. | Caller MUST fix the capacity range before retrying. |
+| Unsupported `capacity_range` | 11 OUT_OF_RANGE | Indicates that the capacity range is not allowed by the Plugin, for example when trying to create a volume smaller than the source snapshot or the Plugin does not support creating volumes larger than the source snapshot or source volume. More human-readable information MAY be provided in the gRPC `status.message` field. | Caller MUST fix the capacity range before retrying. |


nit: there's another instance of this: "smaller than the source snapshot"

xing-yang · 2021-03-03T20:11:23Z

Looks good to me. Just a nit.

saad-ali

/lgtm
/approve

jsafrane mentioned this pull request Sep 21, 2020

Filesystem resize is required after snapshot restore / volume clone kubernetes/kubernetes#94929

Closed

6 tasks

jsafrane force-pushed the snapshot-size branch from a8e3db4 to 8ed11ad Compare September 21, 2020 09:48

msau42 reviewed Oct 7, 2020

View reviewed changes

gnufied reviewed Oct 7, 2020

View reviewed changes

Jiawei0227 reviewed Oct 9, 2020

View reviewed changes

Jiawei0227 mentioned this pull request Oct 9, 2020

Restoring from a snapshot to a larger size kubernetes-csi/external-provisioner#485

Closed

4 tasks

jsafrane mentioned this pull request Oct 19, 2020

WIP: [do not merge] Resize ext4 filesystem on NodeStage kubernetes-sigs/aws-ebs-csi-driver#595

Closed

jsafrane force-pushed the snapshot-size branch from 8ed11ad to 73d7751 Compare January 20, 2021 09:58

AndyXiangLi mentioned this pull request Jan 21, 2021

Resizing disk partition in EBS from smaller snapshot size kubernetes-sigs/aws-ebs-csi-driver#569

Closed

bswartz requested changes Feb 11, 2021

View reviewed changes

jsafrane changed the title ~~Clarify content of cloned / restored volumes~~ Clarify size of cloned / restored volumes Feb 12, 2021

jsafrane mentioned this pull request Feb 12, 2021

Add test for filesystem expansion after snapshot restore / clone kubernetes-csi/csi-test#325

Closed

jdef reviewed Feb 13, 2021

View reviewed changes

spec.md Outdated Show resolved Hide resolved

AndyXiangLi reviewed Feb 15, 2021

View reviewed changes

bswartz approved these changes Feb 17, 2021

View reviewed changes

xing-yang reviewed Mar 3, 2021

View reviewed changes

jsafrane added 2 commits March 3, 2021 19:23

Move volume resize clarification to its own paragraph

579c283

jsafrane force-pushed the snapshot-size branch from 8b88d4e to 579c283 Compare March 3, 2021 18:23

xing-yang reviewed Mar 3, 2021

View reviewed changes

saad-ali approved these changes Mar 3, 2021

View reviewed changes

saad-ali merged commit 3e2f811 into container-storage-interface:master Mar 3, 2021

alibo mentioned this pull request May 26, 2021

[cinder-csi-plugin] filesystem of a larger volume created from a snapshot/volume is not expanded kubernetes/cloud-provider-openstack#1539

Closed

Jiawei0227 mentioned this pull request Jun 1, 2021

Restoring from a snapshot to a larger size kubernetes-sigs/gcp-compute-persistent-disk-csi-driver#784

Closed

alibo mentioned this pull request Jun 4, 2021

[cinder-csi-plugin] Resize filesystem of a larger volume created from a snapshot/volume kubernetes/cloud-provider-openstack#1563

Merged

Clarify size of cloned / restored volumes #452

Clarify size of cloned / restored volumes #452

Conversation

jsafrane commented Sep 21, 2020 • edited Loading

Choose a reason for hiding this comment

msau42 commented Oct 7, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

humblec commented Oct 7, 2020 • edited Loading

jsafrane commented Oct 8, 2020

bswartz commented Oct 8, 2020

msau42 commented Oct 8, 2020

bswartz commented Oct 8, 2020

Jiawei0227 commented Oct 9, 2020

Choose a reason for hiding this comment

Jiawei0227 commented Oct 9, 2020

humblec commented Oct 9, 2020 • edited Loading

bswartz commented Oct 9, 2020

humblec commented Oct 9, 2020 • edited Loading

bswartz commented Oct 9, 2020

humblec commented Oct 9, 2020

bswartz commented Oct 9, 2020

saad-ali commented Oct 14, 2020

ddebroy commented Oct 16, 2020 • edited Loading

jsafrane commented Oct 19, 2020

saad-ali commented Nov 11, 2020

jsafrane commented Jan 20, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Jiawei0227 commented Feb 12, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jdef commented Feb 16, 2021 via email

bswartz left a comment

Choose a reason for hiding this comment

xing-yang Mar 3, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xing-yang commented Mar 3, 2021

saad-ali left a comment

Choose a reason for hiding this comment

jsafrane commented Sep 21, 2020 •

edited

Loading

humblec commented Oct 7, 2020 •

edited

Loading

humblec commented Oct 9, 2020 •

edited

Loading

humblec commented Oct 9, 2020 •

edited

Loading

ddebroy commented Oct 16, 2020 •

edited

Loading

xing-yang Mar 3, 2021 •

edited

Loading