> On June 4, 2014, 6:13 p.m., Vinod Kone wrote:
> > src/tests/launcher_tests.cpp, line 70
> > <https://reviews.apache.org/r/22224/diff/1/?file=603296#file603296line70>
> >
> >     do the users even need to know the path of the "mesos-launcher"? why 
> > can't "operation" figure that out because it is always the same?

We cannot hard coded it because:

1) in test, it is in <build>/src/mesos-launcher (tests::flags::build_dir)
2) in production, it is in <install>/libexec/mesos-launcher (flags.launcher_dir)


> On June 4, 2014, 6:13 p.m., Vinod Kone wrote:
> > src/launcher/launcher.cpp, line 136
> > <https://reviews.apache.org/r/22224/diff/1/?file=603294#file603294line136>
> >
> >     from the environment and command line right?
> >     
> >     the flags are set in the environment afaict. what other flags are 
> > expected on the command line?

Well, the 'launcher' can be used from command line as well (e.g., for debugging 
purpose). In that case, we are parsing the flags from command line.


> On June 4, 2014, 6:13 p.m., Vinod Kone wrote:
> > src/launcher/launcher.hpp, line 37
> > <https://reviews.apache.org/r/22224/diff/1/?file=603293#file603293line37>
> >
> >     I think "Command" reads better here than "Operation"? e.g: subprocess 
> > executes a command.

'Command' is also overloaded. I still prefer Operation:) Do you insist?


> On June 4, 2014, 6:13 p.m., Vinod Kone wrote:
> > src/Makefile.am, line 200
> > <https://reviews.apache.org/r/22224/diff/1/?file=603292#file603292line200>
> >
> >     we already use "launcher" in containerizer. can we use some other name 
> > for this to avoid confusion? how about operator? or command?

Yeah, but we also have src/launcher directory which is totally irrelevant to 
Launcher in containerizer.


- Jie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22224/#review44728
-----------------------------------------------------------


On June 3, 2014, 11:46 p.m., Jie Yu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22224/
> -----------------------------------------------------------
> 
> (Updated June 3, 2014, 11:46 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Ian Downes, and Vinod Kone.
> 
> 
> Bugs: MESOS-1446
>     https://issues.apache.org/jira/browse/MESOS-1446
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Currently, whenever we want something to be executed in a subprocess, we 
> create a separate binary (e.g., mesos-fetcher, mesos-executor, mesos-usage, 
> etc.). This has several drawbacks:
> 
> 1) Code duplication (passing arguments, main function, etc.)
> 2) Split logic into multiple files (not good for readability)
> 
> To solve that, I created a generic 'launcher' for 'Operation's. Users can 
> define their own 'Operation' and 'launch' it in a subprocess. For instance:
> 
> class CustomizedOperation : public Operation
> {
> public:
>   class Flags : public flags::FlagsBase
>   {
>     Flags();
>     Option<string> arg1;
>     Option<int> arg2;
>   };
> 
> protected:
>   virtual string name() const { return "customized_operation"; }
> 
>   virtual int execute()
>   {
>     if (arg1.isNone()) { return 1; }
>     if (arg2.isNone()) { return 1; }
> 
>     do_something(arg1.get(), arg2.get());
>   }
> };
> 
> In your code, if you want to execute 'CustomizedOperation' in a subprocess, 
> you can just launch it:
> 
> CustomizedOperation operation;
> operation.flags.arg1 = "arg1";
> operation.flags.arg2 = "arg2";
> 
> operation.launch(flags.launcher_dir + "/mesos-launcher");
> 
> We will handle the flags passing and parsing for you under the hood.
> 
> 
> Diffs
> -----
> 
>   src/Makefile.am ffde59b 
>   src/launcher/launcher.hpp PRE-CREATION 
>   src/launcher/launcher.cpp PRE-CREATION 
>   src/launcher/main.cpp PRE-CREATION 
>   src/tests/launcher_tests.cpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/22224/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Reply via email to