Writes require the lease too, so it is not possible for a quorum of nodes on one side of a partition to serve writes while a lease holder on the other side serves stale reads. This is a degenerate case of quorum leases (https://www.cs.cmu.edu/~dga/papers/leases-socc2014.pdf) for a single lease holder; in the future we're interested in supporting multiple lease holders to improve read latency (at the expense of write performance and availability).
Writes becoming unavailable during a partition is a reasonable solution for a CP system.
It's probably not hard to require that writes (which require a majority) also require the lease-holder to ack the write, which seems like it'd solve this. It's a bit odd that they don't mention anything like this, but it is a fairly short blog post.
A bit of lazy browsing didn't lead me to any more detailed descriptions of how it handles partitions. Anyone else know?
So, what happens to readers who are partitioned away from the node which holds that data? Can they not read the data for that lease duration? If they can't, then yeah, CP is a good description.
...
So the design doc seems to hold this up - reads must go to the lease holder, until the lease expires. Nice.
EDIT: Design doc link:
https://github.com/cockroachdb/cockroach/blob/master/docs/de...