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