Thx mark, good to know this happens before it is librarized. Is there any place where these common set of refactoring tasks is written down (so that info can be referred to instead of a question on the mailing list)?
Sent from my really tiny device... On Aug 21, 2013, at 10:20 PM, "Mark McLoughlin" <mar...@redhat.com> wrote: > On Thu, 2013-08-22 at 01:14 +0000, Joshua Harlow wrote: >> Agreed, any thoughts from the oslo folks on how this could be done >> (without a major refactoring??). Can it even be done? >> >> It will be a continuous problem for libraries which want to be >> integrated with the various openstack projects, especially if those >> libraries use oslo code, since there is now a weird 'action at a >> distance' on config shared between the project and the library. To me >> this is one of the pain points in a global CFG object, maybe for >> things that oslo will 'librarize' those libraries should not have a >> strong coupling to said global CFG but should prefer a local config >> 'object' to be passed in (of which the project using the oslo library >> can by default pass in the global CFG object to it, if the project >> desires to use it this way). > > Take a look at the oslo.messaging API: > > http://docs.openstack.org/developer/oslo.messaging/transport.html > > See? No dependence on a global config object. And the ability to connect > to alternate brokers via a transport_url. > > So, yes - moving any API out of oslo-incubator into a standalone library > is all about cleaning up issues like this. > > Mark. > > > _______________________________________________ > 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
