Include the URL of your launchpad blueprint:
The community currently supports MySQL and PostgreSQL production databases. Several other core projects already support DB2 (Keystone, Glance, Ceilometer, Heat). This blueprint adds support to Cinder for DB2 as a production database.
The changes required to enable Cinder to run on DB2 are limited given that Cinder’s database structure is not complicated. No changes are currently required to the migration scripts to enable deployment on a DB2 database.
Unit test will need to be updated to support running tests against a DB2 backend with the ibm_db_sa driver and all Cinder patches will be tested against a Tempest full run with 3rd party CI running DB2, maintained by IBM. Note that these 3rd Party CI runs have already been enabled for Cinder.
There is already code in Oslo’s db.api layer to support common function with DB2 like duplicate entry error handling and connection trace, so that is not part of this spec. Cinder, however, will need to sync up to the latest Oslo DB code to enable DB2 support.
Deployers can use other supported database backends like MySQL or PostgreSQL, but this may not be an ideal option for customers already running applications with DB2 that want to integrate with OpenStack. In addition, you could run other core projects with multiple schemas in a single DB2 OpenStack database, but you’d have to run Cinder separately which is a maintenance/configuration problem.
There are no impacts on the current Cinder data model. Any issues that arise due to future changes will be uncovered by the 3rd Party CI tests and will be able to be addressed at that point in time.
The one exception to this statement is in the unit test path. I made two commits in Icehouse to start implementing the infrastructure to enable DB2 unit testing. The commits were to add a bool_type dictionary (2a7b11922bd9389287915c45de92ca5eed3d448e) and a time_type dictionary (a9527de9ed3a2eae951564c3c74b7319113e8bf5). I will need to add the appropriate types for DB2, as was done for MySQL, as part of the unit test changes I will be making for DB2.
Execution of migration unit tests on DB2 may take longer than on other backend databases due to the time required to create the database schema. This impact, however, will only be seen when running unit tests for DB2.
There are no plans to migrate the Cinder database from a pre-existing installation (I.E. MySQL) to DB2. So deployers will need to be starting with a fresh Cinder installation to enable DB2 as a backend database.
The only impact on developers is if they are adding DB API code or migrations that don’t work with DB2, they will have to adjust those appropriately, just like we do today with MySQL and PostgreSQL. IBM ATCs would provide support/guidance on issues like this which require specific conditions for DB2, although for the most part, the DB2 InfoCenter provides adequate detail on how to work with the engine and provides details on error codes.
DB2 SQL error message explanations can be found here: http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/index.jsp?topic=%2Fcom.ibm.db2.luw.messages.sql.doc%2Fdoc%2Frsqlmsg.html
Information on developing with DB2 using python can be found here: http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/index.jsp?topic=%2Fcom.ibm.swg.im.dbclient.python.doc%2Fdoc%2Fc0054366.html
Main contacts for DB2 questions in OpenStack:
The install guides in the community do not go into specifics about setting up the database. The RHEL/Fedora install guide says to use the openstack-db script provided by openstack-utils in RDO which uses MySQL. The other install guides just say that SQLite3, MySQL and PostgreSQL are widely used databases. So for the install guides, those generic statements about supported databases would be updated to add DB2 to the list. Similar generic statements are also made in the following places which would be updated as well:
There are database topics in the security guide, so there would be DB2 considerations there as well, specifically: