<div dir="ltr"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 17, 2019 at 10:37 AM Ben Nemec <<a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This thread got a bit sidetracked with potential use-cases for etcd3 <br>
(which seems to happen a lot with this topic...), but we still need to <br>
decide how we're going to actually communicate with etcd from OpenStack <br>
services. Does anyone have input on that?<br></blockquote><div><br></div><div>I have been successful testing the cinder-volume service using etcd3-gateway [1] to access etcd3 via tooz.coordination. Work great, although I haven't stress tested the setup.<br></div><div><br></div><div>[1] <a href="https://github.com/dims/etcd3-gateway">https://github.com/dims/etcd3-gateway</a><br></div><div><br></div><div>Alan</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks.<br>
<br>
-Ben<br>
<br>
On 12/3/18 4:48 PM, Ben Nemec wrote:<br>
> Hi,<br>
> <br>
> I wanted to revisit this topic because it has come up in some downstream <br>
> discussions around Cinder A/A HA and the last time we talked about it <br>
> upstream was a year and a half ago[1]. There have certainly been changes <br>
> since then so I think it's worth another look. For context, the <br>
> conclusion of that session was:<br>
> <br>
> "Let's use etcd 3.x in the devstack CI, projects that are eventlet based <br>
> an use the etcd v3 http experimental API and those that don't can use <br>
> the etcd v3 gRPC API. Dims will submit a patch to tooz for the new <br>
> driver with v3 http experimental API. Projects should feel free to use <br>
> the DLM based on tooz+etcd3 from now on. Others projects can figure out <br>
> other use cases for etcd3."<br>
> <br>
> The main question that has come up is whether this is still the best <br>
> practice or if we should revisit the preferred drivers for etcd. Gorka <br>
> has gotten the grpc-based driver working in a Cinder driver that needs <br>
> etcd[2], so there's a question as to whether we still need the HTTP <br>
> etcd-gateway or if everything should use grpc. I will admit I'm nervous <br>
> about trying to juggle eventlet and grpc, but if it works then my only <br>
> argument is general misgivings about doing anything clever that involves <br>
> eventlet. :-)<br>
> <br>
> It looks like the HTTP API for etcd has moved out of experimental <br>
> status[3] at this point, so that's no longer an issue. There was some <br>
> vague concern from a downstream packaging perspective that the grpc <br>
> library might use a funky build system, whereas the etcd3-gateway <br>
> library only depends on existing OpenStack requirements.<br>
> <br>
> On the other hand, I don't know how much of a hassle it is to deploy and <br>
> manage a grpc-gateway. I'm kind of hoping someone has already been down <br>
> this road and can advise about what they found.<br>
> <br>
> Thanks.<br>
> <br>
> -Ben<br>
> <br>
> 1: <a href="https://etherpad.openstack.org/p/BOS-etcd-base-service" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/BOS-etcd-base-service</a><br>
> 2: <br>
> <a href="https://github.com/embercsi/ember-csi/blob/5bd4dffe9107bc906d14a45cd819d9a659c19047/ember_csi/ember_csi.py#L1106-L1111" rel="noreferrer" target="_blank">https://github.com/embercsi/ember-csi/blob/5bd4dffe9107bc906d14a45cd819d9a659c19047/ember_csi/ember_csi.py#L1106-L1111</a> <br>
> <br>
> 3: <a href="https://github.com/grpc-ecosystem/grpc-gateway" rel="noreferrer" target="_blank">https://github.com/grpc-ecosystem/grpc-gateway</a><br>
<br>
</blockquote></div></div></div>