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 <jaypi...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev