On Nov 6, 2014, at 11:13 AM, Julien Danjou <jul...@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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to