> On Feb. 18, 2014, 2:07 p.m., Vinod Kone wrote: > > src/tests/mesos.hpp, lines 239-252 > > <https://reviews.apache.org/r/16724/diff/6/?file=492073#file492073line239> > > > > Why not augment createTask() above? > > > > Also, it seems a bit weird to use DEFAULT_EXECUTOR_INFO as > > Task.ExecutorInfo. > > Adam B wrote: > If I use createTask() as is, I get "Failed to launch executor <foo> of > framework <bar> because it is unknown to the isolator". > If I add "task.mutable_executor()->CopyFrom(DEFAULT_EXECUTOR_INFO);" > after calling createTask, I get TASK_LOST ("TaskInfo must have either an > 'executor' or a 'command'"). > From the declaration of TaskInfo in mesos.proto, "Either ExecutorInfo or > CommandInfo should be set" (not both), so I think it makes sense to have > createTaskWithCommand() and createTaskWithExecutor(). Since I'm just using > the DEFAULT_EXECUTOR_INFO, I have renamed my function > createTaskWithDefaultExecutor(), but we could generalize this to take in an > (optional) ExecutorInfo.
This code was also moved into fault_tolerance_tests.cpp. If it becomes valuable to other tests, then we can revisit the design of createTask() to include an ExecutorInfo or CommandInfo. - Adam ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/16724/#review34767 ----------------------------------------------------------- On Feb. 18, 2014, 6:07 p.m., Adam B wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/16724/ > ----------------------------------------------------------- > > (Updated Feb. 18, 2014, 6:07 p.m.) > > > Review request for mesos, Benjamin Hindman, Ben Mahler, Niklas Nielsen, and > Vinod Kone. > > > Bugs: MESOS-767 > https://issues.apache.org/jira/browse/MESOS-767 > > > Repository: mesos-git > > > Description > ------- > > Added completed frameworks/tasks to slave re-registration. > Fixes MESOS-767. > > Additional issues discovered during investigation: > - MESOS-905: Remove Framework.id in favor of FrameworkInfo.id > - MESOS-906: Last task in Completed Framework never graduates from > terminatedTasks to completedTasks. > - Completed frameworks/executors/tasks are stored in circular buffers, > and these may overflow in different orders on different slaves. > BenH proposes an archive to replace these circular buffers. > > > Diffs > ----- > > include/mesos/scheduler.hpp 2e4707e > src/master/master.hpp 7649737 > src/master/master.cpp 77872ec > src/messages/messages.proto 922a8c4 > src/slave/slave.cpp 2d21e16 > src/tests/fault_tolerance_tests.cpp 60e06cc > src/tests/mesos.hpp d7bdaee > > Diff: https://reviews.apache.org/r/16724/diff/ > > > Testing > ------- > > make check; manually failed-over a master, watched the slave reregister its > completed frameworks, web UI shows completed tasks and stdout/stderr. > Added a new unit/integration test to verify the expected behavior. > > > Thanks, > > Adam B > >
