----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/32975/#review79433 -----------------------------------------------------------
include/mesos/mesos.proto <https://reviews.apache.org/r/32975/#comment128789> please update type_utils.cpp to account for this field when comparing CommandInfos. src/launcher/fetcher.cpp <https://reviews.apache.org/r/32975/#comment128790> and chown is requested. src/tests/fetcher_tests.cpp <https://reviews.apache.org/r/32975/#comment128808> Add a note/todo here mentioning why you are setting these fields but not doing any asserts/expects on them. - Vinod Kone On April 8, 2015, 2:20 p.m., Jim Klucar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/32975/ > ----------------------------------------------------------- > > (Updated April 8, 2015, 2:20 p.m.) > > > Review request for mesos. > > > Bugs: MESOS-1790 > https://issues.apache.org/jira/browse/MESOS-1790 > > > Repository: mesos > > > Description > ------- > > Added chown to CommandInfo.URI protocol buffer as an optional > boolean that defaults to true, the current chown behavior. > > The fetcher was updated to skip the os::chown operation if the chown > boolean is set to false. > > No documentation was updated. > > > Diffs > ----- > > include/mesos/mesos.proto 3c592d5ab3092ecbeddfaff95e0c1addc3ac58f8 > src/launcher/fetcher.cpp 796526f59c25898ef6db2b828b0e2bb7b172ba25 > src/tests/fetcher_tests.cpp 4549e6a631e2c17cec3766efaa556593eeac9a1e > > Diff: https://reviews.apache.org/r/32975/diff/ > > > Testing > ------- > > Unit testing this functionality is difficult because it would require that > the user running the test to have permission to chown a file to someone other > than themselves. I didn't want to add that as a requirement to build. I added > the new field to the existing test cases just to see that they populate. > > > Thanks, > > Jim Klucar > >
