> On Dec. 19, 2014, 12:23 p.m., Ben Mahler wrote: > > 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 wrote: > Also, is this a WIP? If you plan on getting this committed mind changing > the title?
If we do end up introducing hierarchical roles, I see no reason why they would only be two levels deep, since one could dynamically reserve from "*" to "marathon" to "marathon/ads" to "marathon/ads/EU" etc., so a single `static_role` field may not suffice. We may need a repeated list/stack, or just keep track of all that information in the master and don't bother exposing it to the framework. The original role is just what was necessary for this framework to get the offer. Once the framework decides to change the role, let the master track any necessary history. I think it's fine for us to keep the single `role` field to represent the current/desired role, and the ReservationType will indicate a) (when sent by the master) what type of reservation this resource currently belongs to, and hence what actions may be taken on it, and b) (when sent by the framework) the desired reservation type, with the action specified by what kind of message (acquire/release/launch) this Resource is a part of. That said, I am all the more convinced that we should name the enum ReservationType to prepare for a day when we need a fuller Reservation message. - Adam ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28697/#review65670 ----------------------------------------------------------- On Dec. 16, 2014, 4:56 p.m., Michael Park wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/28697/ > ----------------------------------------------------------- > > (Updated Dec. 16, 2014, 4:56 p.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 > >
