6dbbafdeb4
A few data migrations were added in the following module:
gbpservice/neutron/plugins/ml2plus/drivers/apic_aim/data_migrations.py
which reference tables defined in the corresponding DB models. However,
this opens up the possibility that those definitions might change via
migration scripts that get added after the data migration scripts in which
they are referenced. This leads to the situation that when the data
migration is run, sqlalchemy loads the newer table definition, but the DB
itself does not have the changes (defined in the schema migration that has not
yet run).
To get around this, instead of referencing the tables from the DB models,
the table defintion must be added to the data migration script itself and
referenced. This freezes the table definition that is expected by the data
migration script and ensures that the data migration script will work.
This patch updates the aforementioned data migration script to add the relevant
table definitions (based on the commit at the time those migrations were added).
It also eliminates the use of DB mixin methods to retrieve resources (which
can change over time and might include new attributes not available to this
migration).
A sanity UT is added for the Security Groups migration which did not have
UT coverage. The other data migrations are already being tested in UTs, but
to ensure that the older models are loaded (and the newer model defintions are not
referenced) some more UTs can be added as follow up.
Going forward, each data migration script should be contained in the alembic
migration script along with the table definitions that it uses. For reference
see how its done here:
625de54de3/neutron/db/migration/alembic_migrations/versions/newton/contract/3b935b28e7a0_migrate_to_pluggable_ipam.py
Change-Id: If7b74160a36b9946a7ab8de8c4c19fed2a87d850
Group Based Policy (GBP) provides declarative abstractions for achieving scalable intent-based infrastructure automation.
GBP complements the OpenStack networking model with the notion of policies that can be applied between groups of network endpoints. As users look beyond basic connectivity, richer network services with diverse implementations and network properties are naturally expressed as policies. Examples include service chaining, QoS, path properties, access control, etc.
GBP allows application administrators to express their networking requirements using a Group and a Policy Rules-Set abstraction. The specifics of policy rendering are left to the underlying pluggable policy driver.
GBP model also supports a redirect operation that makes it easy to abstract and consume complex network service chains and graphs.
Checkout the GBP wiki page for more detailed information: <http://wiki.openstack.org/GroupBasedPolicy>
The latest code is available at: <http://git.openstack.org/cgit/openstack/group-based-policy>.
GBP project management (blueprints, bugs) is done via Launchpad: <http://launchpad.net/group-based-policy>
For help using or hacking on GBP, you can send mail to <mailto:openstack-dev@lists.openstack.org>.
Acronyms used in code for brevity:
- PT: Policy Target
- PTG: Policy Target Group
- PR: Policy Rule
- PRS: Policy Rule Set
- L2P: L2 Policy
- L3P: L3 Policy
- NSP: Network Service Policy
- EP: External Policy
- ES: External Segment