Open Stack

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.

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

-- 
Thierry Carrez (ttx)