Open Stack

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
>>>> 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).

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 @
> 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
>
> __________________________________________________________________________
> 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