Open Stack

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
>>> library
>>> (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
>>> Protocol
>>> Buffers implementing a simple API for liveness checking and host
>>> maintenance
>>> reporting.
>>
>> 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 for
>>> 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:
>>
>> https://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/service-group-using-tooz.html
>>
>>
>> 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).

>
> 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 @ 
https://github.com/jaypipes/os-lively/blob/master/os_lively/service.py#L524-L542 


>
> Best,
> -jay
>
> __________________________________________________________________________
> 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