Open Stack

On Wed, Mar 22, 2017 at 11:23 AM, Flavio Percoco <flavio at redhat.com> wrote:
> On 15/03/17 15:40 -0400, Doug Hellmann wrote:
>>
>> Excerpts from Monty Taylor's message of 2017-03-15 04:36:24 +0100:
>>>
>>> On 03/14/2017 06:04 PM, Davanum Srinivas wrote:
>>> > Team,
>>> >
>>> > So one more thing popped up again on IRC:
>>> > https://etherpad.openstack.org/p/oslo.config_etcd_backend
>>> >
>>> > What do you think? interested in this work?
>>> >
>>> > Thanks,
>>> > Dims
>>> >
>>> > PS: Between this thread and the other one about Tooz/DLM and
>>> > os-lively, we can probably make a good case to add etcd as a base
>>> > always-on service.
>>>
>>> As I mentioned in the other thread, there was specific and strong
>>> anti-etcd sentiment in Tokyo which is why we decided to use an
>>> abstraction. I continue to be in favor of us having one known service in
>>> this space, but I do think that it's important to revisit that decision
>>> fully and in context of the concerns that were raised when we tried to
>>> pick one last time.
>>>
>>> It's worth noting that there is nothing particularly etcd-ish about
>>> storing config that couldn't also be done with zk and thus just be an
>>> additional api call or two added to Tooz with etcd and zk drivers for it.
>>>
>>
>> The fun* thing about working with these libraries is managing the
>> interdependencies. If we're going to have an abstraction library that
>> provides configuration options for seeing the backend, like we do in
>> oslo.db and olso.messaging, then the configuration library can't use it
>> or we have a circular dependency.
>>
>> Luckily, tooz does not currently use oslo.config. So, oslo.config could
>> use tooz and we could create an oslo.dlm library with a shallow
>> interface mapping config options to tooz calls to open connections or
>> whatever we need from tooz in an application. Then apps could use
>> oslo.dlm instead of calling into tooz directly and the configuration of
>> the backend would be hidden from the application developer.
>
>
> Replying here becasue I like the proposal, I like what Monty said and I also
> like what Doug said. Most of the issues and concerns have been covered in
> this
> thread and I don't have much else to add other than +1.

The one-million-dollar question now is: what are the next steps?
It sounds like an oslo spec would be nice to summarize the ideas here
and talk about design.

I volunteer to help but I would need someone more familiar than I am with Oslo.
Please let me know if you're interested to work on it with me
otherwise I'll chase chase some of you :-)

Thanks for the nice discussions here, I think we've made good progress.

>> Doug
>>
>> * your definition of "fun" may be different than mine
>
>
> Which is probably different than mine :)
>
> --
> @flaper87
> Flavio Percoco
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Emilien Macchi