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-revisin... -- Thierry Carrez (ttx)