Bug 1041083

Summary:	[RFE][nova]: Direct MySQLdb implementation
Product:	Red Hat OpenStack	Reporter:	RHOS Integration <rhos-integ>
Component:	RFEs	Assignee:	RHOS Maint <rhos-maint>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	markmc, yeylon
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
URL:	https://blueprints.launchpad.net/nova/+spec/db-mysqldb-impl
Whiteboard:	upstream_milestone_none upstream_status_started upstream_definition_drafting
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-19 17:44:43 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description RHOS Integration 2013-12-12 13:35:40 UTC

Cloned from launchpad blueprint https://blueprints.launchpad.net/nova/+spec/db-mysqldb-impl.

Description:

With the move of all DB calls for nova-compute going to nova-conductor, it becomes important to have efficient DB calls that do not block the whole python process.  It's been found that:

1) sqlalchemy calls are tremendously slower than using direct calls with mysqldb.  Even when using more low level sqlalchemy calls without ORM, this is true.
2) Using eventlet.tpool with sqlalchemy falls down.  sqlalchemy is doing something that is exercising bugs with eventlet.tpool or is doing something incompatible.  We end up in a state where the whole process is hung for reasons that are not extremely easy to track down.  Even if tpool worked with sqlalchemy, the improvements by using MySQLdb directly are significant enough to provide it as an implementation option.

See: http://paste.openstack.org/show/31019/

The goal here will be to implement DB api calls 1 by 1, falling back to sqlalchemy for methods not implemented yet.

Specification URL (additional information):

None