mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph Wu" <jos...@mesosphere.io>
Subject Re: Review Request 40935: Fixed flakiness in MasterMaintenanceTest.InverseOffersFilters.
Date Fri, 04 Dec 2015 01:30:22 GMT

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

Ship it!


Tested on Centos7.

There still appears to be some flakiness (in the first inverse offer filter) that requires
further investigation.  But these changes make the test significantly more stable.
I vote for committing this patch, but keeping the JIRA open until we nail down the flakiness
for good.


src/tests/master_maintenance_tests.cpp (lines 1485 - 1488)
<https://reviews.apache.org/r/40935/#comment168372>

    It might be valuable to expect an update for each task.
    
    Maybe check:
    `updateStatus.task_id() == taskInfo1.task_id() || updateStatus.task_id() == taskInfo2.task_id()`
    And between the two acknowledges, you could do:
    `updateStatus.task_id() != event.get().update().status().taskid()`
    
    ----
    Note: As far as I know, no other HTTP scheduler library test launches two tasks simultaneously.


- Joseph Wu


On Dec. 3, 2015, 4:17 p.m., Neil Conway wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/40935/
> -----------------------------------------------------------
> 
> (Updated Dec. 3, 2015, 4:17 p.m.)
> 
> 
> Review request for mesos, Joris Van Remoortere and Joseph Wu.
> 
> 
> Bugs: MESOS-4059
>     https://issues.apache.org/jira/browse/MESOS-4059
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> There were two problems:
> 
> (1) After launching two tasks, we assumed that we would see TASK_RUNNING updates
>     for the tasks in the same order they were launched. This is not guaranteed,
>     so adjust the test to handle TASK_RUNNING updates in the order they are
>     received.
> 
> (2) The test used this pattern:
> 
>         Mesos m;
>         Call c;
> 
>         m.send(c);
>         Clock::settle();
>         // Trigger a new batch allocation that reflects the call
>         Clock::advance();
> 
>     However, this is actually unsafe (see MESOS-3760): the send() call might not
>     have reached the master by the time `Clock::settle()` happens. This was
>     fixed by blocking using `FUTURE_DISPATCH` on the downstream logic in the
>     allocator that is invoked to handle the delivered event.
> 
> 
> Diffs
> -----
> 
>   src/tests/master_maintenance_tests.cpp 00900561a1b8dd03a7a2f3d60a036b4beb920aa1 
> 
> Diff: https://reviews.apache.org/r/40935/diff/
> 
> 
> Testing
> -------
> 
> ./src/mesos-tests --gtest_filter="MasterMaintenanceTest.InverseOffersFilters" --gtest_repeat=2000
# on OSX
> ./src/mesos-tests --gtest_filter="MasterMaintenanceTest.InverseOffersFilters" --gtest_repeat=100
 # on Ubuntu Wily (slow VM)
> 
> 
> Thanks,
> 
> Neil Conway
> 
>


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