> On Nov. 24, 2014, 12:28 p.m., Vinod Kone wrote: > > src/master/master.cpp, lines 2485-2493 > > <https://reviews.apache.org/r/28401/diff/1/?file=774586#file774586line2485> > > > > Modifying the task, framework and slave this late in the launch cyle is > > dangerous. > > > > What is the guarantee that the validations that we did earlier (task > > validations, framework and slave validations) still hold? > > > > The hook returns a Framework and Slave object that could potentially be > > different from what the Master has? What? Why? > > > > I'm really uncomfortable with this approach. > > Kapil Arya wrote: > This is a valid concern. Right now, we don't have a use-case to justify > the salve/framework modifications. We implemented it this way for > consistency purposes, such that we can specify a single policy for all hooks. > However, an alternative approach would be to have per-hook policies. For > example, in case of Master launch task hook, it would only to the TaskInfo > struct. If we want to be even more conservative, we can specify some > read-only fields in TaskInfo as well, e.g., everything apart from labels is > read-only.
Vinod: Agreed - I think the conclusion is that each hook need to be carefully placed, documented and side-effects considered (rather than doing a generic, one-size-fits-all). We should not change anything in the framework or slave structs, but as Kapil said: it was for consistensy / making the call-sites homogeneous. The guys in HTCondor did this by naming the hooks and define an API for hook developers such that they know what 1) State they get in 2) How the output will be interpreted. We should do something similar. - Niklas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28401/#review62860 ----------------------------------------------------------- On Nov. 24, 2014, 12:07 p.m., Kapil Arya wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/28401/ > ----------------------------------------------------------- > > (Updated Nov. 24, 2014, 12:07 p.m.) > > > Review request for mesos, Benjamin Hindman and Niklas Nielsen. > > > Bugs: MESOS-2060 > https://issues.apache.org/jira/browse/MESOS-2060 > > > Repository: mesos-git > > > Description > ------- > > Hooks can be specified on the command line by specifying the --hooks flags. > Hooks are implemented as Mesos modules that have to be specified via the > --modules flag which can also be used to specify any hook-specific command > line parameters. > > This is still a PoC based on the discussions on the dev mailing list. > > > Diffs > ----- > > src/Makefile.am 1d4ba1c8335eb8106cbccf903eaf3d9fdebdcda2 > src/hook/hook.hpp PRE-CREATION > src/hook/manager.hpp PRE-CREATION > src/hook/manager.cpp PRE-CREATION > src/master/flags.hpp 1cea50c02f3ad7de1e1ae91d65d1accdb9af7b03 > src/master/main.cpp 193d53f13d8b14638b311cc290b5a5802ea56299 > src/master/master.cpp de42f8eb7c3c4ed64fb7fea9f4977e276f4a9043 > src/module/hook.hpp PRE-CREATION > src/module/manager.cpp b15b0fc3f056fe29bd4d1acca508d75805ef2e0b > > Diff: https://reviews.apache.org/r/28401/diff/ > > > Testing > ------- > > > Thanks, > > Kapil Arya > >
