Alexey Serbin has posted comments on this change. Change subject: Kudu Jepsen Tests - Initial Commit ......................................................................
Patch Set 6: (2 comments) Thank you for the review! Certainly we should communicate on our expectations and requirements. I considered this original David's patch as a foundation to build the necessary functionality to run jepsen test against freshly built Kudu binaries. You can find the result at: http://sandbox.jenkins.cloudera.com/view/Kudu/job/kudu-jepsen/ I decided to address some comments right away to resolve the ambiguity and suspense. I'm planning to get back on the rest when I'm back from vacation. I'm not sure what would be the best way to proceed here: merge everything into one patch or something else. As you can see, I have two additional patches based on this: https://gerrit.cloudera.org/#/c/5500/ https://gerrit.cloudera.org/#/c/5551/ https://gerrit.cloudera.org/#/c/5559/ I hope that answers at least some questions. http://gerrit.cloudera.org:8080/#/c/5492/6/java/kudu-jepsen/src/main/clojure/jepsen/kudu.clj File java/kudu-jepsen/src/main/clojure/jepsen/kudu.clj: Line 74: (c/su > So the obvious question is: why do we need to use system packages with Jeps In my subsequent patch there are provisions to run that with binaries only. That was the original approach that David and I were running at our laptops in Docker for Mac. I think we need two options here: (a) run against built packages (Debian only due to Jepsen restrictions) and (b) run against freshly built binaries. In http://sandbox.jenkins.cloudera.com/view/Kudu/job/kudu-jepsen/ the latter approach is used. And that will be an option. Line 74: (c/su > In general, it's much easier to run tests without root access on the remote The root access is needed to manage IP filter and other nemesis (i.e. failure-injection) stuff -- that's how Jepsen does its failure injection thing on DB nodes. I don't think we are about to re-do that part, at least in the nearest future. Ideally, it would be nice to run everything using our minicluster (as Dan already mentioned somewhere), but that would result in invasive changes on Jepsen core code. So, I would opt for keeping requirement for root access at remote nodes, so we are conformant with Jepsen infrastructure. The NTP part could be removed if we add a separate provision in our Kudu source to ignore non-synced time -- that we will need eventually anyway (I started that patch, but it's not ready for review yet). But as for now I don't see a problem here. -- To view, visit http://gerrit.cloudera.org:8080/5492 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: I590c6e78840304b3131666c7037ff9a08dc77dea Gerrit-PatchSet: 6 Gerrit-Project: kudu Gerrit-Branch: master Gerrit-Owner: David Ribeiro Alves <dral...@apache.org> Gerrit-Reviewer: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Alexey Serbin <aser...@cloudera.com> Gerrit-Reviewer: Dan Burkert <danburk...@apache.org> Gerrit-Reviewer: David Ribeiro Alves <dral...@apache.org> Gerrit-Reviewer: Jean-Daniel Cryans <jdcry...@apache.org> Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Todd Lipcon <t...@apache.org> Gerrit-HasComments: Yes
