> On April 2, 2014, 5:47 p.m., Vinod Kone wrote: > >
Thanks for the thorough review Vinod! The new patch captures some of the trivial changes but some of the bigger issues are still outstanding. I have raised questions inline. Also, I think it makes sense to break out the Executor::resources option change in a dependent patch. > On April 2, 2014, 5:47 p.m., Vinod Kone wrote: > > src/slave/slave.cpp, line 3736 > > <https://reviews.apache.org/r/19795/diff/3/?file=544927#file544927line3736> > > > > CHECK_NOTNULL(slave) Inlined in Slave::executorLaunched() - so no need for this check. > On April 2, 2014, 5:47 p.m., Vinod Kone wrote: > > src/slave/slave.cpp, line 3562 > > <https://reviews.apache.org/r/19795/diff/3/?file=544927#file544927line3562> > > > > hmm. we should make this optional instead of setting it to empty. Good idea - I will probably put this change in its own review? > On April 2, 2014, 5:47 p.m., Vinod Kone wrote: > > src/slave/slave.cpp, line 3474 > > <https://reviews.apache.org/r/19795/diff/3/?file=544927#file544927line3474> > > > > All you are doing here during recovery is to setup the resources. Just > > do it directly instead of calling launched(). Good catch - done! :) > On April 2, 2014, 5:47 p.m., Vinod Kone wrote: > > src/slave/slave.cpp, lines 970-971 > > <https://reviews.apache.org/r/19795/diff/3/?file=544927#file544927line970> > > > > Pull this inside the if below. Good point - done :) > On April 2, 2014, 5:47 p.m., Vinod Kone wrote: > > src/slave/slave.cpp, line 726 > > <https://reviews.apache.org/r/19795/diff/3/?file=544927#file544927line726> > > > > Instead of constructing and passing the message why not do the message > > construction in _doReliableRegistration()? That way you would avoid any > > nasty races. The message is being constructed in _doReliableRegistration now. But it only reregisters the executorInfos that was collected in doReliableRegistration. I did that as I was in doubt whether we could rely on no new executors being launched in the interim. Should we assume this and just CHECK() that all executor's infos are ready? > On April 2, 2014, 5:47 p.m., Vinod Kone wrote: > > src/slave/slave.cpp, line 992 > > <https://reviews.apache.org/r/19795/diff/3/?file=544927#file544927line992> > > > > Do we need this future passed through considering we have the > > executorInfo member variable? I think it was mostly for error checking. Should we move towards .onReady() and have .onFailed(), onDiscarded() or a onAny(error(lambda::_1)) which catches and reports those errors? > On April 2, 2014, 5:47 p.m., Vinod Kone wrote: > > src/slave/slave.cpp, line 1188 > > <https://reviews.apache.org/r/19795/diff/3/?file=544927#file544927line1188> > > > > ditto. Do we need this future passed through considering we have the > > executorInfo member variable? See the question above :) > On April 2, 2014, 5:47 p.m., Vinod Kone wrote: > > src/slave/slave.cpp, lines 1207-1209 > > <https://reviews.apache.org/r/19795/diff/3/?file=544927#file544927line1207> > > > > I don't think the slave can be in RECOVERING state here? > > > > Also, do we want to proceed if the slave is TERMINATING? > > Fair enough - the check was stolen from the top half, but you are right. Those states are caught in the tests. > On April 2, 2014, 5:47 p.m., Vinod Kone wrote: > > src/slave/slave.cpp, line 1641 > > <https://reviews.apache.org/r/19795/diff/3/?file=544927#file544927line1641> > > > > ditto. Do we need this future passed through considering we have the > > executorInfo member variable? See question on top :) > On April 2, 2014, 5:47 p.m., Vinod Kone wrote: > > src/slave/slave.cpp, line 1823 > > <https://reviews.apache.org/r/19795/diff/3/?file=544927#file544927line1823> > > > > ditto. do we need to pass the future? See question above. > On April 2, 2014, 5:47 p.m., Vinod Kone wrote: > > src/slave/slave.cpp, lines 3433-3460 > > <https://reviews.apache.org/r/19795/diff/3/?file=544927#file544927line3433> > > > > I don't think you need this. It is not possible that you are here if > > "state.info.isNone()" because that means state.runs.empty() and > > state.latest.isNone(). IOW, it's not possible that you have non-zero runs > > but not have executor info. Does that make sense? > > > > To make this precise, in fact you can add state.info.isNone() to the if > > check at the top and do a CHECK(state.info.isSome()) here. > > > > I removed this piece, but think we should discuss recovery/clean-up of containers/executors that is launching during fail-over. Any suggestions of where we can hook in and pick up the presence of a container (but with no executor)? > On April 2, 2014, 5:47 p.m., Vinod Kone wrote: > > src/slave/slave.cpp, lines 3260-3264 > > <https://reviews.apache.org/r/19795/diff/3/?file=544927#file544927line3260> > > > > Do you want to address this TODO now? > > > > I'm afraid that if you only make ExecutorInfo a future when we revisit > > this TODO we have to go through the same pain of refactoring? So we should actually have a different Containerizer::launch() API. I wonder if the whole executor struct or a nested struct should be returned by launch (with directory, container id and executor info)? > On April 2, 2014, 5:47 p.m., Vinod Kone wrote: > > src/slave/slave.cpp, lines 3266-3272 > > <https://reviews.apache.org/r/19795/diff/3/?file=544927#file544927line3266> > > > > In fact I think even the directory should be handled by the > > containerizer? See question above. - Niklas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19795/#review39335 ----------------------------------------------------------- On April 3, 2014, 5:22 p.m., Niklas Nielsen wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/19795/ > ----------------------------------------------------------- > > (Updated April 3, 2014, 5:22 p.m.) > > > Review request for mesos, Ian Downes and Vinod Kone. > > > Bugs: MESOS-922 > https://issues.apache.org/jira/browse/MESOS-922 > > > Repository: mesos-git > > > Description > ------- > > This is the 2nd part of the task-info patch split > (https://reviews.apache.org/r/18403/) and changes Executor::info to an > executor info future. > This is motivated by delegating executor info creation/choice to the > containerizer to address new container/executor scenarios > (https://issues.apache.org/jira/browse/MESOS-922). > > This patch use the new Executor::info and introduces new continuations to > deal with launching containers i.e. executor infos are to be determined. > > > Diffs > ----- > > src/slave/http.cpp 594032d > src/slave/slave.hpp 15e23ce > src/slave/slave.cpp a356f5f > > Diff: https://reviews.apache.org/r/19795/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Niklas Nielsen > >
