Some systems Jepsen tests are expensive or time-consuming to set up. They might involve lengthy compilation processes, large packages which take a long time to download, or allocate large files on initial startup.

Other systems require state which persists from run to run–for instance, there might be an expensive initial cluster join process, and you might want to perform that process once, save the cluster’s state to disk before testing, and for subsequent tests redeploy that state to nodes to skip the cluster join.

This namespace provides a persistent cache, stored on the control node’s filesystem, which is suitable for strings, data, or files. It also provides a basic locking mechanism.

Cached values are referred to by logical paths: a vector of strings, keywords, numbers, booleans, etc; see the Encode protocol for details. For instance, a cache path could be any of

:hi 1 true :foodb :license :key :foodb “1523a6b”

Cached paths can be stored and retrieved in several ways. Each storage type has a pair of functions: (cache/save-string! path “foo”) writes “foo” to path, and (cache/load-string path) returns the stored value as a string.

• As strings (save-string!, load-string)
• As EDN data (save-edn!, load-edn)
• As raw File objects (save-file!, load-file)
• As remote files (save-remote!, deploy-remote!)

In general, writers are (save-format! from-source to-path), and return from-source, allowing them to be used transparently for side effects. Readers are (load-format path), and return nil if the value is uncached. You can use (cached? path) to distinguish between a missing cache value and a present nil.

Writes to cache are atomic: a temporary file will be written to first, then renamed into its final cache location.

You can acquire locks on any cache path, whether it exists or not, using (locking path ...).