Alexey Serbin created KUDU-2034:
-----------------------------------
Summary: 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
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)
