d2a5c0f982
Implements blueprint nec-distribute-router Two types of neutron router will be supported: l3-agent and distributed. A type can be specified through "provider" attribute of a router. The naming of the attribute "provider" is intentional since I plan to support the service provider framework for router in the future and would like to make it easy to migrate. distributed router in NEC OpenFLow controller now does not support NAT, so l3-agent and distributed router coexists. To achieve it, l3-agent scheudler logic is modified in NEC plugin to exclude distributed routers from candidates of floating IP hosting routers. To support the above feature, the following related changes are done: - Adds a new driver to PFC driver which supports OpenFlow based router support in NEC OpenFlow products in PFlow v5. - Update ofc_client to extract detail error message from OpenFlow controller This commit also changes the following outside of NEC plugin: - Makes L3 agent notifiers configurable. l3-agent router and OpenFlow distributed router can coexist. Notication to l3-agent should be done only when routers are hosted by l3-agent, so we need custom L3 agent notifiers to filter non l3-agent routers. - Split test_agent_scheduler base class (in OVS plugin) into the base setup and testcases. By doing so we can implement custom testcases related to agent scheduler. Change-Id: I538201742950a61b92fb05c49a9256bc96ae9014
# 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 Neutron 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 Neutron's migration wrapper which uses the Alembic library to manage the migration. Neutron 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: $ neutron-db-manage --config-file /path/to/neutron.conf \ --config-file /path/to/plugin/config.ini stamp folsom You can then upgrade to the latest database version via: $ neutron-db-manage --config-file /path/to/neutron.conf \ --config-file /path/to/plugin/config.ini upgrade head To check the current database version: $ neutron-db-manage --config-file /path/to/neutron.conf \ --config-file /path/to/plugin/config.ini current To create a script to run the migration offline: $ neutron-db-manage --config-file /path/to/neutron.conf \ --config-file /path/to/plugin/config.ini upgrade head --sql To run the offline migration between specific migration versions: $ neutron-db-manage --config-file /path/to/neutron.conf \ --config-file /path/to/plugin/config.ini upgrade \ <start version>:<end version> --sql Upgrade the database incrementally: $ neutron-db-manage --config-file /path/to/neutron.conf \ --config-file /path/to/plugin/config.ini upgrade --delta <# of revs> Downgrade the database by a certain number of revisions: $ neutron-db-manage --config-file /path/to/neutron.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 Neutron 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 neutron-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. $ neutron-db-manage --config-file /path/to/neutron.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: $ neutron-db-manage --config-file /path/to/neutron.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: $ neutron-db-manage --config-file /path/to/neutron.conf \ --config-file /path/to/plugin/config.ini check_migration If the migration path does branch, you can find the branch point via: $ neutron-db-manage --config-file /path/to/neutron.conf \ --config-file /path/to/plugin/config.ini history