> On Dec. 24, 2014, 9:20 a.m., Adam B wrote:
> > src/slave/slave.cpp, lines 2669-2676
> > <https://reviews.apache.org/r/28063/diff/5/?file=799499#file799499line2669>
> >
> > There should only be one CommandInfo to modify, so you can use a CHECK
> > or make this an if/else
>
> Alexander Rukletsov wrote:
> There is only one place where we enforce this constraint. I do not want
> to introduce this check in another piece of code, since the behaviour may
> change. Current grace period update code will handle both situations
> correctly.
>
> Adam B wrote:
> Fair enough. Dropping.
> But maybe we should have a protobuf utility function that takes a
> TaskInfo and returns a reference to the valid CommandInfo?
That sounds similar to my proposal to move the function to
`common/protobuf_utils.{hpp|cpp}`. I think we agreed to keep it local instead.
Do I understand it correctly?
- Alexander
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28063/#review66019
-----------------------------------------------------------
On Dec. 23, 2014, 3:25 p.m., Alexander Rukletsov wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/28063/
> -----------------------------------------------------------
>
> (Updated Dec. 23, 2014, 3:25 p.m.)
>
>
> Review request for mesos, Ben Mahler, Niklas Nielsen, and Till Toenshoff.
>
>
> Bugs: MESOS-1571
> https://issues.apache.org/jira/browse/MESOS-1571
>
>
> Repository: mesos-git
>
>
> Description
> -------
>
> CommandExecutor grace_period field is designed to be used by slave to
> propagate the value of the grace period flag further to containerizers and
> executors.
>
>
> Diffs
> -----
>
> include/mesos/mesos.proto 0085aba
> src/slave/slave.hpp 70bd8c1
> src/slave/slave.cpp ed63ded
>
> Diff: https://reviews.apache.org/r/28063/diff/
>
>
> Testing
> -------
>
> make check (Mac OS 10.9.4, Ubuntu 14.04)
>
>
> Thanks,
>
> Alexander Rukletsov
>
>
