mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Rukletsov" <ruklet...@gmail.com>
Subject Re: Review Request 36321: Maintenance primitives: Add Unavailability and InverseOffer protobufs.
Date Sun, 23 Aug 2015 17:41:40 GMT


> 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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message