[jira] [Resolved] (KUDU-2631) DeleteTableITest.TestNoDeleteTombstonedTablets is a little flaky

["Will Berkeley (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KUDU-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Will Berkeley resolved KUDU-2631.
---------------------------------
       Resolution: Fixed
         Assignee: Alexey Serbin  (was: Will Berkeley)
    Fix Version/s: 1.8.0

Whoops, looks like I was running an older version. Alexey fixed this with 91e207fccf95230476b4455b825e9eadd106a19f back in March.

> DeleteTableITest.TestNoDeleteTombstonedTablets is a little flaky
> ----------------------------------------------------------------
>
>                 Key: KUDU-2631
>                 URL: https://issues.apache.org/jira/browse/KUDU-2631
>             Project: Kudu
>          Issue Type: Bug
>    Affects Versions: 1.8.0
>            Reporter: Will Berkeley
>            Assignee: Alexey Serbin
>            Priority: Major
>             Fix For: 1.8.0
>
>
> delete_table-itest's TestNoDeleteTombstonedTablets test case is a little flaky since 87dcaf34d3. which implemented removal of excess replicas in the master. The test does the following:
> {noformat}
> A. Find the leader L of tablet T
> B. Find a server X that's not the leader L but has a replica of T.
> C. Find a server Y that has no replica of T.
> D. Add a replica of T to Y (as a VOTER).
> E. Remove the replica of T from X.
> F. Wait and check that the master doesn't delete the tombstoned replica of T on Y, even after restart.
> {noformat}
> The problem is that step D makes T over-replicated, so E is racing with the master removing Y. Rarely, the master wins the race and its config change is pending when step E occurs, which causes E to fail because a tablet will only accept one config change at a time.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)