> On July 14, 2015, 12:20 a.m., Paul Brett wrote:
> >
> 
> Artem Harutyunyan wrote:
>     <a drive by comment suggested by Joris> is inline really necessary here?

well, it is - as this is a header file (not having the `inline` will cause a 
linker error for a 'duplicate definition' or something).
Happy to move it to a `.cpp` file, but there's been disagreement about this in 
the past, so I'm following the same pattern as `subprocess` here.


> On July 14, 2015, 12:20 a.m., Paul Brett wrote:
> > 3rdparty/libprocess/include/process/subprocess.hpp, line 307
> > <https://reviews.apache.org/r/36424/diff/1/?file=1008891#file1008891line307>
> >
> >     How about returning a tuple/struct of stdout, stderr and return code 
> > and let the caller decide what they want?
> 
> Marco Massenzio wrote:
>     sure, that would be a possibility too, but it seems to me that the 
> "approved way" in Mesos is to return a `Try` for when something *may* go 
> wrong.
>     This is consistent across the entire code base.
> 
> Artem Harutyunyan wrote:
>     Maybe I am missing something, I did a grep for `Future<Try..` and could 
> not find any occurence of it in the code base. Perhaps the reason is that 
> it's customary to use Future's `Failure()` to indicate an error (as opposed 
> to returning a `Try`). If anything `Result` would probably be more 
> appropriate here than Try, but I'd like to hear what a shepherd has to say.
>     
>     The function could just return `Future<std::string>` and you could use 
> `Failure()` to indicate the error. In that case you'll need to change the 
> return type of `.then` lamda to `Future<std::string>` and also to replace a 
> `return Error(...` on line 346 with `return Failure(...` (which you might 
> want to do anyway for the sake of consistency).
> 
> Marco Massenzio wrote:
>     > I'd like to hear what a shepherd has to say.
>     
>     eh eh, no kidding - while writing this code, I swear my brain melted :)
>     
>     The one thing to bear in mind (and that's probably the reason this is a 
> bit of a 'only child') is that the 'error mode' here is different than 
> elsewhere: if the command 'fails' the request to run a command actually 
> 'succeeded' - if I try to execute: 'ls -la /tmp/foo' well, the command 
> executes successfully, it's just that `foo` ain't there.
>     
>     So, the semantics of a "Future of a Try" is that, yep, your request 
> succeeded and, yay!, your command succeeded too *or* dang! that failed and 
> here's the error message.
>     
>     (side note: that's also the reason why I return a 200 OK from the 
> `/execute` endpoint, even if the command fails - your Request, nonetheless 
> succeeded).
>     
>     But I can be convinced both ways, and return instead a `Failure(stderr)`
>     
>     However, I like the tuple idea better because (a) the exit code carries 
> information that we'd be losing and (b) sometimes, to understand what really 
> went wrong, one needs both stdout **and** stderr, so I'm considering 
> returning a `(code, stdout, stderr)` tuple (yay! C++11 FTW)

Upon further debate (and following @BenM advice - see below) we will be 
returning a `Future<CommandResultInfo>` (a protobuf that will also be defined 
anew in this patch) containing all the required info.


> On July 14, 2015, 12:20 a.m., Paul Brett wrote:
> > 3rdparty/libprocess/include/process/subprocess.hpp, line 309
> > <https://reviews.apache.org/r/36424/diff/1/?file=1008891#file1008891line309>
> >
> >     Could we drop the option and just have it default to an empty vector.
> 
> Marco Massenzio wrote:
>     Again, I'm trying to be consistent with the existing code base.
>     Very valid option, though.
>     
>     I'm happy to go either way, depending on what my shepherd says :)

Yes - I found a way to deal with the original need that works well with an 
empty vector.


> On July 14, 2015, 12:20 a.m., Paul Brett wrote:
> > 3rdparty/libprocess/include/process/subprocess.hpp, line 313
> > <https://reviews.apache.org/r/36424/diff/1/?file=1008891#file1008891line313>
> >
> >     If you just want to copy args, why not pass by value?
> 
> Marco Massenzio wrote:
>     not sure I fully understand the comment, anyways, here's my motivation 
> around this (seemingly pointless) bit of coding: the first element of the 
> array is treated as `argv[0]`: it is actually ignored (entirely) during the 
> execution, but will be used to print the 'usage' string (and/or the error 
> message) - so we need to pass a non-empty arg (with ideally the first element 
> matching the command invocation), but I wanted to avoid the caller to worry 
> about these details; so instead of passing:
>     ```
>     executeCommand("echo", vector<string>{"echo", "hello", "world"})
>     ```
>     they can just pass the command + args and be merry.

I will do that, figured out a way to deal with the issue mentioned in my 
earlier comment.


- Marco


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


On July 17, 2015, 5:52 a.m., Marco Massenzio wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/36424/
> -----------------------------------------------------------
> 
> (Updated July 17, 2015, 5:52 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Ben Mahler, and Cody Maloney.
> 
> 
> Bugs: MESOS-3035
>     https://issues.apache.org/jira/browse/MESOS-3035
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Jira: MESOS-2902
> 
> While researching how to execute an arbitrary script
> to detect the Master IP address, it emerged clearly that
> a helper method to execute an arbitrary command/script on
> a node and obtain either stdout or stderr would have been
> useful and avoided a lot of code repetition.
> 
> This could not be ultimately used for the purpose at hand,
> but I believe it to be useful enough (particularly, to avoid
> people doing "coding by copy&paste" and/or waste time
> researching the same functionality).
> 
> This would also be beneficial in MESOS-2830 and MESOS-2834
> factoring out the remote command execution logic.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/subprocess.hpp 
> 310cb4f8e4e2faa5545dffd196d7490c868bc5d6 
>   3rdparty/libprocess/src/tests/subprocess_tests.cpp 
> f6acb204582a9e696c3b09d4e4c543bb052e97d4 
> 
> Diff: https://reviews.apache.org/r/36424/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Marco Massenzio
> 
>

Reply via email to