[
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 does not fail with the parameters the system is 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.
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.
> 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 does not fail with the parameters the system
> is 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)
