On Nov 24, 2014, at 11:30 AM, Jay Pipes <jaypi...@gmail.com> wrote: > On 11/24/2014 10:43 AM, Mike Bayer wrote: >>> On Nov 24, 2014, at 9:23 AM, Adam Young <ayo...@redhat.com> wrote: >>> For pieces such as the Nova compute that talk almost exclusively on >>> the Queue, we should work to remove Monkey patching and use a clear >>> programming model. If we can do that within the context of >>> Eventlet, great. If we need to replace Eventlet with a different >>> model, it will be painful, but should be done. What is most >>> important is that we avoid doing hacks like we've had to do with >>> calls to Memcached and monkeypatching threading. >> >> Nova compute does a lot of relational database access and I’ve yet to >> see an explicit-async-compatible DBAPI other than psycopg2’s and >> Twisted abdbapi. Twisted adbapi appears just to throw regular >> DBAPIs into a thread pool in any case (see >> http://twistedmatrix.com/trac/browser/trunk/twisted/enterprise/adbapi.py), >> so given that awkwardness and lack of real async, if eventlet is >> dropped it would be best to use a thread pool for database-related >> methods directly. > > Hi Mike, > > Note that nova-compute does not do any direct database queries. All database > reads and writes actually occur over RPC APIs, via the conductor, either > directly over the conductor RPC API or indirectly via nova.objects. > > For the nova-api and nova-conductor services, however, yes, there is > direct-to-database communication that occurs, though the goal is to have only > the nova-conductor service eventually be the only service that directly > communicates with the database.
This is a good point. I’m not sure we can say “we’ll only use explicit/implicit async in certain cases" because most of our apps actually mix the cases. We have WSGI apps that send RPC messages and we have other apps that receive RPC messages and operate on the database. Can we mix explicit and implicit operating models, or are we going to have to pick one way? If we have to pick one, the implicit model we’re currently using seems more compatible with all of the various libraries and services we depend on, but maybe I’m wrong? Doug > > Best, > -jay > > > > _______________________________________________ > 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
