Open Stack

On Thu, Apr 6, 2017 at 7:08 PM, Doug Hellmann <doug at doughellmann.com> wrote:
> Excerpts from Emilien Macchi's message of 2017-04-06 18:17:59 -0400:
>> 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 :-)
>
> I can help from the Oslo side.

I've resurrected an old spec: https://review.openstack.org/#/c/243114/
- addressed some comments and put TODOs that Doug and I will work
together.
The target is set to Queens but we might provide some proof-of-concept
during Pike to make progress.
TripleO project is very interested by this feature and I'm pretty sure
other deployment tools might be too. Any feedback on the work here is
more than welcome!

Thanks,

> Doug
>
>>
>> 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
>> >
>>
>
> __________________________________________________________________________
> 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