> 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 > >
