----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/49323/#review140559 -----------------------------------------------------------
src/tests/persistent_volume_endpoints_tests.cpp (lines 1639 - 1647) <https://reviews.apache.org/r/49323/#comment205974> It seems like the final test here is that the offer is recinded and that the unreserve request has been accepted. I'm curious as to why we don't check that the resources has been restored, like we do in the test below. In the test below, the last check is: ``` AWAIT_READY(offers); ASSERT_EQ(1u, offers.get().size()); offer = offers.get()[0]; EXPECT_TRUE(Resources(offer.resources()).contains(unreserved)); ``` - Michael Park On July 1, 2016, 9:47 a.m., Neil Conway wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/49323/ > ----------------------------------------------------------- > > (Updated July 1, 2016, 9:47 a.m.) > > > Review request for mesos, Alexander Rukletsov, Joris Van Remoortere, and > Michael Park. > > > Bugs: MESOS-5698 > https://issues.apache.org/jira/browse/MESOS-5698 > > > Repository: mesos > > > Description > ------- > > These tests check that dynamic reservations and persistent volumes can > be created via the offer API and then removed via the HTTP endpoints, > and vice versa. > > > Diffs > ----- > > src/tests/persistent_volume_endpoints_tests.cpp > 971a7b38d26b26c8543815e467f30cbb83ee412c > > Diff: https://reviews.apache.org/r/49323/diff/ > > > Testing > ------- > > make check > > This test passes without any Mesos changes. i.e., it doesn't reproduce the > bug by itself, but having more test coverage for this scenario seems wise. > > > Thanks, > > Neil Conway > >
