> On March 15, 2018, 12:10 p.m., Chun-Hung Hsiao wrote:
> > include/mesos/mesos.proto
> > Lines 1920-1921 (patched)
> > <https://reviews.apache.org/r/66049/diff/1/?file=1974927#file1974927line1920>
> >
> >     As we discussed, let's do `s/PERSISTENT_//`, as well as 
> > `s/Persistent//` and `s/persistent_//` below.

Will do.


> On March 15, 2018, 12:10 p.m., Chun-Hung Hsiao wrote:
> > include/mesos/mesos.proto
> > Lines 1975 (patched)
> > <https://reviews.apache.org/r/66049/diff/1/?file=1974927#file1974927line1975>
> >
> >     I'm thinking that, instead of asking the framework to craft the freed 
> > disk, we could leave it to the agent/RP so they have the freedom to 
> > transform the freed disk to an appropriate type of disk resource (although 
> > for now it will be the same as the original volume except in size and 
> > persistence). So how about having a `Scalar target` instead, and we can 
> > implement it through `Resources::shrink()`?

I suggest we do not look at how `Resources` class implements various helpers 
when designing public API, but rather think about how to make the API easy, 
straightforward and consistent for the users (here it would be framework 
authors).

Initially, I chose this format because it is more symetrical to 
`RESERVE`/`UNRESERVE` and could be chained together in one operation. However, 
after the decision to make new API non-chainable (and non-speculative), that 
argument seems weaker now.

If we go with `target` format, I'd rather make the target as a full `Resource` 
object and the API will look like:

```
message SHRINK_VOLUME {
  required Resource original = 1; // original volume resource
  required Resource target = 2;  // target volume resource
}
```

Framework author can just make a copy of `original` and change the scalar 
quantity.

Eventually, we might be able to mark `original` optional or drop it in the API.

What do you think?


- Zhitao


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/66049/#review199283
-----------------------------------------------------------


On March 13, 2018, 3:48 p.m., Zhitao Li wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66049/
> -----------------------------------------------------------
> 
> (Updated March 13, 2018, 3:48 p.m.)
> 
> 
> Review request for mesos, Chun-Hung Hsiao and Gaston Kleiman.
> 
> 
> Bugs: MESOS-4965
>     https://issues.apache.org/jira/browse/MESOS-4965
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Added offer operation to grow and shrink persistent volumes.
> 
> 
> Diffs
> -----
> 
>   include/mesos/mesos.proto e6ba3746456c9241ceaefac39200f68562dd5cb9 
>   include/mesos/v1/mesos.proto 30d4d35e865db2af1ba85b12e2b5b0e499ef8de8 
> 
> 
> Diff: https://reviews.apache.org/r/66049/diff/1/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Zhitao Li
> 
>

Reply via email to