> 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. > > Michael Park wrote: > 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.
Another thought, a framework with role=R gets offered resources with (role=R, reservation_type=STATIC). Such framework shouldn't be able to make a subreservation with role=S since role S doesn't belong to it. This means multi-role frameworks need to be in place before we can make subreservations work. - 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 > >
