<div dir="ltr">Indeed it is a considered a base service, but I'm unaware of why it was decided to not have any abstraction layer on top. That sort of defeats the adoption of tooz as a standard in the community. Plus with the rest of our code bases, we have a number of similar or identical patterns and it would be ideal to have a single library providing the overall interface for the purposes of consistency. Could you provide some more background on that decision?<div><br></div><div>I guess what I'd really like to see is an oslo.db interface into etcd3.<br><div><br></div><div>-Julia<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 3, 2018 at 4:55 PM Fox, Kevin M <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">It is a full base service already:<br>
<a href="https://governance.openstack.org/tc/reference/base-services.html" target="_blank">https://governance.openstack.org/tc/reference/base-services.html</a><br>
<br>
Projects have been free to use it for quite some time. I'm not sure if any actually are yet though.<br>
<br>
It was decided not to put an abstraction layer on top as its pretty simple and commonly deployed.<br>
<br>
Thanks,<br>
Kevin<br>
<div style="font-family:Times New Roman;color:#000000;font-size:16px">
<hr>
<div id="m_-723792725246985153divRpF188034" style="direction:ltr"><font size="2" face="Tahoma" color="#000000"><b>From:</b> Julia Kreger [<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a>]<br>
<b>Sent:</b> Monday, December 03, 2018 3:53 PM<br>
<b>To:</b> Ben Nemec<br>
<b>Cc:</b> Davanum Srinivas; <a href="mailto:geguileo@redhat.com" target="_blank">geguileo@redhat.com</a>; <a href="mailto:openstack-discuss@lists.openstack.org" target="_blank">openstack-discuss@lists.openstack.org</a><br>
<b>Subject:</b> Re: [all] Etcd as DLM<br>
</font><br>
</div>
<div></div>
<div>
<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" rel="noopener noreferrer" target="_blank">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>
</div>
</div>
</div>
</div>

</blockquote></div></div></div></div>