Open Stack

On Apr 24, 2013, at 7:51 AM, Russell Bryant <rbryant at redhat.com> wrote:

> On 04/24/2013 10:40 AM, John Dickinson wrote:
>> I think both of your statements are wrong.
>> 
>> python-swiftclient (on of the swift project deliverables) uses oslo.
>> 
>> Our main issue with oslo is the current state of packaging it. Solve the current copy/paste code tree dance (something that is being worked on, I believe), and we'll be much more open to using oslo.
> 
> I don't think it's really something that needs to be solved.  It's
> already clearly defined.  Once the API is stable, it moves out of the
> incubator and into a library that you would consume like usual.  So to
> put it another way, Swift is interested in consuming Oslo libraries once
> they have left the incubator and have a stable API?

Yes, if they are libraries that can be installed and used (ie not inside the project codebase), then they become something that can be considered.

> 
> The oslo config library reached this point in the last cycle.  Do you
> have interest in migrating swift to use that?

That depends on a lot more than just "it's now a separate package". It also depends on what benefit it provides and any migration necessary for existing clusters. But these aren't concerns specific to oslo code--they are the same questions that must be answered for every change in the code or dependencies.

My (limited) understanding of the oslo config library is that there isn't a good migration path for existing deployments to move from the current config format to the format required by oslo config. This would need to be written in Swift, including config translators, so that both formats could be used, and I haven't seen yet a compelling benefit in oslo config that would adequately justify such a large change in the Swift codebase.

--John