8284bf9b3a
* use neutron_lib.directory for plugin retrieval * switch to neutron_lib for neutron constants, exceptions, extensions * add neutron.plugins.ml2.ovo_rpc to OUT_OF_PROCESS_NOTIFICATIONS: neutron added ovo rpc callback mechanism for ovo objects, and aim notification manager needs to recognize those as out of process. Since neutron moved away from get_session API to get_reader_session and get_writer_session, override for these was added. Few bugs were fixed in the delayed notification area as well. * new engine facade: make use of reader and writer to grab db engine * remove _update_fip_assoc override (didn't find a reason for the override) * aim driver: a fix in update_subnetpool_precommit - not to assume address_scope_id field is returned from neutron update call if it was not updated. * extend_XXX_dict call was switched to receive ovo instead of db object. As a result, foreign keys are not part of the object anymore, and need to be retrieved from db. * remove_router_interface - receive port dictinary rather than port object * fix patched neutron functions to receive correct parameter types (like patched_get_locked_port_and_binding) * use add_agent_status_check_worker instead of add_agent_status_check * advertise_mtu configuration parameter was removed from neutron. It is used in aim driver, hence added to aim driver config. * use of project_id instead of tenant_id where required * use segments_db module for network segments * test_aim_mapping_driver: the test used to override uuid generation in order to get predictable uuid results. New neutron code makes use of python uuid module where overrides are complicated. It was easire to remove all uuid-based values from dictionaries under test * add filters parameter to get_address_scopes calls, otherwise the call fails (probably should be fixed in neutron) * in routing tests, remove the assumption that routes are returned in specific order Change-Id: I1943fd4196ea6199d825ae53f0e9f5b54d54a260
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