[
https://issues.apache.org/jira/browse/KUDU-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18121168#comment-18121168
]
ASF subversion and git services commented on KUDU-2034:
-------------------------------------------------------
Commit 63a8252e2805cff4426f854d0e65f9cd7aca146b in kudu's branch
refs/heads/master from Alexey Serbin
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=63a8252e2 ]
[kudu-jepsen] remove kudu-jepsen Java sub-project
The kudu-jepsen Java sub-project hasn't been maintained for several
years already, and there hasn't been much demand or interest in
reviving it so far. All Gradle's tasks for the sub-project's were
effectively no-op with [1] (circa October 2020).
There was an alternative changelist posted for review at [2] to catch
kudu-jepsen up to the recent jepsen and clojure versions. However,
the automation piece was still missing, so it required maintaining
several pre-provisioned nodes/VMs to run the testbench.
Eventually, after digesting review feedback for [2] and a few rounds
of offline discussions, the consensus arrived to the decision: drop
the jepsen-based sub-project from the Kudu's upstream repo.
If necessary, it's possible to restore and refresh it from the repo
when there is interest in providing more coverage for data consistency
guarantees in Kudu.
With this update, perhaps we'll need to close KUDU-2036, KUDU-2034,
and KUDU-2609 with "Won't Fix" resolution.
[1] https://github.com/apache/kudu/commit/41a7c4e4e
[2] https://gerrit.cloudera.org/#/c/24867/
Change-Id: I3bd19411c8b032c326ba992d6ce83e38426ff66e
Reviewed-on: http://gerrit.cloudera.org:8080/24876
Reviewed-by: Marton Greber <[email protected]>
Tested-by: Marton Greber <[email protected]>
> 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
> Priority: Major
> 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
(v8.20.10#820010)
