sqlalchemy failures when using multi-backend

[Eric Harney]

I'm encountering failures on master when configuring multi-backend. I hit this repeatedly at c-vol startup when configuring 4 rbd backends on Fedora 20.

Errors indicate various failures in sqlalchemy communicating with the SQL server. These are two common examples:

2015-03-11 11:25:05.361 TRACE cinder.openstack.common.threadgroup DBError: This result object does not return rows. It has been closed automatically.

2015-03-11 11:30:52.038 TRACE cinder DBConnectionError: (OperationalError) (2013, 'Lost connection to MySQL server during query')

From what I can tell, this was introduced by:
6879bd0 NFS Security Enhancements: allows secure NFS environment setup

The reason it breaks things is that before, we didn't use the database before passing self.db to import_object(volume_driver, ..., db=self.db, ...), so the driver must have gotten a new connection initialized. However, since we now use the database before that call, the volume manager and driver end up both trying to use the same sqlalchemy object/connection, which is not safe.

We need to ensure each backend gets a clean object/connection to work with.

[Eric Harney (eharney)]

To verify that the noted change causes this, just set "vol_db_empty = False" in VolumeManager's __init__ and see that the failure doesn't occur.

[Mike Bayer (zzzeek)]

this is a well known error which is described fully at https://bugs.launchpad.net/oslo.db/+bug/1417018. the fixes are known but to my knowledge there was still some debate over what steps to take.

[Mike Bayer (zzzeek)]

I'd like to mark as a dupe, Eric can you please confirm for me, thanks!

[Eric Harney (eharney)]

Oops, lost track of the other bug, thanks. :)