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