Open Stack

On Nov 6, 2014, at 11:13 AM, Julien Danjou <julien at danjou.info> wrote:

> On Wed, Nov 05 2014, Davanum Srinivas wrote:
> 
>> Please see notes from Doug on the etherpad on why leaving it in
>> oslo.log or oslo.utils was not considered.
>> https://etherpad.openstack.org/p/kilo-oslo-library-proposals
> 
> I only get that it might be related to db at some point, but I only
> skimmed through the linked blueprint at it's not clear to me how that
> prevent this to be in oslo.utils for example. Sorry to be a pain. :)

The main reasons for splitting code into its own library are dependency management, API ownership, the logical separation of the contents of the library within the application stack and between other libraries, and review ACLs within gerrit.

We have a couple of libraries (oslo.log and oslo.messaging) that want to specify an API via the context base class, so the class can’t live in either of those places.

The utils library is actually used by some of the clients now, so we need to be conscious of adding dependencies there. I don’t think context will bring in any real dependencies for now, but it also doesn’t seem to be a general-purpose utility. We’re going to need to add some thread-local caches for setting and fetching the current context, I think, either within context or in some of the other libraries with callbacks invoked by the context constructor. So for logical separation, a different library seemed to make more sense.

It’s also possible that the applications will find other uses for a shared context base class, and so we’ll want to build a review team for it that isn’t limited to the oslo-core team, but that’s less important than the logical considerations in my mind.

Doug


> 
> -- 
> Julien Danjou
> -- Free Software hacker
> -- http://julien.danjou.info
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev