Open Stack

Also, I gave a stab at an etcd3 tooz coordination driver:

https://review.openstack.org/#/c/447223/

Can't figure out how to get the tests to run properly, but meh, I'll get 
to it in a bit :)

-jay

On 03/19/2017 04:34 PM, Davanum Srinivas wrote:
> Quick update: We have 3 options to talk to etcd:
>
> 1) existing V2 HTTP API - still not deprecated in etcd 3.1.x, so
> existing code in tooz still works.
> 2) grpc based V3 API - We can use the etcd3 package, discussion in
> review[1], problem is that this will not work currently with eventlet
> based services
> 3) v3alpha HTTP API - See details in [2], quick prototype requests
> based code [3]
>
> Thanks,
> Dims
>
> [1] https://review.openstack.org/#/c/446983/
> [2] https://github.com/coreos/etcd/blob/master/Documentation/dev-guide/api_grpc_gateway.md
> [3] https://gist.github.com/dims/19ceaf9472ef54aa3011d7a11e809371
>
> On Sun, Mar 19, 2017 at 9:32 AM, Jay Pipes <jaypipes at gmail.com> wrote:
>> On 03/18/2017 07:48 PM, Mike Perez wrote:
>>>
>>> On 12:35 Mar 14, Jay Pipes wrote:
>>>>
>>>> On 03/14/2017 08:57 AM, Julien Danjou wrote:
>>>>>
>>>>> On Tue, Mar 14 2017, Davanum Srinivas wrote:
>>>>>
>>>>>> Let's do it!! (etcd v2-v3 in tooz)
>>>>>
>>>>>
>>>>> Hehe. I'll move that higher in my priority list, I swear. But anyone is
>>>>> free to beat me to it in the meantime. ;)
>>>>
>>>>
>>>> A weekend experiment:
>>>>
>>>> https://github.com/jaypipes/os-lively
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>
>>>
>>> As Monty has mentioned, I'd love for us to decide on one thing. As being
>>> a moderator of that discussion I was trying not to be one-sided.
>>>
>>> Whether or not a decision was made 1.5 years ago, the community that was
>>> present at that time of the decision at the summit decided on an
>>> abstraction
>>> layer to have options. Forcing an option on the community without
>>> gathering
>>> feedback of what the community currently looks like is not a good idea.
>>>
>>> I'd recommend if you want to make this base service, start the discussions
>>> in
>>> somewhere other than the dev list, like the Forum.
>>
>>
>> Mike, it was an experiment :)
>>
>> But, yes, happy to participate in a discussion at the forum.
>>
>>
>> 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
>
>
>