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

Reply via email to