Open Stack

I like where this is going!  Comment in-line.

On Tue, Dec 4, 2018 at 8:53 AM Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:

> This thread is shifting a bit...
>
> I'd like to throw in another related idea we're talking about it...
>
> There is storing data in key/value stores and there is also storing data
> in document stores.
>
> 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.
>
> 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.
>

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.

>
> Thanks,
> Kevin
> ________________________________________
> From: Bogdan Dobrelya [bdobreli at redhat.com]
> Sent: Tuesday, December 04, 2018 6:29 AM
> To: openstack-discuss at lists.openstack.org
> Subject: Re: [all][FEMDC] Etcd as DLM
>
> On 12/4/18 2:15 PM, Thierry Carrez wrote:
> > Not sure that is what you're looking for, but the concept of an oslo.db
> > interface to a key-value store was explored by a research team and the
> > FEMDC WG (Fog/Edge/Massively-distributed Clouds), in the context of
> > distributing Nova data around. Their ROME oslo.db driver PoC was using
> > Redis, but I think it could be adapted to use etcd quite easily.
> >
> > Some pointers:
> >
> > https://github.com/beyondtheclouds/rome
> >
> >
> https://www.openstack.org/videos/austin-2016/a-ring-to-rule-them-all-revising-openstack-internals-to-operate-massively-distributed-clouds
>
> That's interesting, thank you! I'd like to remind though that Edge/Fog
> cases assume high latency, which is not the best fit for strongly
> consistent oslo.db data backends, like Etcd or Galera. Technically, it
> had been proved in the past a few years that only causal consistency,
> which is like eventual consistency but works much better for end users
> [0], is a way to go for Edge clouds. Except that there is *yet* a decent
> implementation exists of a causal consistent KVS!
>
> So my take is, if we'd ever want to redesign ORM transactions et al to
> CAS operations and KVS, it should be done not for Etcd in mind, but a
> future causal consistent solution.
>
> [0]
>
> https://www.usenix.org/system/files/login/articles/08_lloyd_41-43_online.pdf
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20181204/c045a683/attachment-0001.html>