summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorLF Jenkins CI <releng+lf-jobbuilder@linuxfoundation.org>2020-04-08 20:22:03 +0000
committerLF Jenkins CI <releng+lf-jobbuilder@linuxfoundation.org>2020-04-08 20:22:07 +0000
commit7a34e0dbfbeb3a0387e53c6b95869376a0fa000a (patch)
tree18a28b7efcad80742d08fe4049e610987fae4896
parent0da43614201d33e1161e47f0de7308d1ec0e4bcd (diff)
Automation adds policy-engine-architecture.rst
Issue-ID: CIMAN-376 Change-Id: I8079f4dee4b5b1e9ffd643f1c97eb01c8c675055 Signed-off-by: lf-jobbuilder <releng+lf-jobbuilder@linuxfoundation.org>
-rw-r--r--docs/platform/architecture.rst15
1 files changed, 8 insertions, 7 deletions
diff --git a/docs/platform/architecture.rst b/docs/platform/architecture.rst
index 19f774c65..2eb3e88f0 100644
--- a/docs/platform/architecture.rst
+++ b/docs/platform/architecture.rst
@@ -1,6 +1,7 @@
.. This work is licensed under a
.. Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
+.. _architecture:
Architecture
@@ -10,7 +11,7 @@ Architecture
:depth: 3
POLICY is a subsystem of ONAP that maintains, distributes, and operates on the
-set of rules that underlie ONAP’s control, orchestration, and management
+set of rules that underlie ONAP's control, orchestration, and management
functions.
POLICY provides a logically centralized environment for the creation and
@@ -136,14 +137,14 @@ selected conditions in effect at that time.
Some examples of types of policies are:
-* VNF placement — rules governing where VNFs should be placed, including
+* VNF placement - rules governing where VNFs should be placed, including
affinity rules
-* Data and feed management — what data to collect and when, retention periods,
+* Data and feed management - what data to collect and when, retention periods,
and when to send alarms about issues
-* Access control — who (or what) can have access to which data
-* Trigger conditions and actions — what conditions are actionable, and what to
+* Access control - who (or what) can have access to which data
+* Trigger conditions and actions - what conditions are actionable, and what to
do under those conditions
-* Interactions — how interactions between change management and
+* Interactions - how interactions between change management and
fault/performance management are handled (for example, should closed loops be
disabled during maintenance?)
@@ -190,7 +191,7 @@ correct component in a control loop such as the MSO, a Controller, or DCAE.
Policy engines such as XACML and Drools also enforce policies and can trigger
other components as a result (for example, causing a controller to take
specific actions specified by the policy). Additionally, some policies
-(“Guard Policies”) may enforce checks against decided actions.
+("Guard Policies") may enforce checks against decided actions.
Policy Unification and Organization