On 12/02/13 at 09:08am, Russell Bryant wrote:
On 12/02/2013 09:02 AM, Victor Sergeyev wrote:
Hi folks!

At the moment I and Roman Podoliaka are working on splitting of
openstack.common.db code into a separate library. And it would be nice
to drop dependency on eventlet before oslo.db is released.

Currently, there is only one place in oslo.db where we use eventlet -
wrapping of DB API method calls to be executed by tpool threads. It
wraps DB API calls to be executed by tpool threads. This is only needed
when eventlet is used together with DB-API driver implemented as a
Python C extension (eventlet can't monkey patch C code, so we end up
with DB API calls blocking all green threads when using Python-MySQLdb).
eventlet has a workaround known as 'tpool' which is basically a pool of
real OS threads that can play nicely with eventlet event loop. tpool
feature is experimental and known to have stability problems. There is a
doubt that anyone is using it in production at all. Nova API (and
probably other API services) has an option to prefork the process on
start, so that they don't need to use tpool when using eventlet together
Python-MySQLdb.

We'd really like to drop tpool support from oslo.db, because as a
library we should not be bound to any particular concurrency model. If a
target project is using eventlet, we believe, it is its problem how to
make it play nicely with Python-MySQLdb lib, but not the problem of
oslo.db. Though, we could put tpool wrapper into another helper module
within oslo-incubator.

But we would really-really like not to have any eventlet related code in
oslo.db.

Are you using CONF.database.use_tpool in production? Does the approach
with a separate tpool wrapper class seem reasonable? Or we can just drop
tpool support at all, if no one is using it?

Please don't remove it completely.  Putting it in oslo-incubator for now
seems fine, though.

+1. We are using it in production, though only in certain places because it does have stability issues that we'd like to track down and fix.


--
Russell Bryant

_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to