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 more, and I think it can
handle more cases, including CSI volumes. To be more concrete, here is a
prototype I would suggest:
```
message GrowVolume {
Resource volume = 1;
Resource addition = 2;
}
```
Potentially, we may let a framework to grow `volume` with either an
existing `PATH` volume or a `RAW` storage pool. Neither option 2 nor 3 can
provide such functionality, because it cannot specify where the extra space
comes from.
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!
On Mar 16, 2018 11:12 AM, "Zhitao Li" <zhitaoli...@gmail.com> 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
following two patches:
https://reviews.apache.org/r/66049/
https://reviews.apache.org/r/66052
Our intention is to eventually support resizing of not only persistent
volumes, but also CSI volumes[3] introduced after Mesos 1.5 in the same set
of API, so we are declaring the API as experimental in its first release
version.
We also want to make sure the API is reasonable to use to framework authors
and operators.
Considering the above, both APIs need to include the original volume as
resource. Some alternatives on extra fields:
1) size difference in Resource format: this may not be applicable in CSI
volume;
2) size difference in Scalar value: this can be applicable in both CSI and
persistent volume case, since there is always a quantitive difference. We
can add extra CSI only fields once the spec is defined;
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.
Therefore, we are taking option 2) in current patches.
Please let me know what you think. Thanks.
[1] https://issues.apache.org/jira/browse/MESOS-4965
[2] https://docs.google.com/document/d/1Z16okNG8mlf2eA6NyW_PUmBfNFs_
6EOaPzPtwYNVQUQ/edit#
[3] https://github.com/apache/mesos/blob/master/docs/csi.md
--
Cheers,
Zhitao Li
