<div dir="ltr">I would like to slightly interrupt this train of thought for an unscheduled vision of the future!<div><br></div><div>What if we could allow a component to store data in etcd3's key value store like how we presently use oslo_db/sqlalchemy?</div><div><br></div><div>While I personally hope to have etcd3 as a DLM for ironic one day, review bandwidth permitting, it occurs to me that etcd3 could be leveraged for more than just DLM. If we have a common vision to enable data storage, I suspect it might help provide overall guidance as to how we want to interact with the service moving forward.</div><div><br></div><div>-Julia</div><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 3, 2018 at 2:52 PM Ben Nemec <<a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
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>