[
https://issues.apache.org/jira/browse/KUDU-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin updated KUDU-2034:
--------------------------------
Description:
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 the parameters that the system was run in the
production. 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.
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 the parameters the system was run in the
production. 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
>
> 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 the parameters that the
> system was run in the production. 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.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
