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). From: Mark Washenberger <mark.washenber...@markwash.net<mailto:mark.washenber...@markwash.net>> Reply-To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, August 21, 2013 5:59 PM To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Oslo.db] Configuration options Josh thanks for highlighting this. This example is a good reason why oslo libraries should decouple their useful bits from any configuration assumptions. Much of the code already allows use without requiring you to adopt configuration code. But we should make all of it like that. On Wed, Aug 21, 2013 at 3:42 PM, Joshua Harlow <harlo...@yahoo-inc.com<mailto:harlo...@yahoo-inc.com>> wrote: Another question related to making oslo.db a pypi library and relevant to how taskflow is used. Currently taskflow has a persistence layer, its using a copy of oslo-incubator db module to do this. That copied code (soon to be library I hope) has the following: db_opts = [ cfg.StrOpt('backend', default='sqlalchemy', deprecated_name='db_backend', deprecated_group='DEFAULT', help='The backend to use for db'), cfg.BoolOpt('use_tpool', default=False, deprecated_name='dbapi_use_tpool', deprecated_group='DEFAULT', help='Enable the experimental use of thread pooling for ' 'all DB API calls') ] Now if oslo.db is a library, and taskflow and the integrated project want to use a database backend (potentially a different one) how would that be possible with a single library configuration? It would seem like the configuration done like this would not allow for that, and I could see taskflow having local sqlite as its backend (different DB config in this case, same backend), while the integrated project using mysql (for whatever its storing). Would something like that be possible? Thoughts?? -josh _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto: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
