vmware-nsx/quantum/db/migration
Akihiro MOTOKI c3fd3feba6 plugin/nec: Make sure resources on OFC is globally unique.
Fixes bug 1127664

Network cannot be created in NEC plugin when OFC network ID is
unique inside a tenant. Some OFC implmenetations generate a network
ID unique inside a tenant. In this case generated network IDs on can
be duplicated in system-wide. To fix it, this changes resource ID on
OFC to REST URI to make sure IDs on OFC globally unique.

Fixes bug 1120962

Make sure NEC plugin creates shared networks

In Quantum resource relationship is not limited inside a tenant.
E.g., a non-owner tenant can create a port on a shared network.
To deal with it the provider layer should not be aware of tenants
each resource belongs to even when it has a kind of tenant concept.

This commit changes ofc_manager to pass a parent resource for resource
creation and identify a resouce by REST URI used to access OFC resources.
It decouples Quantum resource access model from OFC resource models.
OFC IDs created before this commit are also looked up.

Primary keys of OFC ID mapping tables are changed to quantum_id because
most of all accesses to these mapping tables are done by quantum_id.
However the current version of alembic does not support changing primary
keys, so new OFC ID mapping tables for tenant, network, port and packet
filter are created. Dropping the previous mapping tables will be done
along with the data migration logic.

This commit also changes the following minor issues.
- Make sure ID on ProgrammableFlow OpenFlow controller (PFC) is less than
  32 chars. The current PFC accepts only 31 chars max as ID and 127 chars
  as a description string.
- Some database accesses created their own session and did not support
  subtransactions. Make sure to use context.session passed from the API layer.
- Removes Unused methods (update_network, update_port) in trema/pfc drivers.

Change-Id: Ib4bb830e5f537c789974fa7b77f06eaeacb65333
2013-02-18 17:40:35 +09:00
..
alembic_migrations plugin/nec: Make sure resources on OFC is globally unique. 2013-02-18 17:40:35 +09:00
__init__.py Add migration support to Quantum 2013-01-07 17:21:27 -08:00
alembic.ini Add migration support to Quantum 2013-01-07 17:21:27 -08:00
cli.py Use oslo-config-2013.1b3 2013-02-17 17:33:05 +00:00
README Add migration support to Quantum 2013-01-07 17:21:27 -08:00

# vim: tabstop=4 shiftwidth=4 softtabstop=4
#
# Copyright 2012 New Dream Network, LLC (DreamHost)
#
#    Licensed under the Apache License, Version 2.0 (the "License"); you may
#    not use this file except in compliance with the License. You may obtain
#    a copy of the License at
#
#         http://www.apache.org/licenses/LICENSE-2.0
#
#    Unless required by applicable law or agreed to in writing, software
#    distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
#    WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
#    License for the specific language governing permissions and limitations
#    under the License.
#
# @author Mark McClain (DreamHost)

The migrations in the alembic/versions contain the changes needed to migrate
from older Quantum releases to newer versions. A migration occurs by executing
a script that details the changes needed to upgrade/downgrade the database. The
migration scripts are ordered so that multiple scripts can run sequentially to
update the database. The scripts are executed by Quantum's migration wrapper
which uses the Alembic library to manage the migration.  Quantum supports
migration from Folsom or later.


If you are a deployer or developer and want to migrate from Folsom to Grizzly
or later you must first add version tracking to the database:

$ quantum-db-manage -config-file /path/to/quantum.conf \
 --config-file /path/to/plugin/config.ini stamp folsom

You can then upgrade to the latest database version via:
$ quantum-db-manage --config-file /path/to/quantum.conf \
 --config-file /path/to/plugin/config.ini upgrade head

To check the current database version:
$ quantum-db-manage --config-file /path/to/quantum.conf \
 --config-file /path/to/plugin/config.ini current

To create a script to run the migration offline:
$ quantum-db-manage --config-file /path/to/quantum.conf \
 --config-file /path/to/plugin/config.ini upgrade head --sql

To run the offline migration between specific migration versions:
$ quantum-db-manage --config-file /path/to/quantum.conf \
--config-file /path/to/plugin/config.ini upgrade \
<start version>:<end version> --sql

Upgrade the database incrementally:
$ quantum-db-manage --config-file /path/to/quantum.conf \
--config-file /path/to/plugin/config.ini upgrade --delta <# of revs>

Downgrade the database by a certain number of revisions:
$ quantum-db-manage --config-file /path/to/quantum.conf \
--config-file /path/to/plugin/config.ini downgrade --delta <# of revs>


DEVELOPERS:
A database migration script is required when you submit a change to Quantum
that alters the database model definition.  The migration script is a special
python file that includes code to update/downgrade the database to match the
changes in the model definition. Alembic will execute these scripts in order to
provide a linear migration path between revision. The quantum-db-manage command
can be used to generate migration template for you to complete.  The operations
in the template are those supported by the Alembic migration library.

$ quantum-db-manage --config-file /path/to/quantum.conf \
--config-file /path/to/plugin/config.ini revision \
-m "description of revision" \
--autogenerate

This generates a prepopulated template with the changes needed to match the
database state with the models.  You should inspect the autogenerated template
to ensure that the proper models have been altered.

In rare circumstances, you may want to start with an empty migration template
and manually author the changes necessary for an upgrade/downgrade.  You can
create a blank file via:

$ quantum-db-manage --config-file /path/to/quantum.conf \
--config-file /path/to/plugin/config.ini revision \
-m "description of revision"

The migration timeline should remain linear so that there is a clear path when
upgrading/downgrading.  To verify that the timeline does branch, you can run
this command:
$ quantum-db-manage --config-file /path/to/quantum.conf \
--config-file /path/to/plugin/config.ini check_migration

If the migration path does branch, you can find the branch point via:
$ quantum-db-manage --config-file /path/to/quantum.conf \
--config-file /path/to/plugin/config.ini history