On 12/04/2018 08:15 AM, Thierry Carrez wrote:
Julia Kreger wrote:
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?
Dims can probably summarize it better than I can do.
When we were discussing adding a DLM as a base service, we had a lot of discussion at several events and on several threads weighing that option (a "tooz-compatible DLM" vs. "etcd"). IIRC the final decision had to do with leveraging specific etcd features vs. using the smallest common denominator, while we expect everyone to be deploying etcd.
I guess what I'd really like to see is an oslo.db interface into etcd3.
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.
Note that it's not appropriate to replace *all* use of an RDBMS in OpenStack-land with etcd. I hope I wasn't misunderstood in my statement earlier. Just *some* use cases are better served by a key/value store, and etcd3's transactions and watches are a great tool for solving *some* use cases -- but definitely not all :) Anyway, just making sure nobody's going to accuse me of saying OpenStack should abandon all RDBMS use for a KVS. :) Best, -jay
Some pointers:
https://github.com/beyondtheclouds/rome
https://www.openstack.org/videos/austin-2016/a-ring-to-rule-them-all-revisin...