<div dir="ltr">I like where this is going!  Comment in-line.<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 4, 2018 at 8:53 AM 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">This thread is shifting a bit...<br>
<br>
I'd like to throw in another related idea we're talking about it...<br>
<br>
There is storing data in key/value stores and there is also storing data in document stores.<br>
<br>
Kubernetes uses a key/value store and builds a document store out of it. All its api then runs through a document store, not a key/value store.<br>
<br>
This model has proven to be quite powerful. I wonder if an abstraction over document stores would be useful? wrapping around k8s crds would be interesting. A lightweight openstack without mysql would have some interesting benifits.<br></blockquote><div><br></div><div>I suspect the code would largely be the same, if we support key/value then I would hope that then we could leverage all of that with just opening/connecting of the document store.  Perhaps this is worth some further investigation,  but ultimately what I've been thinking is if we _could_ allow some, not all, services to operate in completely decoupled fashion we better enable them to support OpenStack and neighboring technologies. Ironic is kind of the obvious starting point of sorts since everyone needs to start with some baremetal somewhere if they are are building their own infrastructure up.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Kevin<br>
________________________________________<br>
From: Bogdan Dobrelya [<a href="mailto:bdobreli@redhat.com" target="_blank">bdobreli@redhat.com</a>]<br>
Sent: Tuesday, December 04, 2018 6:29 AM<br>
To: <a href="mailto:openstack-discuss@lists.openstack.org" target="_blank">openstack-discuss@lists.openstack.org</a><br>
Subject: Re: [all][FEMDC] Etcd as DLM<br>
<br>
On 12/4/18 2:15 PM, Thierry Carrez wrote:<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>
> 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>
That's interesting, thank you! I'd like to remind though that Edge/Fog<br>
cases assume high latency, which is not the best fit for strongly<br>
consistent oslo.db data backends, like Etcd or Galera. Technically, it<br>
had been proved in the past a few years that only causal consistency,<br>
which is like eventual consistency but works much better for end users<br>
[0], is a way to go for Edge clouds. Except that there is *yet* a decent<br>
implementation exists of a causal consistent KVS!<br>
<br>
So my take is, if we'd ever want to redesign ORM transactions et al to<br>
CAS operations and KVS, it should be done not for Etcd in mind, but a<br>
future causal consistent solution.<br>
<br>
[0]<br>
<a href="https://www.usenix.org/system/files/login/articles/08_lloyd_41-43_online.pdf" rel="noreferrer" target="_blank">https://www.usenix.org/system/files/login/articles/08_lloyd_41-43_online.pdf</a><br>
<br>
--<br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<br>
<br>
<br>
</blockquote></div></div>