----- Original Message ----- > On 11/01/2013 12:33 PM, Clayton Coleman wrote: > > ----- Original Message ----- > >> > >> Once all the gitreview stuff is cleaned up I was going to do some purely > >> mechanical additions. > >> > >> I heard a few +1 for sqlalchemy with the standard OpenStack abstraction: > >> > >> solum/db/api.py > >> manager abstraction for db calls > >> solum/db/sqlalchemy/api.py > >> sqlalchemy implementation > >> > >> I was also going to throw in migrate as a dependency and put in the glue > >> code > >> for that based on common use from ironic/trove/heat. That'll pull in a > >> few > >> openstack common and config settings. Finally, was going to add a > >> solum-dbsync command a la the aforementioned projects. No schema will be > >> added. > >> > >> Objections? > >> > > > > I was blindly assuming we want to pull in eventlet support, with the > > implicit understanding that we will be doing some form of timeslicing and > > async io bound waiting in the API... but would like to hear others weigh > > in before I add the monkey_patch and stub code around script startup. > > I'm not so sure that bringing in eventlet should be done by default. It > adds complexity and if most/all of the API calls will be doing some call > to a native C library like libmysql that blocks, I'm not sure there is > going to be much benefit to using eventlet versus multiplexing the > servers using full OS processes -- either manually like some of the > projects do with the workers=N configuration and forking, or using more > traditional multiplexing solutions like running many mod_wsgi or uwsgi > workers inside Apache or nginx. >
What about callouts to heat/keystone APIs? _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
