[openstack-dev] [all] etcd3 as base service - update

Joshua Harlow harlowja at fastmail.com
Fri Jun 9 04:37:16 UTC 2017

Julien Danjou wrote:
> On Thu, Jun 08 2017, Mike Bayer wrote:
>> So far I've seen a proposal of etcd3 as a replacement for memcached in
>> keystone, and a new dogpile connector was added to oslo.cache to handle
>> referring to etcd3 as a cache backend.  This is a really simplistic / minimal
>> kind of use case for a key-store.
> etcd3 is not meant to be a cache. Synchronizing caching value using the
> Raft protocol sounds a bit overkill. A cluster of memcached would be
> probably of a better use.

Agreed from me,

My thinking is that people should look over https://raft.github.io/ or 
http://thesecretlivesofdata.com/raft/ (or both or others...)

At least read how it sort of works, before trying to put it everywhere 
(the same can and should be said for any new service), because its not a 
solution for all the things.

The other big thing to know is how writes happen in this kind of system, 
they all go through a single node (the leader, who sends the same data 
to followers and waits for a certain number of followers to respond 
before committing)....

Anyways, with great power comes great responsibility...

IMHO just be careful and understand the technology before using it for 
things it may not really be good for. Oh ya and perhaps someone will 
want to finally take more advantage of 
https://docs.openstack.org/developer/taskflow/jobs.html#overview (which 
uses the same concepts etcd exposes to make highly available workflows 
that can survive node failure).

>> But, keeping in mind I don't know anything about etcd3 other than "it's another
>> key-store", it's the only database used by Kubernetes as a whole, which
>> suggests it's doing a better job than Redis in terms of "durable".
> Not sure about that. And Redis has much more data structure than etcd,
> that is can be faster/more efficient than etcd. But it does not have
> Raft and a synchronisation protocol. Its clustering is rather poor in
> comparison of etcd.
>> So I wouldn't be surprised if new / existing openstack applications
>> express some gravitational pull towards using it as their own
>> datastore as well. I'll be trying to hang onto the etcd3 track as much
>> as possible so that if/when that happens I still have a job :).
> Sounds like a recipe for disaster. :)
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list