Re: API Review: Resize (persistent) volume support

>From the perspective of resource allocation, GROW takes two resources and merge them into one, while SHRINK takes one resource and split it into two. So, having two separated calls could make it explicit to the framework about what the resources being consumed are. Jie also mentioned in the

Re: API Review: Resize (persistent) volume support

> On Mar 16, 2018, at 11:12 AM, Zhitao Li wrote: > > Hi everyone, > > Chun, Greg, Gastón and I are working on supporting resizing of persistent > volume[1]. See [2] for the design doc in length. > > The proposed new offer operation and corresponding operator API are in

Re: API Review: Resize (persistent) volume support

> 3) target volume in `Resource` format: this may not be possible for any CSI volume because the implementation could change certain metadata, so we did not take this approach. Can you expand on this? 3 looks like the best approach since it's idempotent and doesn't require that clients compute

Re: API Review: Resize (persistent) volume support

> > That said, I'm not sure if this is a valid concern since we don't have such > CSI functions yet. So input from folks would be very welcome! FYI, I just opened an issue in the CSI community: https://github.com/container-storage-interface/spec/issues/212 - Jie On Fri, Mar 16, 2018 at 11:40

Re: API Review: Resize (persistent) volume support

Thanks Zhitao for the summary. My thoughts are: For `SHRINK_VOLUME`, I feel option 2 is appropriate, as it gives the component that actually applies the operation to decide what the resulting free disk space would become. Option 3 is also acceptable. For `GROW_VOLUME`, I actually prefer option 1

API Review: Resize (persistent) volume support

Hi everyone, Chun, Greg, Gastón and I are working on supporting resizing of persistent volume[1]. See [2] for the design doc in length. The proposed new offer operation and corresponding operator API are in following two patches: https://reviews.apache.org/r/66049/