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 Tue, 25 Aug 2015 22:01:58 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.
> 
> Alexander Rukletsov wrote:
>     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?
> 
> Joseph Wu wrote:
>     Updated the comments.  Let me know what you think.

I think the comment is great: brief and clear. One thing I'm not sure about is whether it
should be placed in the `InverseOffer` message, since there is a similar field in `ResourceOffer`.
Maybe it makes sense to pull it up to the `Unavailability` definition and leave a reference
to it in both places, where `unavailability` is used.


- Alexander


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36321/#review96073
-----------------------------------------------------------


On Aug. 25, 2015, 3:24 p.m., Joseph Wu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/36321/
> -----------------------------------------------------------
> 
> (Updated Aug. 25, 2015, 3:24 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Ben Mahler, Artem Harutyunyan, Joris Van
Remoortere, and Vinod Kone.
> 
> 
> 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 33e1b28f1ccbe227657a14395f81df20e0a9e193 
>   include/mesos/v1/mesos.proto 382b978dca769757171c5558b7f259870592c321 
> 
> 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