----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41001/#review109458 -----------------------------------------------------------
src/tests/reservation_tests.cpp (line 1548) <https://reviews.apache.org/r/41001/#comment169000> `s/can/cannot/`? src/tests/reservation_tests.cpp (line 1660) <https://reviews.apache.org/r/41001/#comment169003> This one gets dropped because it's an invalid unreserve request, right? This is still what's intended to be tested? src/tests/reservation_tests.cpp (lines 1690 - 1691) <https://reviews.apache.org/r/41001/#comment169001> Rather than changing `taskInfo` midway through the test, can we just label them `taskInfo1` and `taskInfo2` corresponding to `dynamicallyReserved1` and `dynamicallyReserved2` respectively? src/tests/reservation_tests.cpp (lines 1703 - 1704) <https://reviews.apache.org/r/41001/#comment169005> Just to make sure I understand the intent of this patch, this is the part where the operations are dropped due to authorization rather than invalid request. Correct? - Michael Park On Dec. 8, 2015, 5:14 p.m., Greg Mann wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/41001/ > ----------------------------------------------------------- > > (Updated Dec. 8, 2015, 5:14 p.m.) > > > Review request for mesos, Jie Yu and Michael Park. > > > Repository: mesos > > > Description > ------- > > Improved 'ReservationTest.ACLMultipleOperations'. > > > Diffs > ----- > > src/tests/reservation_tests.cpp eccbb8f8a02b65b26f34e020e736afe0445a6d0d > > Diff: https://reviews.apache.org/r/41001/diff/ > > > Testing > ------- > > `GTEST_FILTER="ReservationTest.ACLMultipleOperations" bin/mesos-tests.sh > --gtest_repeat=1000 --gtest_break_on_failure` > > This test was originally written to test the interaction of multiple > RESERVE/UNRESERVE/LAUNCH operations in a single `acceptOffers()` call when > authorization is enabled. In order to probe the effect of authorization on > this interaction, some operations should fail due to failed authorization. > However, this test included operations that failed simply because they were > malformed. I altered the test so that now operations will fail due to failed > authorization, which tests the desired functionality more precisely. > > > Thanks, > > Greg Mann > >
