[
https://issues.apache.org/jira/browse/KUDU-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16041172#comment-16041172
]
Jean-Daniel Cryans commented on KUDU-2034:
------------------------------------------
bq. The kudu-jepsen setup has been running with no errors for a long time
already.
This isn't something that's running on ASF infra and the results aren't
published either, right? It'd be nice if we could make the above claim and also
back it.
> 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 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.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
