[openstack-dev] [Oslo.db] Configuration options
Mark Washenberger
mark.washenberger at markwash.net
Thu Aug 22 00:59:28 UTC 2013
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 <harlowja at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130821/09ec3754/attachment.html>
More information about the OpenStack-dev
mailing list