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

Reply via email to