> On Dec. 19, 2014, 8: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? > > Adam B wrote: > 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.
Removed WIP. Changed Reservation to ReservationType. - Michael ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28697/#review65670 ----------------------------------------------------------- On Dec. 30, 2014, 2:42 a.m., Michael Park wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/28697/ > ----------------------------------------------------------- > > (Updated Dec. 30, 2014, 2:42 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 > >
