aboutsummaryrefslogtreecommitdiffstats
path: root/docs/architecture/architecture.rst
diff options
context:
space:
mode:
authorliamfallon <liam.fallon@est.tech>2019-05-30 20:53:05 +0000
committerPamela Dragosh <pdragosh@research.att.com>2019-06-03 16:29:29 +0000
commit21b8895270fdce164ba3a43e971cb4cc54cea098 (patch)
tree793d824916e657300f8731e540de712c927a69ff /docs/architecture/architecture.rst
parent8f61ace86baf3a42fc3bb39a82c3763ce2223781 (diff)
Design and Public API documentation completed.
The draw.io diagrams are in Gerrit. If the page is ever deleted, they will be lost. They ae now saved in XML format in gerrit. The design documentation links to the examples in github rather than quoting them in the document. General tidy up and cleaning of links, rewording, and reformatting of desgin document. Added missing diagram to the Design document. Updated and tidied up the internal PAP/PDP document. General improvement of documentation. Issue-ID: POLICY-1676 Change-Id: Ie5c9f32693f047beafe14a3e412a32cdf9ed6fde Signed-off-by: liamfallon <liam.fallon@est.tech> (cherry picked from commit 4d1d9830d51d3df59cadaa0ac9c9b004f2cb0d17)
Diffstat (limited to 'docs/architecture/architecture.rst')
-rw-r--r--docs/architecture/architecture.rst13
1 files changed, 7 insertions, 6 deletions
diff --git a/docs/architecture/architecture.rst b/docs/architecture/architecture.rst
index 727cb6c9..175bb20d 100644
--- a/docs/architecture/architecture.rst
+++ b/docs/architecture/architecture.rst
@@ -2,6 +2,7 @@
.. Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
+.. _architecture-label:
Architecture
############
@@ -94,7 +95,7 @@ of conflicts across all policies running in an ONAP installation.
The diagram below shows the architecture of the ONAP Policy Framework at its highest level.
-.. image:: images/highest.png
+.. image:: images/PFHighestLevel.svg
The *PolicyDevelopment* component implements the functionality for development of policy types and policies.
*PolicyAdministration* is responsible for the deployment life cycle of policies as well as interworking with the
@@ -113,7 +114,7 @@ with *PolicyAdministration*, *PolicyExecution* or any other run-time ONAP compon
The diagram below shows a more detailed view of the architecture, as inspired by
`RFC-2753 <https://tools.ietf.org/html/rfc2753>`__ and `RFC-3198 <https://tools.ietf.org/html/rfc3198>`__.
-.. image:: images/detailed.png
+.. image:: images/PFDesignAndAdmin.svg
*PolicyDevelopment* provides a `CRUD <https://en.wikipedia.org/wiki/Create,_read,_update_and_delete>`__ API for policy
types and policies. The policy types and policy artifacts and their metadata (Information about policies, policy types,
@@ -142,7 +143,7 @@ three APIs:
*PolicyExecution* is the set of running PDPs that are executing policies, logically partitioned into PDP groups and
subgroups.
-.. image:: images/execution.png
+.. image:: images/PolicyExecution.svg
The figure above shows how *PolicyExecution* looks at run time with PDPs running in Kubernetes. A *PDPGroup* is a purely
logical construct that collects all the PDPs that are running policies for a particular domain together. A *PDPSubGroup*
@@ -179,12 +180,12 @@ for :ref:`Policy Administration Point (PAP) Architecture <pap-label>`.
This section describes the structure of and relations between the main concepts in the Policy Framework. This model is
implemented as a common model and is used by *PolicyDevelopment*, *PolicyDeployment,* and *PolicyExecution.*
-.. image:: images/objectmodel1.png
+.. image:: images/ClassStructure.svg
The UML class diagram above shows the portion of the Policy Framework Object Model that applies to *PolicyDeployment*
and *PolicyExecution.*
-.. image:: images/objectmodel2.png
+.. image:: images/DesignTimeComponents.svg
The UML class diagram above shows the portion of the Policy Framework Object Model that applies to *PolicyDevelopment*
and *PolicyDeployment.*
@@ -498,7 +499,7 @@ On receipt or a shutdown request, the PDP completes or aborts any ongoing policy
Policy execution is the execution of a policy in a PDP. Policy enforcement occurs in the component that receives a
policy decision.
-.. image:: images/PolicyExecution.svg
+.. image:: images/PolicyExecutionFlow.svg
Policy execution can be *synchronous* or *asynchronous*. In *synchronous* policy execution, the component requesting a
policy decision requests a policy decision and waits for the result. The PDP-X and PDP-A implement synchronous policy