mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anindya Sinha <anindya_si...@apple.com>
Subject Re: Review Request 57817: Offers not sent for suppressed roles as indicated in `SUBSCRIBE`.
Date Tue, 23 May 2017 22:19:43 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?

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


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