mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph Wu" <jos...@mesosphere.io>
Subject Re: Review Request 36321: Maintenance primitives: Add Unavailability and InverseOffer protobufs.
Date Mon, 31 Aug 2015 21:09:58 GMT


> On Aug. 31, 2015, 1:06 p.m., Ben Mahler wrote:
> > include/mesos/mesos.proto, lines 140-154
> > <https://reviews.apache.org/r/36321/diff/15/?file=1057977#file1057977line140>
> >
> >     Should this have been:
> >     
> >     ```
> >     message Interval {
> >       required TimeInfo start;
> >       optional DurationInfo duration;
> >     }
> >     
> >     message Unavailability {
> >       required Interval interval;
> >       
> >       // Add additional fields related to unavailability.
> >     }
> >     ```
> >     
> >     Curious if we're going to have to duplicate Interval elsewhere.

It was difficult to decide which combination of required/optional was appropriate for a generic
`Interval` message.

Would it be a strict definition (required start and duration), the existing one (required
start, optional duration, no duration == infinite), or a lax one (optional start and duration)?
 Each definition has slightly different connotations and I didn't want to lock `Interval`
into any one of them, just because we use it for this feature.


> On Aug. 31, 2015, 1:06 p.m., Ben Mahler wrote:
> > include/mesos/mesos.proto, lines 949-963
> > <https://reviews.apache.org/r/36321/diff/15/?file=1057977#file1057977line949>
> >
> >     Does this need to be required? For example, if we'd like to do ASAP de-allocation
in the future, what would that look like?
> >     
> >     Would we be omitting an unavailability? Or would we be setting the start time
to 'now'? Also, would we need additional information in the inverse offer (e.g. hard vs soft?).
Food for thought.

Note: In the MVP, the "emergency" maintenance workflow is still to go from UP -> DRAINING
-> DOWN (Normal -> Draining -> Deactivated, if we use the design doc's terminology),
with an Unavailability set to "now".  

The unavailability is required because:
* We want as much info as possible.  And it's not painful to supply.
* The master uses (the presence of) Unavailability for some logic.  If we didn't have it required,
we might end up with an awkward `Option<Option<Unavailability>>`.
* Presumably, additional information (hard/soft, etc) would go in the Unavailability and thereby
end up in the Offer and InverseOffer.


- Joseph


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


On Aug. 28, 2015, 10:11 a.m., Joseph Wu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/36321/
> -----------------------------------------------------------
> 
> (Updated Aug. 28, 2015, 10:11 a.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.
> 
> Also copied to v1 API.
> 
> No integration with other components (that part is tracked in separate JIRAs, see MESOS-1474).
> 
> 
> Diffs
> -----
> 
>   include/mesos/mesos.proto c40a09b2bb2b9444e9b90e86eefe6fc8f98b613d 
>   include/mesos/v1/mesos.proto ee15b9ae70aeb8cf803ea7e4b06f4443bd7bc9e2 
> 
> 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