> On May 23, 2017, 9:01 p.m., Vinod Kone wrote: > > src/master/allocator/mesos/hierarchical.hpp > > Line 309 (original), 309 (patched) > > <https://reviews.apache.org/r/57817/diff/4-8/?file=1689440#file1689440line312> > > > > I don't quite follow why you need to have this variable here? Looks > > like the sorter can be the source of truth of whether a role is activated > > or not?
`FrameworkInfo::roles` indicates all the roles the framework registers as, and `Call::Subscribe::suppressed_roles` is a subset of roles for which the master would not offer resources. The effective `suppressed_roles` can change (after the framework is (re)registered) with `SUPPRESS` and `REVIVE` calls, which means the roles for which offers are sent to frameworks can change based on roles contained in these messages. Now, the existing `activateFramework()` (and `deactivateFramework()`) activates (and deactivates) all roles of the framework. I think that should not be the case any longer. We should activate (and deactivate) roles of the framework which are not contained in `suppressed_roles` at any given point of time. To achieve this, we keep track of `HierarchicalAllocatorProcess::Framework::Framework::suppressed_roles` to ensure we keep track of `suppressed_roles` based on `SUPPRESS` and `REVIVE` calls during the life cycle of the framework. This would help us determine if we activate (or deactivate) for a specific role based on whether the role is a `suppressed_roles`. > On May 23, 2017, 9:01 p.m., Vinod Kone wrote: > > src/master/allocator/mesos/hierarchical.cpp > > Lines 348 (patched) > > <https://reviews.apache.org/r/57817/diff/4-8/?file=1689441#file1689441line352> > > > > why the if? is the `sorter::activate` not idempotent? See response to the first comment. > On May 23, 2017, 9:01 p.m., Vinod Kone wrote: > > src/master/allocator/mesos/hierarchical.cpp > > Lines 370 (patched) > > <https://reviews.apache.org/r/57817/diff/4-8/?file=1689441#file1689441line374> > > > > ditto. Same as the response to the first comment. > On May 23, 2017, 9:01 p.m., Vinod Kone wrote: > > src/master/master.cpp > > Lines 2804-2808 (patched) > > <https://reviews.apache.org/r/57817/diff/4-8/?file=1689443#file1689443line2809> > > > > why do you need this check? is the below one not sufficient? Just an optimization to not loop through the roles in `suppressedRoles` incase the sizes of `frameworkRoles` and `suppressedRoles` differ. But I think it should be fine to loop through since we do not anticipate the number of roles to be too many. - Anindya ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/57817/#review175846 ----------------------------------------------------------- On May 23, 2017, 10:19 p.m., Anindya Sinha wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/57817/ > ----------------------------------------------------------- > > (Updated May 23, 2017, 10:19 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 the `SUBSCRIBE` indicates a subset of roles to be suppressed during > framework (re)registration, the allocator does not offer resources for > those roles to such frameworks. Note that this functionality is added > for `v1::SUBSCRIBE` only (and not for scheduler driver API). > > In addition, the master validates the suppressed roles to be a subset > of all the roles being (re)registered by the framework. > > > Diffs > ----- > > include/mesos/allocator/allocator.hpp > dc34a1b6f0c2bdf0d653bd53394364cfa9873ca7 > src/common/protobuf_utils.hpp be2325f05b81b847fa592eff65175cbc99764fd6 > src/common/protobuf_utils.cpp 3fcaf786b29a00f003c10b0f1614a2c7eddc725d > src/master/allocator/mesos/allocator.hpp > 119b461136123229f85ed3c3cfd41137974a6b9b > src/master/allocator/mesos/hierarchical.hpp > 123f97cf495bff0f822838e09df0d88818f04da6 > src/master/allocator/mesos/hierarchical.cpp > b75ed9a20a9a42f958cebbacd91e5e15b0d21394 > src/master/master.hpp 89d0790fd5fea59e74276f462581fe0073594732 > src/master/master.cpp 1c89a1159d8ac01a40f567beb14ed424ac613912 > src/tests/allocator.hpp 4ea722491f63f5ceda5a47228aafddc020f643b0 > src/tests/hierarchical_allocator_tests.cpp > 6dee2296d5a14185dbf7eee17968b20148839bfd > src/tests/master_allocator_tests.cpp > d05ee441a5120144aff42d78c095e1ce5051a6ac > src/tests/persistent_volume_endpoints_tests.cpp > 8c54372b7f6d94f0335561086f2a8cb90373e285 > src/tests/reservation_tests.cpp 4504831d77c1bfcf5f2ddf6d28cd45dea2c421ad > src/tests/resource_offers_tests.cpp > f0bca1d9e03013ce35215b0ffa6b50b38972dc0c > src/tests/slave_recovery_tests.cpp 52e78b6b6280a159233b402ce2849448204d4f11 > > > Diff: https://reviews.apache.org/r/57817/diff/9/ > > > Testing > ------- > > All tests passed. > > > Thanks, > > Anindya Sinha > >
