> 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. > > Michael Park wrote: > Removed WIP. Changed Reservation to ReservationType.
As far as frameworks dynamically reserving resources from a non-"*" role, we do want frameworks to be offered statically reserved resources that *do not belong* to them in order to get better resource utilization. However, we do not want frameworks to be offered resources with `(role=R, reservation_type=STATIC)` where `R` does not belong to the framework due to security issues (a malicious framework could only use/reserve one statically reserved role's resources). What would be better is to send statically reserved resources as revocable resources to the framework where revocable resources are denoted by `role="_"` or maybe a combination of `role="*" + revocable=true`. This makes sense because if the statically reserved resources are needed they need to be revoked. Under this design, the master would keep track of which role the revocable resources came from and the framework doesn't/shouldn't know where they came from. For frameworks dynamically reserving resources from a non-"*" role that does belong to them, we could revisit it if it seems like a useful feature. I think Adam is right in that we can keep the record of the chain of reservations (hopefully keep it at 2 for simplicity sake...) in the master and not expose it to the framework. - 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 > >
