From dev-return-50239-archive-asf-public=cust-asf.ponee.io@mesos.apache.org Mon Mar 19 19:33:21 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 8EE1F180647 for ; Mon, 19 Mar 2018 19:33:20 +0100 (CET) Received: (qmail 37513 invoked by uid 500); 19 Mar 2018 18:33:19 -0000 Mailing-List: contact dev-help@mesos.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@mesos.apache.org Delivered-To: mailing list dev@mesos.apache.org Received: (qmail 37498 invoked by uid 99); 19 Mar 2018 18:33:19 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Mar 2018 18:33:19 +0000 Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 35DFC1C08 for ; Mon, 19 Mar 2018 18:33:17 +0000 (UTC) Received: by mail-oi0-f50.google.com with SMTP id x12so15153333oie.13 for ; Mon, 19 Mar 2018 11:33:17 -0700 (PDT) X-Gm-Message-State: AElRT7HmvNzeXoir++tBMntgGiPmTkgyPN5hIoozOLvwWE+SUSRbF3Dd CfHGWxFxwOGaWQLLZa26mM3fxw7Ks+3WEJTqD0lmyA== X-Google-Smtp-Source: AG47ELvfRWZeTKDHdCgyPCfZwobkvXMoPQ6DIqmP5jF93btojBNIkyjHR+1P61XLPnUkZB7srgAnXfIxUk2mPqvNQ5M= X-Received: by 10.202.189.5 with SMTP id n5mr7996167oif.260.1521484396948; Mon, 19 Mar 2018 11:33:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:4481:0:0:0:0:0 with HTTP; Mon, 19 Mar 2018 11:33:16 -0700 (PDT) In-Reply-To: <90D72AD4-9DD3-411C-9210-7B950452DF8F@apache.org> References: <90D72AD4-9DD3-411C-9210-7B950452DF8F@apache.org> From: Chun-Hung Hsiao Date: Mon, 19 Mar 2018 11:33:16 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: API Review: Resize (persistent) volume support To: dev Cc: jpeach@apache.org Content-Type: multipart/alternative; boundary="001a113d6cd40319a00567c83161" --001a113d6cd40319a00567c83161 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 comment https://reviews.apache.org/r/66049/#comment279663 that specifying two resources instead of one in GROW would make the validation clear. I don't think allowing the operation to be applied more than once is a good idea, and thus I'm thinking about the following validation: 1. The master checks that its resources contain the consumed resource(s). 2. The master forwards the operation to the agent. 3. The agent checks that its resources contain the consumed resource(s). 4. The agent applies the operation to update its resources, and returns a resource conversion. 5. The master receives the resource conversion and applies it to update its resources. On Sun, Mar 18, 2018 at 8:16 PM, James Peach wrote: > > > > On Mar 16, 2018, at 11:12 AM, Zhitao Li wrote: > > > > Hi everyone, > > > > Chun, Greg, Gast=C3=B3n and I are working on supporting resizing of per= sistent > > 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 releas= e > > version. > > > > We also want to make sure the API is reasonable to use to framework > authors > > and operators. > > Why do you have separate GROW/SHRINK operations? Could a RESIZE operation > with a target size work? > > In all of these cases, is it possible for the operation to be applied mor= e > than once? Clearly, replaying a SHRINK would be bad. Applying RESIZE > operations out of order would also be bad, but not in the same way. > > What is the response to this request? > > > 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 CS= I > > 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 > > --001a113d6cd40319a00567c83161--