Update.. So i just proposed a new library built off the [3] gist to be added to g-r and u-c.
https://review.openstack.org/#/c/450967/ The alternative was to add support for custom backends in etcd3 library itself with grpc and v3alpha HTTP API as implementations. Since tooz is already an abstraction and the work non-trivial we can start this way. If etcd3 ends up with supporting both, then we can just eliminate this library at that time. Thanks, Dims On Sun, Mar 19, 2017 at 4:34 PM, Davanum Srinivas <dava...@gmail.com> 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 <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 -- 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