[
https://issues.apache.org/jira/browse/KUDU-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18121167#comment-18121167
]
ASF subversion and git services commented on KUDU-2036:
-------------------------------------------------------
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]>
> kudu-jepsen: add a scenario to run against a set of machines having
> significant clock skew
> ------------------------------------------------------------------------------------------
>
> Key: KUDU-2036
> URL: https://issues.apache.org/jira/browse/KUDU-2036
> Project: Kudu
> Issue Type: Task
> Reporter: Alexey Serbin
> Priority: Major
> Labels: consistency, newbie, test
>
> It would be nice to introduce a run-time scenario for kudu-jepsen to run
> tablet servers on machines with significant clock skew (say, 30 seconds for
> the beginning).
> From the high-level, it seems feasible to update local clock on every machine
> and then start the ntpd daemon which uses machine's hardware clock as a
> driver (so, no external NTP server to sync with).
> While doing that, it's worth clarifying how to do the same trick if using
> Docker containers instead of VMs -- it might not work under Docker.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
