Comment 2 for bug 1641609

It's not Nova specific, actually the problem is the same for *all* OpenStack projects: MySQL does not support transactional DDL (i.e. each DDL statement like CREATE TABLE will implicitly issue a COMMIT ending the ongoing DB transaction, so that one can no longer ROLLBACK all the previous changes in case of errors) - if application of migration scripts fails in the middle for whatever reason (e.g. "2006 mysql server has gone away") - the DB is potentially left in inconsistent state: e.g. migration scripts actions might have already been performed (e.g. tables might have been created), but the schema version number hasn't been updated yet - next time you run migration scripts alembic or sqlalchemy-migrate will try to execute the very same script potentially trying to create tables that already exist.

While the best solution is to have transactional DDL to make sure the DB is always in consistent state in case of errors, it does not look like it will happen anytime soon (PostgreSQL supports it, but MySQL Galera is one of the corner stones of MOS reference architecture).

We could try to patch all the existing migration scripts in OpenStack to add conditions to DDL statements (like CREATE TABLE IF NOT EXISTS), but that's going to be a cross-project effort, which is potentially error-prone.

FWIW, I do not think the problem is that severe: all new migration scripts are usually written with conditional statements to ensure they are idempotent even in absence of support from RDBMS side (at least in Nova), so this should mitigate problems on upgrade of the existing schema. And for new deployments, one can always drop the existing schema completely (as it's empty - there no rows in tables yet) and re-create if from scratch by the means of migration scripts.

The bottom line is, I see this as a valid request for improvement, but not as a severe issue.