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

Ship it!


This looks good Michael, one thing that I think is important to highlight about 
this approach is that we no longer "know" the static reservation for a 
dynamically reserved resource.

This is ok for now because a dynamically reserved resource *always* implies 
that it's static role is `"*"` (unreserved). But it might be work thinking, 
possibly leaving a NOTE or TODO, about what we would do if we introduced the 
ability for a framework to dynamically reserved resources from a non-`"*"` 
role. For example, this could happen if we introduced hierarchical roles (e.g. 
Marathon reserves `"marathon"` resources under the role `"marathon-ads"`). 
Would we introduce a `static_role` or a richer `Reservation` message as Adam 
alluded to? Just some food for thought here.

Will defer to Adam on this one, also would like to see some documentation 
around dynamic reservations at the top level of the `Resource` proto message.

Thanks!

- Ben Mahler


On Dec. 17, 2014, 12:56 a.m., Michael Park wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/28697/
> -----------------------------------------------------------
> 
> (Updated Dec. 17, 2014, 12:56 a.m.)
> 
> 
> Review request for mesos, Adam B, Benjamin Hindman, Ben Mahler, Jie Yu, and 
> Vinod Kone.
> 
> 
> Bugs: MESOS-2137
>     https://issues.apache.org/jira/browse/MESOS-2137
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Adding new protobuf messages necessary to support dynamic reservations.
> 
> 
> Diffs
> -----
> 
>   include/mesos/mesos.proto 540071db64961466eb75c779b3ea6863f4594437 
> 
> Diff: https://reviews.apache.org/r/28697/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Michael Park
> 
>

Reply via email to