Open Stack

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



-- 
Davanum Srinivas :: https://twitter.com/dims