> On Aug. 21, 2015, 6:35 p.m., Alexander Rukletsov wrote: > > include/mesos/mesos.proto, lines 917-920 > > <https://reviews.apache.org/r/36321/diff/9/?file=1038857#file1038857line917> > > > > I think the name `Unavailability` is too specific to maintenance, how > > about something more generic, like `Period`? > > > > I'm thinking about a use case, when a custom allocator uses > > InverseOffers to ask a framework to release resources. In this case, we > > need a "timeout", which is naturally expressed by `unavailability.start`. > > Given we don't need duration in this case, the name can be misleading for > > users. > > Joseph Wu wrote: > A while ago, I posted a few diffs where this object was called `Interval` > (https://reviews.apache.org/r/36321/diff/7/). The reason why it was changed > back to `Unavailability` is that we may wish to extend this object to be more > specific, in the future. > > (We've already removed all the maintenance-specific language in the > comments for `Unavailability` and `InverseOffer`.) > > Taking your example, the custom allocator asks for resources back. It > says that these will be unavailable by the `start` time. Duration is > optional; in the case of maintenance, when `duration` is omitted, it means > the duration is forever or unknown. > I think the term also works for non-maintenance uses.
For me "unavailability" implies the resources will be given back once the period (interval) is over. Unless resource are reserved, this is not the case, since allocator has no obligations to offer resources to prior users once unavailability period is over. In an offline conversation, Joris pointed out, that unavailability events are mostly interesting for stateful frameworks, which most probably will have reservations for resources. If you plan to leave current term, could you please reflect in the comment what unavailability guarantees and what it does not? - Alexander ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/36321/#review96073 ----------------------------------------------------------- On Aug. 12, 2015, 10:07 p.m., Joseph Wu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/36321/ > ----------------------------------------------------------- > > (Updated Aug. 12, 2015, 10:07 p.m.) > > > Review request for mesos, Benjamin Hindman, Ben Mahler, Artem Harutyunyan, > and Joris Van Remoortere. > > > Bugs: MESOS-2061 and MESOS-2066 > https://issues.apache.org/jira/browse/MESOS-2061 > https://issues.apache.org/jira/browse/MESOS-2066 > > > Repository: mesos > > > Description > ------- > > MESOS-2061: Add Unavailability and InverseOffer protobufs declarations. > MESOS-2066: Add the Unavailability field to Offers. > > No integration with other components (that part is tracked in separate JIRAs, > see MESOS-1474). > > > Diffs > ----- > > include/mesos/mesos.proto 8a423a56a341e380434e7df91868f1813024840c > > Diff: https://reviews.apache.org/r/36321/diff/ > > > Testing > ------- > > `make check` > > > Thanks, > > Joseph Wu > >
