e4bdcdd326
This change automatically creates a PTG per L2P. This PTG is created as a
reverse map of the "shadow" EPG that was already being created per L2P by
the apic_mapping policy driver.. We will henceforth refer to this PTG as
"auto" PTG.
The ID of the auto PTG is derived from the ID of the L2P as a MD5 hash
calculation (for uniqueness) and persisted in the format:
"auto<hash_of_l2p_id>". It is thus always possible to determine the ID of the
auto PTG from the ID of the L2P and no additional state needs to be maintained.
In order to maintain the reverse-mapping integrity between the shadow EPG and
the auto PTG, an entry is created in the apic name-mapping DB that maps the ID
of the auto PTG to the "apic-name" of the "shadow" EPG.
The initial name of the auto PTG is derived from the ID of the L2P to ease
debugging and troubleshooting, and takes the form: "auto-ptg-<l2p_id>". This
name is mutable (just like any other PTG). The apic_mapping driver does not
have any specical meaning for this name, and does not care about after it
implicitly sets it at the time of the auto PTG creation.
The auto PTG cannot be deleted by the end user and doing so will result in
an error.
The user can update the name, description, provided and consumed PRS for the
auto PTG, but cannot update any other attributes and doing so will result in
an error.
The shared status of the auto PTG is made consistent with the shared status
of the L2P (once set, it cannot be changed).
The auto PTG is deleted when the corresponding L2P is deleted (attempted in
the pre-commit phase).
To prevent forward mapping of the auto PTG to a new EPG, all above
operations are invoked on the GBP DB mixin (parent of the GBP plugin). This
ensures that the apic_mapping policy driver is not invoked for the create and
delete auto PTG operations during L2P creation and deletion.
The creation of the auto PTG is controlled by a configuration and is disabled
by default thus allowing this new feature to be turned ON only where needed.
All existing deployments should not see any change in behavior as long
as they choose not to turn ON this feature. This configuration is as follows:
[apic_mapping]
create_auto_ptg=<True or False>
As the commit title suggests, this is currently only a apic_mapping driver
specific feature. It may evolve to a GBP feature with a well defined auto PTG
attribute definition for the L2P (and/or accessor APIs). The convention used
for the Auto PTG name and the ID format could change as a part of this
evolution.
Change-Id: Ie132ace0fc9f78baa0034a6f30f2ee758bb271c0
(cherry picked from commit 6d56931196)
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