----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/52288/#review152323 -----------------------------------------------------------
src/tests/persistent_volume_tests.cpp (lines 1079 - 1086) <https://reviews.apache.org/r/52288/#comment221303> Actually, if we don't guarantee that `acceptOffer` is processed first, we can't guarantee that `framework2` receives an offer below even with time advancement (if framework2 registers before framework1 launches) We should settle clock here and then the time advancement below ``` AWAIT_READY(frameworkId2); Clock::advance(masterFlags.allocation_interval); AWAIT_READY(offers2); ``` won't be necessary. - Jiang Yan Xu On Oct. 7, 2016, 8:12 a.m., Anindya Sinha wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/52288/ > ----------------------------------------------------------- > > (Updated Oct. 7, 2016, 8:12 a.m.) > > > Review request for mesos and Jiang Yan Xu. > > > Bugs: MESOS-6257 > https://issues.apache.org/jira/browse/MESOS-6257 > > > Repository: mesos > > > Description > ------- > > When a framework issues a DESTROY of a shared volume, and that volume > is not in use by a running or a pending task, we rescind the offers > from frameworks to which the shared volume is present in pending offers > so that the volume is not assigned to any task in a future ACCEPT call. > At that time, we need to recover the resources as well for proper > accounting of such resources by the allocator. > > > Diffs > ----- > > src/master/master.cpp c7e74df71aa31edb490f4f3bd95f2d5aa94b4324 > src/tests/persistent_volume_tests.cpp > e10a79e9662530e143ccaa2aa2506a4d25158364 > > Diff: https://reviews.apache.org/r/52288/diff/ > > > Testing > ------- > > All tests passed. > > > Thanks, > > Anindya Sinha > >
