----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/57817/#review171630 -----------------------------------------------------------
include/mesos/allocator/allocator.hpp Lines 135 (patched) <https://reviews.apache.org/r/57817/#comment244592> s/offersSuppressed/suppressed/ to be consistent with how we named it in the allocator. here and below. src/master/allocator/mesos/allocator.hpp Line 70 (original), 70-71 (patched) <https://reviews.apache.org/r/57817/#comment244843> This is making me think whether we want framework to subscribe with "inactive" field instead "suppress". The reason being, "suppressOffers" was originally added instead of "deactivateFramework" because the former was intended to have some filters. One such filter has been recently added: you can suppress offers for a specific role instead of all roles. Do we want to give the same flexibility for suppression during subscription? For example, here it's not clear to me what is the difference between "active" and "offersSuppressed" booleans as far as the allocator is concerned. Thoughts? - Vinod Kone On April 11, 2017, 11:10 p.m., Anindya Sinha wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/57817/ > ----------------------------------------------------------- > > (Updated April 11, 2017, 11:10 p.m.) > > > Review request for mesos, James Peach, Vinod Kone, and Jiang Yan Xu. > > > Bugs: MESOS-7015 > https://issues.apache.org/jira/browse/MESOS-7015 > > > Repository: mesos > > > Description > ------- > > If requested in SUBSCRIBE api call, offers are suppressed on > framework registration. > > > Diffs > ----- > > include/mesos/allocator/allocator.hpp > 6eda1b8619269c1501a935045b18b1deaf845b33 > src/master/allocator/mesos/allocator.hpp > 57b54b86c43c7731e64d422d285c4b8ca7e27a60 > src/master/allocator/mesos/hierarchical.hpp > f84b0574ce9a392c9528c87b04b01dbb2053cff7 > src/master/allocator/mesos/hierarchical.cpp > 051f749dd5921a322ca930a042c31814616d38f9 > src/master/master.hpp d537933d0b467a6f9996951c601b31338bb9d034 > src/master/master.cpp 0f4c64c6b102ef201779a331c96b5d78a98281ad > src/tests/allocator.hpp 6b71c574e0e4facd1795ef50ee0869c03b87833d > src/tests/hierarchical_allocator_tests.cpp > 33e7b455f8664858eb4f03727b076a10c80cd6e0 > src/tests/master_allocator_tests.cpp > 119e318f8a01d50e8dae5c30cf5fa6a017c3c625 > src/tests/persistent_volume_endpoints_tests.cpp > 1237d081d781948975f66a8240ae9bdb5e819a3b > src/tests/reservation_tests.cpp 4504831d77c1bfcf5f2ddf6d28cd45dea2c421ad > src/tests/resource_offers_tests.cpp > f0bca1d9e03013ce35215b0ffa6b50b38972dc0c > src/tests/slave_recovery_tests.cpp 53f33a2b0411c8158326074ce043c7b1dbeef5b4 > > > Diff: https://reviews.apache.org/r/57817/diff/4/ > > > Testing > ------- > > All tests passed. > > > Thanks, > > Anindya Sinha > >