[jira] [Updated] (KUDU-2034) For kudu-jepsen scenario, add parameters to induce more frequent fail-over events on the server side

["Alexey Serbin (JIRA)" <ji...@apache.org>]

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

Alexey Serbin updated KUDU-2034:
--------------------------------
    Labels: consistency kudu-jepsen newbie  (was: consistency kudu-jepsen)

> For kudu-jepsen scenario, add parameters to induce more frequent fail-over events on the server side
> ----------------------------------------------------------------------------------------------------
>
>                 Key: KUDU-2034
>                 URL: https://issues.apache.org/jira/browse/KUDU-2034
>             Project: Kudu
>          Issue Type: Task
>    Affects Versions: 1.4.0
>            Reporter: Alexey Serbin
>              Labels: consistency, kudu-jepsen, newbie
>
> The kudu-jepsen setup has been running with no errors for a long time already.  Current set of parameters for the back-end components while running kudu-jepsen test is standard -- everything is set to default values except for enabling experimental flags.  Yes, it made sense to test it like that since originally we were thinking to make sure the test does not fail with the parameters the system is run in the production, but now we can start covering broader scenario specter.
> Let's set parameters to induce more frequent re-election/fail-over events at the server side.  The idea is to check what we have under {{src/kudu/integration-tests}}.  E.g., parameters in {{catalog_manager_tsk-itest.cc}} contains an example of good set of parameters to enable frequent re-elections among masters: the raft-related parameter from there can be used as a starting point for tserver's parameter set. 
> An additional step could be injecting latency into tserver operations.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)