mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Kone <vinodk...@gmail.com>
Subject Re: Review Request 57817: Offers not sent for suppressed roles as indicated in `SUBSCRIBE`.
Date Wed, 31 May 2017 00:43:51 GMT


> 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?
> 
> Anindya Sinha wrote:
>     `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`.

I see. Makes sense. Can you add a comment to activateFramework/deactivateFramework about the
new semantics for posterity?


> 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?
> 
> Anindya Sinha wrote:
>     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.

looks like you fixed it, not sure why you marked it as "dropped".


- Vinod


-----------------------------------------------------------
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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message