With that said, I feel really conflicted about v3. I understand why it was introduced and understand why it is objectively better than v2, however the reason I fell in love with etcd was because of v2. It was a simple, highly available, not very fast key store that exposed an easy way to view and traverse the store (via the /v2/keys API endpoint). Likewise, the client api was simple, quick to pickup and very easy to work with.
With v3, while the performance has increased dramatically (and many other things), the "ease" of etcd seems to have gone as well.
To this point, all of the software I've written that makes use of etcd is tied to etcd v2. Should I make a conscious effort to migrate to etcd v3? How much longer is v2 going to be kept around?
Can you explain this more? One of the goals of the new API is to make etcd easier to interact with.
Can you provide a few examples where v3 is more difficult than v2 to work with? (etcd-dev or github might be a better place to discuss though) We would love to hear and improve.
There are users we know successfully using it. If users are unhappy about the HTTP API, or it is too hard to use, we might consider to provide a native HTTP API.
Much of the focus on this release is continuing to support Kubernetes with the best possible consistency database. Xiang Li, one of the leads of etcd, included a couple of notes in his email to Kubernetes dev:
etcd v3.1 improves the read performance by a factor of 10 for Kuberentes use cases (unless quorum read is disabled).
etcd's v3 API will be the default backend in Kubernetes 1.6 release. But now you can also run Kuberentes 1.5 with etcd3 by providing `--storage-backend=etcd3` to the API server.
Tangentially, has anyone tried using etcd as a database for content?
etcd was obviously designed for consensus, coordination and discovery, but there seems to be nothing to prevent it from being perfectly adequate as a data store for other things. From what I can tell, it's pretty fast, strongly consistent, replicating, and has the building blocks to perform atomic transactions across multiple keys. It might work really well as the primary store of truth with something like Elasticsearch on top.
Hm. The first two are pre-3.x, and that issue (#2647) is closed, seemingly because everything has been implemented? Not seeing any huge limitations mentioned in 3 and 4.
The "small amounts of data" issue apparently no longer applies to 3.x, which now persists efficiently to disk.
Not sure what "bespoke" data storage means? 3.x has pluggable backends.
With that said, I feel really conflicted about v3. I understand why it was introduced and understand why it is objectively better than v2, however the reason I fell in love with etcd was because of v2. It was a simple, highly available, not very fast key store that exposed an easy way to view and traverse the store (via the /v2/keys API endpoint). Likewise, the client api was simple, quick to pickup and very easy to work with.
With v3, while the performance has increased dramatically (and many other things), the "ease" of etcd seems to have gone as well.
To this point, all of the software I've written that makes use of etcd is tied to etcd v2. Should I make a conscious effort to migrate to etcd v3? How much longer is v2 going to be kept around?