Forbid invalid operations in expand, migrate, and contract repositories

[Dolph Mathews]

In the legacy migration repository, we've traditionally allowed any sort of database manipulation, including tables to be created, data to be migrated, columns to be dropped, etc. Recently, we introduced a constraint on those upgrades to prevent non-additive operations from occurring as a first step towards minimal downtime upgrades.

The 3 new repositories allow us to have zero downtime upgrades, but come with their own constraints that we should enforce via tests.

1. The expand repo should only be allowed to create tables, columns, indexes, and triggers. It should not be allowed to INSERT, UPDATE, or DELETE any data. It should not be allowed to drop tables, columns, indexes, or triggers.

1. The migrate repo should only be allowed to INSERT, UPDATE, and DELETE data. It should not be allowed to create or drop tables, columns, indexes, or triggers.

1. The contract repo should only be allowed to drop tables, columns, indexes, and triggers. It should not be allowed to INSERT, UPDATE, or DELETE any data. It should not be allowed to create tables, columns, indexes, or triggers.

[Dolph Mathews (dolph)]

Bug 1615014 and bug 1615020 also document new assertions regarding rolling upgrades.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/358723

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/358723
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=743e1102c83b41953b039ea02aa19534336797d6
Submitter: Jenkins
Branch: master

commit 743e1102c83b41953b039ea02aa19534336797d6
Author: Henry Nash <email address hidden>
Date: Sat Aug 20 11:57:30 2016 +0100

    Modify sql banned operations for each of the new repos

    This patch covers all the regular table and column operations
    across the four repos. It does not, however, check for triggers
    and indexes - which will be done in a separate patch.

    Limitations: Due to the fact that migrating versions causes an
    implicit table update (to increase the version number) we don't
    yet include checking agains inappropriate table updates of our
    own tables in the expand and data migration phases.

    Partial-Bug: #1615024
    Change-Id: Ia012c614b9a5b9af6b8bb447b39a9901caaf1fb5

[Lance Bragstad (lbragstad)]

Unassigning due to inactivity and so that if someone has the bandwidth to propose the rest of the fix they can.

[David Wilde (dave-wilde)]

I don't think this is relevant with the migration to alembic. Feel free to re-open if this is still an issue.