Jepsen @jepsen@jepsen.io

New #Jepsen report: we worked with @ScyllaDB to identify and fix cases of LWT split-brain in healthy clusters due to improper hashing and membership changes, as well as documentation improvements. Notably, Scylla no longer claims non-LWT isolation! https://jepsen.io/analyses/scylla-4.2-rc3

Here's the slides for the most recent Jepsen talk, presented at #YOW20: https://aphyr.com/media/talks/2020/jepsen-13.pdf

Can you really say data loss is a *myth* if it's still the default behavior? https://developer.mongodb.com/article/everything-you-know-is-wrong#myth-7--mongodb-loses-data

Happy to announce Jepsen 0.2.1 is now available: https://github.com/jepsen-io/jepsen/releases/tag/0.2.1

Jepsen's AWS Marketplace product (launches a whole Jepsen cluster in a few clicks) has been updated for Debian Buster, and now includes additional dependencies you'll want for running tests based on Elle. Happy testing!

https://aws.amazon.com/marketplace/pp/Jepsen-LLC-Jepsen/B01LZ7Y7U0

Put a bunch of work into the Jepsen docker-compose setup, and I'm pleased to report it now gives you a full Debian Buster cluster with keys and dependencies out of the box--should be good for running the latest tests. Hopefully this helps!

https://github.com/jepsen-io/jepsen/tree/master/docker

🤔 https://docs.datastax.com/en/dse/6.0/cql/cql/cql_reference/cql_commands/cqlBatch.html

Do you use Cassandra or another CQL-compatible database? I'd like to hear your perspective on adding things to a CQL set: https://docs.google.com/forms/d/e/1FAIpQLSc5EqGjHA6HwXcvm5Om0jfNjaiKybHLjeppB32K502Amdsa8g/viewform?usp=sf_link

A bug in Jepsen: from versions 0.1.2 to 0.2.0, the counter checker docstring incorrectly claimed to handle decrements, which could cause valid histories to be reported as failures. This did not affect official Jepsen reports, but other counter tests using decrements may have been affected: https://groups.google.com/u/1/a/jepsen.io/g/announce/c/GsQ6e2e-Mcs

Love this thing where Google Cloud decides that jepsen.io has been stable for a while and it really ought to do something about that, so it kills the VM and spins up a new one to replace it only *after* it's dead, resulting in ~10 minutes of spurious downtime.

It's been doing this for ~two years, COME ON Google, y'all are supposed to be experts at rollouts. Start new nodes *before* you kill existing ones!

Did an interview with Tobias Macey talking about Jepsen's design, software verification in general, and the distributed database landscape: https://www.dataengineeringpodcast.com/jepsen-distributed-systems-testing-episode-143/

Anyway, if you have strong feelings, drop em here.

It's also, like... Jepsen is roughly 50/50 paid vs unpaid work right now. Jepsen contract rates are high, which covers research, maintenance, and writing in between. It's hard to imagine sponsors could materially shift that balance.

On the other hand, this presents a conflict-of-interest problem: so long as reports have a single sponsor (typically the vendor), it's easy to disclose and understand, but that's much trickier when there's a mix of a dozen ongoing sponsors.