It is important to show the overall philosophy of **GBP** as it sets the
project’s direction.
-In the Beryllium release of OpenDaylight, **GBP** focused on **expressed
+In this release of OpenDaylight, **GBP** focused on **expressed
intent**, **refactoring of how renderers consume and publish Subject
Feature Definitions for multi-renderer support**.
- Endpoints:
- Define concrete uniquely identifiable entities. In Beryllium,
+ Define concrete uniquely identifiable entities. In this release,
examples could be a Docker container, or a Neutron port
- EndpointGroups:
The *classifier* and *action* portions of the model can be thought of as
hooks, with their definition provided by each *renderer* about its
-domain specific capabilities. In **GBP** Beryllium, there is one
+domain specific capabilities. In **GBP** for this release, there is one
renderer, the *`OpenFlow Overlay renderer (OfOverlay). <#OfOverlay>`__*
These hooks are filled with *definitions* of the types of *features* the
looks as so:
.. figure:: ./images/groupbasedpolicy/GBP_High-levelBerylliumArchitecture.png
- :alt: GBP High Level Beryllium Architecture
+ :alt: GBP High Level Architecture
- GBP High Level Beryllium Architecture
+ GBP High Level Architecture
The major benefit of this architecture is that the mapping of the
domain-specific-language is completely separate and independent of the
can now be leveraged across NetConf devices simultaneously:
.. figure:: ./images/groupbasedpolicy/GBP_High-levelExtraRenderer.png
- :alt: GBP High Level Beryllium Architecture - adding a renderer
+ :alt: GBP High Level Architecture - adding a renderer
- GBP High Level Beryllium Architecture - adding a renderer
+ GBP High Level Architecture - adding a renderer
As other domain-specific mappings occur, they too can leverage the same
renderers, as the renderers only need to implement the **GBP** access
mapping to the access and forwarding models. For instance:
.. figure:: ./images/groupbasedpolicy/High-levelBerylliumArchitectureEvolution2.png
- :alt: GBP High Level Beryllium Architecture - adding a renderer
+ :alt: GBP High Level Architecture - adding a renderer
- GBP High Level Beryllium Architecture - adding a renderer
+ GBP High Level Architecture - adding a renderer
In summary, the **GBP** architecture:
- Consumer Endpoint Identification Constraint
- Label based criteria for matching against endpoints. In Beryllium
+ Label based criteria for matching against endpoints. In this release
this can be used to label endpoints based on IpPrefix.
The second category is the provider matchers, which match against the
- Consumer Endpoint Identification Constraint
- Label based criteria for matching against endpoints. In Beryllium
+ Label based criteria for matching against endpoints. In this release
this can be used to label endpoints based on IpPrefix.
Clauses have a list of subjects that apply when all the matchers in the
A DevStack demo environment can be found on the `**GBP**
wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`__.
+GBP Renderer manager
+--------------------
+
+Overview
+~~~~~~~~
+
+The GBP Renderer manager is an integral part of **GBP** base module.
+It dispatches information about endpoints'
+policy configuration to specific device renderer
+by writing a renderer policy configuration into the
+registered renderer's policy store.
+
+Installing and Pre-requisites
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Renderer manager is integrated into GBP base module,
+so no additional installation is required.
+
+Architecture
+~~~~~~~~~~~~
+
+Renderer manager gets data notifications about:
+
+- Endoints (base-endpoint.yang)
+
+- EndpointLocations (base-endpoint.yang)
+
+- ResolvedPolicies (resolved-policy.yang)
+
+- Forwarding (forwarding.yang)
+
+Based on data from notifications it creates a configuration task for
+specific renderers by writing a renderer policy configuration into the
+registered renderer's policy store.
+Configuration is stored to CONF data store as Renderers (renderer.yang).
+
+Configuration is signed with version number which is incremented by every change.
+All renderers are supposed to be on the same version. Renderer manager waits
+for all renderers to respond with version update in OPER data store.
+After a version of every renderer in OPER data store has the same value
+as the one in CONF data store,
+renderer manager moves to the next configuration with incremented version.
+
+GBP Location manager
+--------------------
+
+Overview
+~~~~~~~~
+
+Location manager monitors information about Endpoint Location providers
+(see endpoint-location-provider.yang) and manages Endpoint locations in OPER data store accordingly.
+
+Installing and Pre-requisites
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Location manager is integrated into GBP base module,
+so no additional installation is required.
+
+Architecture
+~~~~~~~~~~~~
+
+The endpoint-locations container in OPER data store (see base-endpoint.yang)
+contains two lists for two types of EP location,
+namely address-endpoint-location and containment-endpoint-location.
+LocationResolver is a class that processes Location providers in CONF data store
+and puts location information to OPER data store.
+
+When a new Location provider is created in CONF data store, its Address EP locations
+are being processed first, and their info is stored locally in accordance with processed
+Location provider's priority. Then a location of type "absolute" with the highest priority
+is selected for an EP, and is put in OPER data store. If Address EP locations contain
+locations of type "relative", those are put to OPER data store.
+
+If current Location provider contains Containment EP locations of type "relative",
+then those are put to OPER data store.
+
+Similarly, when a Location provider is deleted, information of its locations
+is removed from the OPER data store.
+
Using the GBP OpenFlow Overlay (OfOverlay) renderer
---------------------------------------------------
Demo/Development environment
----------------------------
-The **GBP** project for Beryllium has two demo/development environments.
+The **GBP** project for this release has two demo/development environments.
- Docker based GBP and GBP+SFC integration Vagrant environment
Code Review / docs.git / blobdiff