[openstack-dev] [oslo][devstack][all] ZooKeeper vs etcd for Tooz/DLM
jaypipes at gmail.com
Tue Mar 14 20:42:47 UTC 2017
On 03/14/2017 04:22 PM, Joshua Harlow wrote:
> Jay Pipes wrote:
>> On 03/14/2017 02:50 PM, Julien Danjou wrote:
>>> On Tue, Mar 14 2017, Jay Pipes wrote:
>>>> Not tooz, because I'm not interested in a DLM nor leader election
>>>> (that's what the underlying etcd3 cluster handles for me), only a
>>>> fast service
>>>> liveness/healthcheck system, but it shows usage of etcd3 and Google
>>>> Buffers implementing a simple API for liveness checking and host
>>> Cool cool. So that's the same feature that we implemented in tooz 3
>>> years ago. It's called "group membership". You create a group, make
>>> nodes join it, and you know who's dead/alive and get notified when their
>>> status change.
>> The point of os-lively is not to provide a thin API over ZooKeeper's
>> group membership interface. The point of os-lively is to remove the need
>> to have a database (RDBMS) record of a service in Nova.
>> tooz simply abstracts a group membership API across a number of drivers.
>> I don't need that. I need a way to maintain a service record (with
>> maintenance period information, region, and an evolvable data record
>> format) and query those service records in an RDBMS-like manner but
>> without the RDBMS being involved.
>>>> My plan is to push some proof-of-concept patches that replace Nova's
>>>> servicegroup API with os-lively and eliminate Nova's use of an RDBMS
>>>> service liveness checking, which should dramatically reduce the
>>>> amount of both
>>>> DB traffic as well as conductor/MQ service update traffic.
>>> Interesting. Joshua and Vilob tried to push usage of tooz group
>>> membership a couple of years ago, but it got nowhere. Well, no, they got
>>> 2 specs written IIRC:
>>> But then it died for whatever reasons on Nova side.
>> It died because it didn't actually solve a problem.
> Hmmm, idk about that, more likely other things involved, but point taken
> (and not meant personally).
That should have read "it died because it didn't actually solve *the*
problem". Meaning, the problem of having to store service and
maintenance information in the RDBMS. Sorry, I didn't mean that tooz
doesn't solve problems. That's not at all how I meant to come across!
>> The problem is that even if we incorporate tooz, we would still need to
>> have a service table in the RDBMS and continue to query it over and over
>> again in the scheduler and API nodes.
>> I want all service information in the same place, and I don't want to
>> use an RDBMS for that information. etcd3 provides an ideal place to
>> store service record information. Google Protocol Buffers is an ideal
>> data format for evolvable versioned objects. os-lively presents an API
>> that solves the problem I want to solve in Nova. tooz didn't.
> Def looks like u are doing some custom service indexes and such in etcd,
> so ya, the default in tooz may not fit that kind of specialized model
> (though I can't say such a model would be unique to nova).
> https://gist.github.com/harlowja/57394357e81703a595a15d6dd7c774eb was
> something I threw together, tooz may not be a perfect match, but still
> seems like it can evolve to store something like your indexes @
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev