[
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)
