[Openstack-operators] [openstack-dev] [Olso][DB] Remove eventlet from oslo.db

Russell Bryant rbryant at redhat.com
Mon Dec 2 14:08:04 UTC 2013

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.

Russell Bryant

More information about the OpenStack-operators mailing list