----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18403/#review35504 -----------------------------------------------------------
I think we need to work on this a little. It seems that making the launching state explicit and then cleaning up behavior (killTask) when in this state is necessary. src/slave/containerizer/containerizer.hpp <https://reviews.apache.org/r/18403/#comment66140> Should this be in mesos_containerizer? I was thinking if the task didn't have task.executor() then the determination of the executor would be containerizer implementation dependent. src/slave/containerizer/mesos_containerizer.cpp <https://reviews.apache.org/r/18403/#comment66141> Why is this a Future<>? Can you not just pass the ExecutorInfo to exec() and have it return? src/slave/containerizer/mesos_containerizer.cpp <https://reviews.apache.org/r/18403/#comment66143> const ExecutorInfo& ? src/slave/slave.cpp <https://reviews.apache.org/r/18403/#comment66056> Could you swap this logic? i.e., if (contains) { launch = framework->launchingExecutors[]; } else { launch = framework->launch(); } src/slave/slave.cpp <https://reviews.apache.org/r/18403/#comment66057> What happens to Executor* if the future is ready? src/slave/slave.cpp <https://reviews.apache.org/r/18403/#comment66058> s/rebust/robust/ src/slave/slave.cpp <https://reviews.apache.org/r/18403/#comment66060> Previously executor == NULL was unexpected but now it seems weird to have NULL as a 'normal' value. Can we capture this is a better way? src/slave/slave.cpp <https://reviews.apache.org/r/18403/#comment66062> We shouldn't be returning TASK_LOST and claiming we cannot find the executor here if the executor is actually launching. If we haven't sent a launching executor the task then we should prevent that and act appropriately. src/slave/slave.cpp <https://reviews.apache.org/r/18403/#comment66063> What about introducing a new executor state - Executor::LAUNCHING? src/slave/slave.cpp <https://reviews.apache.org/r/18403/#comment66065> s/We might be in a situation where the executor is launching but not yet ready. The second half is scheduled until executor is ready, or called directly if executor is running./If the executor is still launching we'll defer registering until it is ready./? src/slave/slave.cpp <https://reviews.apache.org/r/18403/#comment66078> ditto - what happens to Executor* if the future is ready? src/slave/slave.cpp <https://reviews.apache.org/r/18403/#comment66134> ditto - Executor* src/slave/slave.cpp <https://reviews.apache.org/r/18403/#comment66135> okay :-p src/slave/slave.cpp <https://reviews.apache.org/r/18403/#comment66136> perhaps not in this change, but this should done when the Future<ExecutorInfo> is ready rather than now. src/slave/slave.cpp <https://reviews.apache.org/r/18403/#comment66137> ditto - should start timeout when the launch is ready. src/slave/slave.cpp <https://reviews.apache.org/r/18403/#comment66138> The determination of executor resources should be done by each containerizer implementation if they choose an executor. - Ian Downes On Feb. 26, 2014, 12:04 a.m., Niklas Nielsen wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/18403/ > ----------------------------------------------------------- > > (Updated Feb. 26, 2014, 12:04 a.m.) > > > Review request for mesos, Adam B, Benjamin Hindman, Ben Mahler, Ian Downes, > Till Toenshoff, and Vinod Kone. > > > Bugs: MESOS-922 > https://issues.apache.org/jira/browse/MESOS-922 > > > Repository: mesos-git > > > Description > ------- > > This patch delegates the choice of executor to the containerizer by removing > executorInfo dependencies up until Containerizer::launch(). > Containerizer::launch() now returns a future to the executor info that is > being run and the slave creates the corresponding executor structure when > launch completes. > This means message handling from the running executor to the slave in the > interim where the executor structure has not created, need to be enqueued > until executor is ready. So far, registerExecutor() and reregisterExecutor() > has been split into two continuations to deal with this issue. > > > Diffs > ----- > > src/slave/containerizer/containerizer.hpp d9ae326 > src/slave/containerizer/containerizer.cpp d0a1023 > src/slave/containerizer/mesos_containerizer.hpp ee1fd30 > src/slave/containerizer/mesos_containerizer.cpp 6d990cb > src/slave/slave.hpp 01b80df > src/slave/slave.cpp 4f5349b > src/tests/containerizer.hpp 5686398 > src/tests/containerizer.cpp bfb9341 > > Diff: https://reviews.apache.org/r/18403/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Niklas Nielsen > >
