[
https://issues.apache.org/jira/browse/KUDU-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin updated KUDU-2034:
--------------------------------
Description:
Currently, the set of parameters for the back-end components is almost standard
-- everything is set to defaults, but the experimental flags are enabled and
only the following tserver flags are set to something 'special' to speed up the
test:
{noformat}
--heartbeat_interval_ms
--raft_heartbeat_interval_ms
--heartbeat_max_failures_before_backoff
{noformat}
Let's set parameters to induce frequent re-election/fail-over events at the
server side. The idea is to bring in set of parameters used by certain tests
in {{src/kudu/integration-tests}}. E.g., {{catalog_manager_tsk-itest.cc}}
contains an example of parameters to enable frequent re-elections among
masters; the raft-related part can be used as a starting point to update
tserver's parameters for kudu-jepsen.
An additional step might be injecting latency into tservers' operations.
was:
The kudu-jepsen setup has been running with no errors for a long time already.
Currently, the set of parameters for the back-end components is standard --
everything is set to defaults, but the experimental flags are enabled. Yes, it
made sense to run with the default parameters: originally we wanted to make
sure the test did not fail with production-alike settings. Now we can start
exercising 'artificially congested' scenarios.
Let's set parameters to induce frequent re-election/fail-over events at the
server side. The idea is to bring in set of parameters used by certain tests
in {{src/kudu/integration-tests}}. E.g., {{catalog_manager_tsk-itest.cc}}
contains an example of parameters to enable frequent re-elections among
masters; the raft-related part can be used as a starting point to update
tserver's parameters for kudu-jepsen.
An additional step might be injecting latency into tservers' operations.
> 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
>
> Currently, the set of parameters for the back-end components is almost
> standard -- everything is set to defaults, but the experimental flags are
> enabled and only the following tserver flags are set to something 'special'
> to speed up the test:
> {noformat}
> --heartbeat_interval_ms
> --raft_heartbeat_interval_ms
> --heartbeat_max_failures_before_backoff
> {noformat}
> Let's set parameters to induce frequent re-election/fail-over events at the
> server side. The idea is to bring in set of parameters used by certain tests
> in {{src/kudu/integration-tests}}. E.g., {{catalog_manager_tsk-itest.cc}}
> contains an example of parameters to enable frequent re-elections among
> masters; the raft-related part can be used as a starting point to update
> tserver's parameters for kudu-jepsen.
> An additional step might be injecting latency into tservers' operations.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
