<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 4, 2018 at 5:53 AM Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/04/2018 08:15 AM, Thierry Carrez wrote:<br>
> Julia Kreger wrote:<br>
>> Indeed it is a considered a base service, but I'm unaware of why it <br>
>> was decided to not have any abstraction layer on top. That sort of <br>
>> defeats the adoption of tooz as a standard in the community. Plus with <br>
>> the rest of our code bases, we have a number of similar or identical <br>
>> patterns and it would be ideal to have a single library providing the <br>
>> overall interface for the purposes of consistency. Could you provide <br>
>> some more background on that decision?<br>
> <br>
> Dims can probably summarize it better than I can do.<br>
> <br>
> When we were discussing adding a DLM as a base service, we had a lot of <br>
> discussion at several events and on several threads weighing that option <br>
> (a "tooz-compatible DLM" vs. "etcd"). IIRC the final decision had to do <br>
> with leveraging specific etcd features vs. using the smallest common <br>
> denominator, while we expect everyone to be deploying etcd.<br>
> <br>
>> I guess what I'd really like to see is an oslo.db interface into etcd3.<br>
> <br>
> Not sure that is what you're looking for, but the concept of an oslo.db <br>
> interface to a key-value store was explored by a research team and the <br>
> FEMDC WG (Fog/Edge/Massively-distributed Clouds), in the context of <br>
> distributing Nova data around. Their ROME oslo.db driver PoC was using <br>
> Redis, but I think it could be adapted to use etcd quite easily.<br>
<br>
Note that it's not appropriate to replace *all* use of an RDBMS in <br>
OpenStack-land with etcd. I hope I wasn't misunderstood in my statement <br>
earlier.<br>
<br>
Just *some* use cases are better served by a key/value store, and <br>
etcd3's transactions and watches are a great tool for solving *some* use <br>
cases -- but definitely not all :)<br>
<br>
Anyway, just making sure nobody's going to accuse me of saying OpenStack <br>
should abandon all RDBMS use for a KVS. :)<br>
<br>
Best,<br>
-jay<br></blockquote><div><br></div><div>Definitely not interpreted that way and not what I was thinking either. I definitely see there is value, and your thoughts do greatly confirm that at least I'm not the only crazy person thinking it could be a good idea^(TM). </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Some pointers:<br>
> <br>
> <a href="https://github.com/beyondtheclouds/rome" rel="noreferrer" target="_blank">https://github.com/beyondtheclouds/rome</a><br>
> <br>
> <a href="https://www.openstack.org/videos/austin-2016/a-ring-to-rule-them-all-revising-openstack-internals-to-operate-massively-distributed-clouds" rel="noreferrer" target="_blank">https://www.openstack.org/videos/austin-2016/a-ring-to-rule-them-all-revising-openstack-internals-to-operate-massively-distributed-clouds</a> <br>
> <br>
> <br>
<br>
</blockquote></div></div>