mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Bannier <benjamin.bann...@mesosphere.io>
Subject Re: Review Request 69942: Added a test for MESOS-9554.
Date Tue, 12 Feb 2019 21:21:48 GMT


> On Feb. 12, 2019, 7:34 p.m., Benjamin Bannier wrote:
> > src/tests/hierarchical_allocator_tests.cpp
> > Lines 2924-2929 (patched)
> > <https://reviews.apache.org/r/69942/diff/1/?file=2124739#file2124739line2924>
> >
> >     This test actually is more than a regression test for MESOS-9554 as it validates
to some extent that framework allocation decisions are independent (but for possibly decreasing
the available resource pool).
> >     
> >     Maybe rephrase along the lines of
> >     ```
> >     This test validates with one case that framework allocation decisions are independent
(but for possibly decreasing the available resource pool). In particular, we validate that
the decision not to allocate resources of an agent to a particular framework does not influence
to allocate the same resources to another agent. In this test we make agent resources not
allocatable to a framework by refining the resource reservations while the framework which
should be allocated these resources based on DRF share is not capable of receiving them (it
lacks the `RESERVATION_REFINEMENT` capability).
> >     
> >     This is a regression test for MESOS-9554.
> >     ```
> >     
> >     We could also rename the test, e.g., to `HierarchicalAllocatorTest.AllocationIndependent`
(doesn't read to well, either). This tests models a whole class of scenarios we currently
don't validate.
> 
> Benjamin Mahler wrote:
>     Thanks for the suggestion. I will have to think on this, and so I'll leave it open
for now

Thinking more about this, "allocations have no effect on each other" doesn't seem right. A
better invariant might that absent quota all cluster resources get allocated if at least one
framework could receive them. We could even generalize this

Given
- `k` reasons resources could not be allocatable to a framework (e.g., filters for whole agents
or parts of them, framework capabilities)
- `n > k` frameworks

For all assignments of reason to `n - 1` frameworks (reasons can be repeated; an assignement
doesn't need to use all `k` reasons, `n`th framework can always receive any resource):
  For all DRF sortings of frameworks:
    sum of allocations == total resources

If we care about this, it should be possible to generate all possible configurations and check
them.

There might be other invariants which could be checked in a similar way. Quota be treated
similarly, but we'd need to include quota headroom.


- Benjamin


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


On Feb. 11, 2019, 7:21 p.m., Benjamin Mahler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/69942/
> -----------------------------------------------------------
> 
> (Updated Feb. 11, 2019, 7:21 p.m.)
> 
> 
> Review request for mesos, Benjamin Bannier and Meng Zhu.
> 
> 
> Bugs: MESOS-9554
>     https://issues.apache.org/jira/browse/MESOS-9554
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This test ensures that the framework allocation loop does not
> incorrectly break in the case that a framework is incapable
> of receiving the resources on an agent. In this case, the loop
> should continue as other frameworks may be capable of receiving
> the resources.
> 
> 
> Diffs
> -----
> 
>   src/tests/hierarchical_allocator_tests.cpp cc88afbad1b4e6bf707cb13b50c964aa01f9a3ee

> 
> 
> Diff: https://reviews.apache.org/r/69942/diff/1/
> 
> 
> Testing
> -------
> 
> Ensured it fails on master, succeeds after fix to MESOS-9554.
> 
> Ran in repetition.
> 
> 
> Thanks,
> 
> Benjamin Mahler
> 
>


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