> On Aug. 19, 2019, 9:44 a.m., Benjamin Mahler wrote:
> > What's the thinking on taking the allocator's framework struct? Why not 
> > just take the information we need so that we can keep the interface 
> > self-contained?

One of the goals of this refactoring is to eliminate state duplication between 
allocator and the sorter. My plan is to let sorter have back pointers pointing 
to both the framework (and the role in subsequent patches) and the role struct 
in the allocator.

Strictly speaking, there is not much information we need about the framework in 
the sorter:
- For random sorter, we only need frameworkId
- For DRF sorter, we only need to know allocations (which can be built in the 
sorter->allocated callbacks, however, note the duplication with the allocator).

Also, ideally, for any potential other sorter implementation that requires any 
other framework info (just a random example: sorting based on capability), 
carry a pointer makes more sense.

I am not sure what's the benefit of keeping the interface self-contained. If 
for unit testing, we can probably still make it unit-testable even if we carry 
the back pointer.


- Meng


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/71303/#review217293
-----------------------------------------------------------


On Aug. 16, 2019, 5 p.m., Meng Zhu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/71303/
> -----------------------------------------------------------
> 
> (Updated Aug. 16, 2019, 5 p.m.)
> 
> 
> Review request for mesos, Andrei Sekretenko and Benjamin Mahler.
> 
> 
> Bugs: MESOS-9917
>     https://issues.apache.org/jira/browse/MESOS-9917
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This paves the way for removing the framework sorters.
> 
> 
> Diffs
> -----
> 
>   src/master/allocator/mesos/hierarchical.cpp 
> 580d35a3b71c1f7e851fa0504c6b9f037c05c378 
>   src/master/allocator/mesos/sorter/drf/sorter.hpp 
> 537086039fd804453ea8c682cda775d8fdff038f 
>   src/master/allocator/mesos/sorter/drf/sorter.cpp 
> 09889cdf3dc8c0e773b8e2e24154fb0edd2cc254 
>   src/master/allocator/mesos/sorter/random/sorter.hpp 
> f18b014ed15ff8906fbdbd3248becefde896651c 
>   src/master/allocator/mesos/sorter/random/sorter.cpp 
> 60a5797472460a8d3d9be938af9f6711ea51d484 
>   src/master/allocator/mesos/sorter/sorter.hpp 
> 52b8a7b57bf17759311b32aa56c26e614119b773 
> 
> 
> Diff: https://reviews.apache.org/r/71303/diff/1/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Meng Zhu
> 
>

Reply via email to