mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chun-Hung Hsiao <>
Subject Re: API Review: Resize (persistent) volume support
Date Fri, 16 Mar 2018 18:40:59 GMT
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" <> 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:

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

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
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.



Zhitao Li

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message