From f65c8ff3a2db95038b3d330f0fc639d5efd83484 Mon Sep 17 00:00:00 2001 From: Pamela Dragosh Date: Wed, 29 Apr 2020 08:23:12 -0400 Subject: [PATCH] Design/api documentation Updates and fixes. Issue-ID: POLICY-2500 Change-Id: I2d7a0c78d57edf8bd258f685b12ae31bf6d54735 Signed-off-by: Pamela Dragosh --- docs/api/api.rst | 51 +- docs/design/design.rst | 942 ++++----------------- docs/design/draw.io/Guard.drawio | 1 + docs/design/draw.io/Operational.drawio | 1 + docs/design/draw.io/Optimization.drawio | 1 + docs/design/images/Guard.svg | 3 + docs/design/images/Operational.svg | 3 + docs/design/images/Optimization.svg | 3 + .../images/PolicyImplPDPSubGroup.svg | 0 docs/pap/pap.rst | 58 ++ docs/xacml/decision-api.rst | 6 +- docs/xacml/xacml.rst | 14 +- 12 files changed, 293 insertions(+), 790 deletions(-) create mode 100644 docs/design/draw.io/Guard.drawio create mode 100644 docs/design/draw.io/Operational.drawio create mode 100644 docs/design/draw.io/Optimization.drawio create mode 100644 docs/design/images/Guard.svg create mode 100644 docs/design/images/Operational.svg create mode 100644 docs/design/images/Optimization.svg rename docs/{design => pap}/images/PolicyImplPDPSubGroup.svg (100%) diff --git a/docs/api/api.rst b/docs/api/api.rst index 5428a6fc..222a2bce 100644 --- a/docs/api/api.rst +++ b/docs/api/api.rst @@ -10,10 +10,9 @@ Policy Life Cycle API .. contents:: :depth: 2 -Policy life cycle API comprises of policy design API and policy deployment API. This documentation focuses on policy -design API. Policy design API is publicly exposed for clients to Create/Read/Update/Delete (CRUD) policy types, policy type -implementation and policies which can be recognized and executable by appropriate policy engines incorporated in ONAP -policy framework. Policy design API backend is running in an independent building block component of policy framework +The purpose of this API is to support CRUD of TOSCA *PolicyType* entities. This API is provided by the +*PolicyDevelopment* component of the Policy Framework, see the :ref:`The ONAP Policy Framework Architecture +` page. Policy design API backend is running in an independent building block component of policy framework that provides REST service for aforementioned CRUD behaviors. Policy design API component interacts with a policy database for storing and fetching new policies or policy types as needed. Apart from CRUD, API is also exposed for clients to retrieve healthcheck status of this API REST service and statistics report including a variety of counters that reflect the history @@ -29,8 +28,46 @@ atop. In other words, different policies can match the same or different policy of creating such type of policies. In the payload body of each policy to create, policy type name and version should be indicated and the specified policy type should be valid and existing in policy database. +The API allows applications to create, update, delete, and query *PolicyType* entities so that they become available for +use in ONAP by applications such as CLAMP. Some Policy Type entities are preloaded in the Policy Framework. The TOSCA +fields below are valid on API calls: + +============ ======= ======== ========== =============================================================================== +**Field** **GET** **POST** **DELETE** **Comment** +============ ======= ======== ========== =============================================================================== +(name) M M M The definition of the reference to the Policy Type, GET allows ranges to be + specified +version O M C GET allows ranges to be specified, must be specified if more than one version + of the Policy Type exists +description R O N/A Desciption of the Policy Type +derived_from R C N/A Must be specified when a Policy Type is derived from another Policy Type such + as in the case of derived Monitoring Policy Types +metadata R O N/A Metadata for the Policy Type +properties R M N/A This field holds the specification of the specific Policy Type in ONAP +targets R O N/A A list of node types and/or group types to which the Policy Type can be applied +triggers R O N/A Specification of policy triggers, not currently supported in ONAP +============ ======= ======== ========== =============================================================================== + +.. note:: + On this and subsequent tables, use the following legend: M-Mandatory, O-Optional, R-Read-only, C-Conditional. + Conditional means the field is mandatory when some other field is present. + +.. note:: + Preloaded policy types may only be queried over this API, modification or deletion of preloaded policy type + implementations is disabled. + +.. note:: + Policy types that are in use (referenced by defined Policies) may not be deleted. + +.. note:: + The group types of targets in TOSCA are groups of TOSCA nodes, not PDP groups; the *target* concept in TOSCA is + equivalent to the Policy Enforcement Point (PEP) concept + + To ease policy creation, we preload several widely used policy types in policy database. Below is a table listing the preloaded policy types. +.. _policy-preload-label: + .. csv-table:: :header: "Policy Type Name", "Payload" :widths: 15,10 @@ -93,7 +130,7 @@ Below is a table containing sample well-formed TOSCA compliant policies. Below is a global API table from where swagger JSON for different types of policy design API can be downloaded. Global API Table --------------------- +---------------- .. csv-table:: :header: "API name", "Swagger JSON" :widths: 10,5 @@ -105,7 +142,7 @@ Global API Table "Legacy Operational Policy API", ":download:`link `" API Swagger --------------------- +----------- It is worth noting that we use basic authorization for API access with username and password set to *healthcheck* and *zb!XztG34* respectively. Also, the new APIs support both *http* and *https*. @@ -190,6 +227,8 @@ From API client perspective, using *http* or *https* does not have much differen Here we list some sample curl commands (using *http*) for POST, GET and DELETE monitoring and operational policies that are used in vFirewall use case. JSON payload for POST calls can be downloaded from policy table above. +If you are accessing the api from the container, the default *ip* and *port* would be **https:/policy-api:6969/policy/api/v1/**. + Create vFirewall Monitoring Policy:: curl --user 'healthcheck:zb!XztG34' -X POST "http://{ip}:{port}/policy/api/v1/policytypes/onap.policies.monitoring.cdap.tca.hi.lo.app/versions/1.0.0/policies" -H "Accept: application/json" -H "Content-Type: application/json" -d @vFirewall.policy.monitoring.input.tosca.json diff --git a/docs/design/design.rst b/docs/design/design.rst index 190758ce..c484cd51 100644 --- a/docs/design/design.rst +++ b/docs/design/design.rst @@ -8,15 +8,12 @@ Policy Design and Development ############################# .. contents:: - :depth: 3 + :depth: 4 This document describes the design principles that should be used to write, deploy, and run policies of various types using the Policy Framework. It explains the APIs that are available for Policy Framework users. It provides copious examples to illustrate policy design and API usage. -1 Introduction -============== - The figure below shows the Artifacts (Blue) in the ONAP Policy Framework, the Activities (Yellow) that manipulate them, and important components (Salmon) that interact with them. The Policy Framework is fully TOSCA compliant, and uses TOSCA to model policies. Please see the :ref:`TOSCA Policy Primer ` page for an introduction to TOSCA @@ -46,8 +43,8 @@ artifact specifies the values of the properties for the policy and specifies the Policy Design uses the TOSCA *Policy* artifact and the *PolicyTypeImpl* artifact to create an executable *PolicyImpl* artifact.  -2 ONAP Policy Types -=================== +ONAP Policy Types +================= Policy Type Design manages TOSCA *PolicyType* artifacts and their *PolicyTypeImpl* implementations. @@ -55,36 +52,39 @@ A TOSCA *PolicyType* may ultimately be defined by the modeling team but for now project. Various editors and GUIs are available for creating *PolicyTypeImpl* implementations. However, systematic integration of *PolicyTypeImpl* implementation is outside the scope of the ONAP Dublin release. -The *PolicyType* definitions and implementations listed below are preloaded and are always available for use in the -Policy Framework. - -======================================= =============================================================================== -**Policy Type** **Description** -======================================= =============================================================================== -onap.policies.Monitoring Overarching model that supports Policy driven DCAE microservice components used - in Control Loops -onap.policies.controlloop.Operational Used to support legacy actor/action operational policies for control loops -onap.policies.controlloop.Guard Control Loop guard policies for policing control loops -onap.policies.controlloop.Coordination Control Loop Coordination policies to assist in coordinating multiple control - loops at runtime -onap.policies.controlloop.common.Drools Used to support tosca compliant actor/action operational policies for control - loops -onap.policies.native.drools.Controller Used to support the definition of PDP-D controllers -onap.policies.native.drools.Artifact Used to associate application's software with a PDP-D controller -======================================= =============================================================================== - -2.1 Policy Type: onap.policies.Monitoring ------------------------------------------ +The *PolicyType* definitions and implementations listed below can be preloaded so that they are available for use in the +Policy Framework upon platform installation. For a full listing of available preloaded policy types, see the +:ref:`Policy API Preloaded Policy Type List `. + +======================================= =============================================================================== +**Base Policy Types** **Description** +======================================= =============================================================================== +onap.policies.Monitoring Base model that supports Policy driven DCAE microservice components used + in Control Loops +onap.policies.controlloop.Operational Legacy actor/action operational policies for control loops (Deprecated) +onap.policies.controlloop.operational.Common Base Control Loop operational policy common definitions +onap.policies.controlloop.guard.Common Control Loop Guard Policy common definitions +onap.policies.Optimization Base OOF Optimization Policy Type definition +onap.policies.Naming Base SDNC Naming Policy Type definition +onap.policies.Native Base Native Policy Type for PDPs to inherit from in order to provide their own + native policy type. +======================================= =============================================================================== + +.. note:: + The El Alto onap.policies.controlloop.Guard policy types were deprecated and removed in Frankfurt. + +1 Base Policy Type: onap.policies.Monitoring +-------------------------------------------- This is a base Policy Type that supports Policy driven DCAE microservice components used in a Control Loops. The -implementation of this Policy Type is developed using the XACML PDP to support question/answer Policy Decisions during -runtime for the DCAE Policy Handler. +implementation of this Policy Type is done in the XACML PDP. The :ref:`Decision API ` is used by the DCAE +Policy Handler to retrieve a decision on which policy to enforce during runtime. .. code-block:: yaml :caption: Base Policy Type definition for onap.policies.Monitoring :linenos: - tosca_definitions_version: tosca_simple_yaml_1_0_0 + tosca_definitions_version: tosca_simple_yaml_1_1_0 topology_template: policy_types: - onap.policies.Monitoring: @@ -97,838 +97,220 @@ TOSCA *PolicyType* artifacts in the Policy Framework using the Policy Type Desig artifacts will use the same *PolicyTypeImpl* implementation with different property types and towards different targets. This allows dynamically generated DCAE microservice component Policy Types to be created at Design Time. -DCAE microservice components can generate their own TOSCA *PolicyType* using TOSCA-Lab Control Loop guard policies in -SDC (Stretch Goal) or can do so manually. See `How to generate artefacts for SDC catalog using Tosca Lab Tool -`__ -for details on TOSCA-LAB in SDC. For Dublin, the DCAE team is defining the manual steps required to build policy models -`Onboarding steps for DCAE MS through SDC/Policy/CLAMP (Dublin) -`__. - -.. note:: - For Dublin, microservice Policy Types will be preloaded into the SDC platform and be available as a Normative. The - policy framework will preload support for those microservice Monitoring policy types. +Please be sure to name your Policy Type appropriately by prepending it with **onap.policies.monitoring.Custom**. +Notice the lowercase **m** for monitoring, which follows TOSCA conventions. And also notice the capitalized "C" for +your analytics policy type name. .. code-block:: yaml :caption: Example PolicyType *onap.policies.monitoring.MyDCAEComponent* derived from *onap.policies.Monitoring* :linenos: - tosca_definitions_version: tosca_simple_yaml_1_0_0 + tosca_definitions_version: tosca_simple_yaml_1_1_0 policy_types: - - onap.policies.Monitoring: - derived_from: tosca.policies.Root - version: 1.0.0 - description: a base policy type for all policies that govern monitoring provision - - onap.policies.monitoring.MyDCAEComponent: + - onap.policies.monitoring.Mycomponent: derived_from: onap.policies.Monitoring version: 1.0.0 properties: - mydcaecomponent_policy: - type: map - description: The Policy Body I need - entry_schema: - type: onap.datatypes.monitoring.mydatatype - - data_types: - - onap.datatypes.monitoring.MyDataType: - derived_from: tosca.datatypes.Root - properties: - my_property_1: - type: string - description: A description of this property - constraints: - - valid_values: - - value example 1 - - value example 2 + my_property_1: + type: string + description: A description of this property For more examples of monitoring policy type definitions, please refer to the examples in the `ONAP policy-models gerrit -repository `__. +repository `__. Please +note that some of the examples do not adhere to TOSCA naming conventions due to backward compatibility. -2.2 Policy Type: onap.policies.controlloop.Operational ------------------------------------------------------- -This policy type is used to support actor/action operational policies for control loops. There are two types of -implementations for this policy type +2 Base Policy Type onap.policies.controlloop.operational.Common +--------------------------------------------------------------- +This is the new Operational Policy Type introduced in Frankfurt release to fully support TOSCA Policy Type. There are common +properties and datatypes that are independent of the PDP engine used to enforce this Policy Type. -1. Drools implementations that supports runtime Control Loop actions taken on components such as SO/APPC/VFC/SDNC/SDNR -2. Implementations using APEX to support Control Loops. +.. image:: images/Operational.svg + :alt: Operational Policy Type Inheritance -.. note:: - For Dublin, this policy type will ONLY be used for the Policy Framework to distinguish the policy type as operational. +2.1 onap.policies.controlloop.operational.common.Drools +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. code-block:: yaml - :caption: Base Policy Type definition for onap.policies.controlloop.Operational - :linenos: +Drools PDP Control Loop Operational Policy definition extends the base common policy type by adding a property for **controllerName**. - tosca_definitions_version: tosca_simple_yaml_1_0_0 - policy_types: - - onap.policies.controlloop.Operational: - derived_from: tosca.policies.Root - version: 1.0.0 - description: Operational Policy for Control Loops - -Applications should use the following Content-Type when creating onap.policies.controlloop.Operational policies: -.. code-block:: - - Content-Type: "application/yaml" - -2.2.1 Operational Policy Type Schema for Drools -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Please see the definition of the `Drools Operational Policy Type `_ -For Dublin Drools will still support the Casablanca YAML definition of an Operational Policy for Control Loops. -Please use the the `YAML Operational Policy format -`__. +2.2 onap.policies.controlloop.operational.common.Apex +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -2.2.2 Operational Policy Type Schema for APEX -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Apex PDP Control Loop Operational Policy definition extends the base common policy type by adding additional properties. -The operational Policy Type schema for APEX extends the base operational Policy Type schema. This Policy Type allows -parameters specific to the APEX PDP to be specified as a TOSCA policy. See `this sample APEX policy type definition -`__. +Please see the definition of the `Apex Operational Policy Type `_ -2.3 Policy Type: onap.policies.controlloop.Guard ------------------------------------------------- +3 Base Policy Type: onap.policies.controlloop.guard.Common +---------------------------------------------------------- -This policy type is the the type definition for Control Loop guard policies for frequency limiting, blacklisting and +This base policy type is the the type definition for Control Loop guard policies for frequency limiting, blacklisting and min/max guards to help protect runtime Control Loop Actions from doing harm to the network. This policy type is developed using the XACML PDP to support question/answer Policy Decisions during runtime for the Drools and APEX onap.controlloop.Operational policy type implementations. -.. code-block:: yaml - :caption: Base Policy Type definition for onap.policies.controlloop.Guard - :linenos: - - tosca_definitions_version: tosca_simple_yaml_1_0_0 - policy_types: - - onap.policies.controlloop.Guard: - derived_from: tosca.policies.Root - version: 1.0.0 - description: Guard Policy for Control Loops Operational Policies - -As with the *onap.policies.Monitoring* policy type, the *PolicyTypeImpl* implementation of the -*onap.policies.controlloop.Guard* Policy Type is generic to support definition of TOSCA *PolicyType* artifacts in the -Policy Framework using the Policy Type Design API. +.. image:: images/Guard.svg + :alt: Guard Policy Type Inheritance -.. note:: - For Dublin, only the following derived Policy Type definitions below are preloaded in the Policy Framework. However, - the creation of policies will still support the payload from Casablanca. +Please see the definition of the `Common Guard Policy Type `_ -Guard policy type definitions for *FrequencyLimiter*, *BlackList*, and *MinMax* are available in the `ONAP -policy-models gerrit repository -`__. +3.1 Frequency Limiter Guard onap.policies.controlloop.guard.common.FrequencyLimiter +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -2.4 Policy Type: onap.policies.controlloop.common.Drools --------------------------------------------------------- +The frequency limiter supports limiting the frequency of actions being taken by an Actor. -This policy type supports composition of Tosca-compliant Operational Policies for the PDP-D. The -`onap.policies.controlloop.common.Drools policy type specification -`__ is preferred for composition of operational -policies over its `onap.policies.controlloop.Operational policy type specification -`__ precursor, which eventually will be deprecated. -Both policy types are functionally equivalent. +Please see the definition of the `Guard Frequency Limiter Policy Type `_ -2.5 Policy Type: onap.policies.native.drools.Controller -------------------------------------------------------- +3.2 Min/Max Guard onap.policies.controlloop.guard.common.MinMax +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This policy type supports creation of native PDP-D controllers via policy. A controller is an abstraction on -the PDP-D that groups communication channels, message mapping rules, and -any other arbitrary configuration data to realize an application. +The Min/Max Guard supports Min/Max number of entity for scaling operations. -Policies of this type are composed against the -`onap.policies.native.drools.Controller policy type specification -`__ specification. +Please see the definition of the `Guard Min/Max Policy Type `_ -2.6 Policy Type: onap.policies.native.drools.Artifact -------------------------------------------------------- +3.3 Blacklist Guard onap.policies.controlloop.guard.common.Blacklist +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This policy type supports the dynamic association of a native PDP-D controller with rules and dependent -java libraries. This policy type is used in conjuction with the onap.policies.native.drools.Controller -type to create or upgrade a drools application on a live PDP-D. +The Blacklist Guard Supports blacklisting control loop actions from being performed on specific entity id's. -Policies of this type are composed against the -`onap.policies.native.drools.Controller policy type specification -`__ specification. +Please see the definition of the `Guard Blacklist Policy Type `_ -3 PDP Deployment and Registration with PAP -========================================== - -The unit of execution and scaling in the Policy Framework is a *PolicyImpl* entity. A *PolicyImpl* entity runs on a PDP. -As is explained above, a *PolicyImpl* entity is a *PolicyTypeImpl* implementation parameterized with a TOSCA *Policy*. - -.. image:: images/PolicyImplPDPSubGroup.svg - -In order to achieve horizontal scalability, we group the PDPs running instances of a given *PolicyImpl* entity logically -together into a *PDPSubGroup*. The number of PDPs in a *PDPSubGroup* can then be scaled up and down using Kubernetes. In -other words, all PDPs in a subgroup run the same *PolicyImpl*, that is the same policy template implementation (in -XACML, Drools, or APEX) with the same parameters. - -The figure above shows the layout of *PDPGroup* and *PDPSubGroup* entities. The figure shows examples of PDP groups for -Control Loop and Monitoring policies on the right. - -The health of PDPs is monitored by the PAP in order to alert operations teams managing policy. The PAP manages the life -cycle of policies running on PDPs. - -The table below shows the deployment methods in which *PolicyImpl* entities can be deployed to PDP Subgroups. - -========== =========================================== ============================== ================================== -**Method** **Description** **Advantages** **Disadvantages** -========== =========================================== ============================== ================================== -Cold The *PolicyImpl* (*PolicyTypeImpl* and No run time configuration Very restrictive, no run time - TOSCA *Policy*) are predeployed on the PDP. required and run time configuration of PDPs is possible. - PDP is fully configured and ready to administration is simple. - execute when started. - - PDPs register with the PAP when they - start, providing the *PolicyImpl* they - have been predeployed with. - -Warm The *PolicyTypeImpl* entity is predeployed The configuration, parameters, Administration and management is - on the PDP. A TOSCA *Policy* may be loaded and PDP group of PDPs may be required. The configuration and - at startup. The PDP may be configured or changed at run time by loading life cycle of the TOSCA policies - reconfigured with a new or updated TOSCA or updating a TOSCA *Policy* can change at run time and must be - *Policy* at run time. into the PDP. administered and managed. - - PDPs register with the PAP when they start, Support TOSCA *Policy* entity - providing the *PolicyImpl* they have been life cycle managgement is - predeployed with if any. The PAP may update supported, allowing features - the TOSCA *Policy* on a PDP at any time such as *PolicyImpl* Safe Mode - after registration. and *PolicyImpl* retirement. - -Hot The *PolicyImpl* (*PolicyTypeImpl* and The policy logic, rules, Administration and management is - TOSCA *Policy*) are deployed at run time. configuration, parameters, and more complex. The *PolicyImpl* - The *PolicyImpl* (*PolicyTypeImpl* and PDP group of PDPs may be itself and its configuration and - TOSCA *Policy*) may be loaded at startup. changed at run time by loading life cycle as well as the life - The PDP may be configured or reconfigured or updating a TOSCA *Policy* cycle of the TOSCA policies can - with a new or updated *PolicyTypeImpl* and *PolicyTypeImpl* into the change at run time and must be - and/or TOSCA *Policy* at run time. PDP. administered and managed. - - PDPs register with the PAP when they Lifecycle management of TOSCA - start, providing the *PolicyImpl* they have *Policy* entities and - been predeployed with if any. The PAP may *PolicyTypeImpl* entites is - update the TOSCA *Policy* and supported, allowing features - *PolicyTypeImpl* on a PDP at any time after such as *PolicyImpl* Safe Mode - registration and *PolicyImpl* retirement. -========== =========================================== ============================== ================================== - -4. Policy Framework Public APIs -=============================== - -The Policy Framework provides the public APIs outline in the subsections below. For a full description of the APIs, see -their individual documentation linked in each subsection. - -4.1 Policy Type Design API for TOSCA Policy Types -------------------------------------------------- - -The full documentation for this API is available on the :ref:`Policy Life Cycle API ` page. - -The purpose of this API is to support CRUD of TOSCA *PolicyType* entities. This API is provided by the -*PolicyDevelopment* component of the Policy Framework, see the :ref:`The ONAP Policy Framework Architecture -` page. - -The API allows applications to create, update, delete, and query *PolicyType* entities so that they become available for -use in ONAP by applications such as CLAMP. Some Policy Type entities are preloaded in the Policy Framework. The TOSCA -fields below are valid on API calls: - -============ ======= ======== ========== =============================================================================== -**Field** **GET** **POST** **DELETE** **Comment** -============ ======= ======== ========== =============================================================================== -(name) M M M The definition of the reference to the Policy Type, GET allows ranges to be - specified -version O M C GET allows ranges to be specified, must be specified if more than one version - of the Policy Type exists -description R O N/A Desciption of the Policy Type -derived_from R C N/A Must be specified when a Policy Type is derived from another Policy Type such - as in the case of derived Monitoring Policy Types -metadata R O N/A Metadata for the Policy Type -properties R M N/A This field holds the specification of the specific Policy Type in ONAP -targets R O N/A A list of node types and/or group types to which the Policy Type can be applied -triggers R O N/A Specification of policy triggers, not currently supported in ONAP -============ ======= ======== ========== =============================================================================== +4 Optimization onap.policies.Optimization +----------------------------------------- -.. note:: - On this and subsequent tables, use the following legend: M-Mandatory, O-Optional, R-Read-only, C-Conditional. - Conditional means the field is mandatory when some other field is present. +The Optimization Base Policy Type supports the OOF optimization policies. The Base policy Type has common properties shared +by all its derived policy types. -.. note:: - Preloaded policy types may only be queried over this API, modification or deletion of preloaded policy type - implementations is disabled. +.. image:: images/Optimization.svg + :alt: Optimization Policy Type Inheritance -.. note:: - Policy types that are in use (referenced by defined Policies) may not be deleted. +Please see the definition of the `Base Optimization Policy Type `_. -.. note:: - The group types of targets in TOSCA are groups of TOSCA nodes, not PDP groups; the *target* concept in TOSCA is - equivalent to the Policy Enforcement Point (PEP) concept +These Policy Types are unique in that some properties have an additional metadata property **matchable** set to **true** +which indicates that this property can be used to support more fine-grained Policy Decisions. For more information, +see the :ref:`XACML Optimization application implementation `. -4.2 Policy Design API ---------------------- +4.1 Optimization Service Policy Type onap.policies.optimization.Service +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The full documentation for this API is available on the :ref:`Policy Life Cycle API ` page. +This policy type further extends the base onap.policies.Optimization type by defining additional properties specific to +a service. For more information: -The purpose of this API is to support CRUD of TOSCA *Policy* entities from TOSCA compliant *PolicyType* definitions. -TOSCA *Policy* entities become the parameters for *PolicyTypeImpl* entities, producing *PolicyImpl* entities that can -run on PDPs. This API is provided by the *PolicyDevelopment* component of the Policy Framework, see the :ref:`The ONAP -Policy Framework Architecture ` page. +`Service Optimization Base Policy Type `_ -This API allows applications (such as CLAMP and Integration) to create, update, delete, and query *Policy* entities. The -TOSCA fields below are valid on API calls: +Several additional policy types inherit from the Service Optimization Policy Type. For more information, :ref:`XACML Optimization +application implementation `. -=========== ======= ======== ========== ================================================================================ -**Field** **GET** **POST** **DELETE** **Comment** -=========== ======= ======== ========== ================================================================================ -(name) M M M The definition of the reference to the Policy, GET allows ranges to be specified -type O M O The Policy Type of the policy, see section 3.1 -description R O O -metadata R O N/A -properties R M N/A This field holds the specification of the specific Policy in ONAP -targets R O N/A A list of nodes and/or groups to which the Policy can be applied -=========== ======= ======== ========== ================================================================================ +4.2 Optimization Resource Policy Type onap.policies.optimization.Resource +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. note:: - Policies that are deployed (used on deployed *PolicyImpl* entities) may not be deleted +This policy type further extends the base onap.policies.Optimization type by defining additional properties specific to +a resource. For more information: -.. note:: - This API is NOT used by DCAE for a decision on what policy the DCAE PolicyHandler should retrieve and enforce +`Resource Optimization Base Policy Type `_ -.. note:: - The groups of targets in TOSCA are groups of TOSCA nodes, not PDP groups; the *target* concept in TOSCA is equivalent - to the Policy Enforcement Point (PEP) concept +Several additional policy types inherit from the Resource Optimization Policy Type. For more information, :ref:`XACML Optimization +application implementation `. -4.3 Policy Administration API +5 Naming onap.policies.Naming ----------------------------- -The full documentation for this API is available on the :ref:`Policy Administration Point (PAP) ` page. - -The purpose of this API is to support CRUD of PDP groups and subgroups and to support the deployment and life cycles of -*PolicyImpl* entities (TOSCA *Policy* and *PolicyTypeImpl* entities) on PDP sub groups and PDPs. This API is provided by -the *PolicyAdministration* component (PAP) of the Policy Framework, see the :ref:`The ONAP Policy Framework Architecture -` page. - -PDP groups and subgroups may be prefedined in the system. Predefined groups and subgroups can be modified or deleted -over this API. The policies running on predefined groups or subgroups as well as the desired instance counts and -properties can also be modified. - -A PDP may be preconfigured with its PDP group, PDP subgroup, and policies. The PDP sends this information to the PAP -when it starts. If the PDP group, subgroup, or any policy is unknown to the PAP, the PAP locks the PDP in state PASSIVE. - -The state of PDP groups is managed by the API. PDP groups can be in states PASSIVE, TEST, SAFE, or ACTIVE. For a full -description of PDP group states, the :ref:`The ONAP Policy Framework Architecture ` page. - -The API supports retrieval of statistics for PDP groups, PDP subgroups, and individual PDPs. It also allows a PDP group -health check to be ordered on PDP groups and on individual PDPs. - -The fields below are valid on API calls: - -============================ ======= ======== ========== =============================================================== -**Field** **GET** **POST** **DELETE** **Comment** -============================ ======= ======== ========== =============================================================== -name M M M The name of the PDP group -version O M C The version of the PDP group -state R N/A N/A The administrative state of the PDP group: PASSIVE, SAFE, TEST, - or ACTIVE -description R O N/A The PDP group description -properties R O N/A Specific properties for a PDP group -pdp_subgroups R M N/A A list of PDP subgroups for a PDP group -->pdp_type R M N/A The PDP type of this PDP subgroup, currently xacml, drools, or - apex -->supported_policy_types R N/A N/A A list of the policy types supported by the PDPs in this PDP - subgroup. A trailing “.*” can be used to specify multiple - policy types; for example, “onap.policies.monitoring.*” - would match any policy type beginning with - “onap.policies.monitoring.” -->policies R M N/A The list of policies running on the PDPs in this PDP subgroup -->->(name) R M N/A The name of a TOSCA policy running in this PDP subgroup -->->policy_type R N/A N/A The TOSCA policy type of the policy -->->policy_type_version R N/A N/A The version of the TOSCA policy type of the policy -->->policy_type_impl R C N/A The policy type implementation (XACML, Drools Rules, or APEX - Model) that implements the policy -->instance_count R N/A N/A The number of PDP instances running in a PDP subgroup -->min_instance_count O N/A N/A The minumum number of PDP instances to run in a PDP subgroup -->properties O N/A N/A Deployment configuration or other properties for the PDP - subgroup -->deployment_info R N/A N/A Information on the deployment for a PDP subgroup -->instances R N/A N/A A list of PDP instances running in a PDP subgroup -->->instance R N/A N/A The instance ID of a PDP running in a Kuberenetes Pod -->->state R N/A N/A The administrative state of the PDP: PASSIVE, SAFE, TEST, or - ACTIVE -->->healthy R N/A N/A The result of the latest health check on the PDP: - HEALTHY/NOT_HEALTHY/TEST_IN_PROGRESS -->->message O N/A N/A A status message for the PDP if any -->->deployment_instance_info R N/A N/A Information on the node running the PDP -============================ ======= ======== ========== =============================================================== - -Note: In the Dublin release, the *policy_type_impl* of all policy types in a PDP subgroup must be the same. - -4.4 Policy Decision API - Getting Policy Decisions --------------------------------------------------- - -Policy decisions are required by ONAP components to support the policy-driven ONAP architecture. Policy Decisions are -implemented using the XACML PDP. The calling application must provide attributes in order for the XACML PDP to return a -correct decision. - -Decision API queries are implemented with a POST operation with a JSON body that specifies the filter for the policies -to be returned. - -*https:{url}:{port}/decision/v1/ POST* - -The table below describes the fields in the JSON payload for the decision API Call. - -============= ======= ======== ========================================================================== -**Field** **R/O** **Type** **Description** -============= ======= ======== ========================================================================== -ONAPName R String Name of the ONAP Project that is making the request. -ONAPComponent O String Name of the ONAP Project component that is making the request. -ONAPInstance O String Optional instance identification for that ONAP component. -action R String The action that the ONAP component is performing on a resource. - "configure" → DCAE uS onap.Monitoring policy Decisions to configure uS - "naming" - "placement" - "guard" -============= ======= ======== ========================================================================== - -These sub metadata structures are used to scope the resource the ONAP component is performing an action upon. At least -one must be specified in order for Policy to return a decision. Multiple structures may be utilized to help define a -precise scope for a decision. - -4.4.1 Policy Decision API - DCAE configuration examples -------------------------------------------------------- - -These resource fields are examples on how DCAE implements its "configure" application to make Decision API calls. - -================= ======= ======== ================================================================== -**Field** **R/O** **Type** **Description** -================= ======= ======== ================================================================== -policy-type-name O String The policy type name. This may be a regular expression. -policy-id O String The policy id. This may be a regular expression or an exact value. -================= ======= ======== ================================================================== - -This example below shows the JSON body of a query with a single policy ID. - -.. code-block:: yaml - :caption: Decision API Call - Single Policy ID query - :linenos: - - { - "ONAPName": "DCAE", - "ONAPComponent": "PolicyHandler", - "ONAPInstance": "622431a4-9dea-4eae-b443-3b2164639c64", - "action": "configure", - "resource": { - "policy-id": "onap.scaleout.tca" - } - } - -.. code-block:: yaml - :caption: Decision Response - Single Policy ID query - :linenos: - - { - "policies": { - "onap.scaleout.tca": { - "type": "onap.policies.monitoring.cdap.tca.hi.lo.app", - "version": "1.0.0", - "metadata": { - "policy-id": "onap.scaleout.tca", - "policy-version": 1 - }, - "properties": { - "tca_policy": { - "domain": "measurementsForVfScaling", - "metricsPerEventName": [{ - "eventName": "vLoadBalancer", - "controlLoopSchemaType": "VNF", - "policyScope": "type=configuration", - "policyName": "onap.scaleout.tca", - "policyVersion": "v0.0.1", - "thresholds": [{ - "closedLoopControlName": "ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3", - "closedLoopEventStatus": "ONSET", - "version": "1.0.2", - "fieldPath": "$.event.measurementsForVfScalingFields.vNicPerformanceArray[*] - .receivedBroadcastPacketsAccumulated", - "thresholdValue": 500, - "direction": "LESS_OR_EQUAL", - "severity": "MAJOR" - }, - { - "closedLoopControlName": "ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3", - "closedLoopEventStatus": "ONSET", - "version": "1.0.2", - "fieldPath": "$.event.measurementsForVfScalingFields.vNicPerformanceArray[*] - .receivedBroadcastPacketsAccumulated", - "thresholdValue": 5000, - "direction": "GREATER_OR_EQUAL", - "severity": "CRITICAL" - }] - }] - } - } - } - } - } +Naming policies are used in SDNC to enforce which naming policy should be used during instantiation. -This example below shows the JSON body of a query with multiple policy IDs. +Policies of this type are composed using the `Naming Policy Type Model `_. -.. code-block:: yaml - :caption: Decision API Call - Multiple Policy IDs query - :linenos: +6 Native Policy Types onap.policies.Native +------------------------------------------ - { - "ONAPName": "DCAE", - "ONAPComponent": "PolicyHandler", - "ONAPInstance": "622431a4-9dea-4eae-b443-3b2164639c64", - "action": "configure", - "resource": { - "policy-id": [ - "onap.scaleout.tca", - "onap.restart.tca" - ] - } - } - -.. code-block:: yaml - :caption: Decision Response - Multiple Policy IDs query - :linenos: - - { - "policies": { - "onap.scaleout.tca": { - "type": "onap.policies.monitoring.cdap.tca.hi.lo.app", - "version": "1.0.0", - "metadata": { - "policy-id": "onap.scaleout.tca" - }, - "properties": { - "tca_policy": { - "domain": "measurementsForVfScaling", - "metricsPerEventName": [ - { - "eventName": "vLoadBalancer", - "controlLoopSchemaType": "VNF", - "policyScope": "type=configuration", - "policyName": "onap.scaleout.tca", - "policyVersion": "v0.0.1", - "thresholds": [ - { - "closedLoopControlName": "ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3", - "closedLoopEventStatus": "ONSET", - "version": "1.0.2", - "fieldPath": "$.event.measurementsForVfScalingFields.vNicPerformanceArray[*] - .receivedBroadcastPacketsAccumulated", - "thresholdValue": 500, - "direction": "LESS_OR_EQUAL", - "severity": "MAJOR" - }, - { - "closedLoopControlName": "ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3", - "closedLoopEventStatus": "ONSET", - "version": "1.0.2", - "fieldPath": "$.event.measurementsForVfScalingFields.vNicPerformanceArray[*] - .receivedBroadcastPacketsAccumulated", - "thresholdValue": 5000, - "direction": "GREATER_OR_EQUAL", - "severity": "CRITICAL" - } - ] - } - ] - } - } - }, - "onap.restart.tca": { - "type": "onap.policies.monitoring.cdap.tca.hi.lo.app", - "version": "1.0.0", - "metadata": { - "policy-id": "onap.restart.tca", - "policy-version": 1 - }, - "properties": { - "tca_policy": { - "domain": "measurementsForVfScaling", - "metricsPerEventName": [ - { - "eventName": "Measurement_vGMUX", - "controlLoopSchemaType": "VNF", - "policyScope": "DCAE", - "policyName": "DCAE.Config_tca-hi-lo", - "policyVersion": "v0.0.1", - "thresholds": [ - { - "closedLoopControlName": "ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e", - "version": "1.0.2", - "fieldPath": "$.event.measurementsForVfScalingFields.additionalMeasurements[*] - .arrayOfFields[0].value", - "thresholdValue": 0, - "direction": "EQUAL", - "severity": "MAJOR", - "closedLoopEventStatus": "ABATED" - }, - { - "closedLoopControlName": "ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e", - "version": "1.0.2", - "fieldPath": "$.event.measurementsForVfScalingFields.additionalMeasurements[*] - .arrayOfFields[0].value", - "thresholdValue": 0, - "direction": "GREATER", - "severity": "CRITICAL", - "closedLoopEventStatus": "ONSET" - } - ] - } - ] - } - } - } - } - } +This is the Base Policy Type used by PDP engines to support their native language policies. PDP engines inherit from +this base policy type to implement support for their own custom policy type: -This example below shows the JSON body of a query to return all the deployed policies for a specific policy type. +.. code-block:: yaml -.. code-block:: yaml - :caption: Decision API Call - Policies for Policy Type query - :linenos: + tosca_definitions_version: tosca_simple_yaml_1_1_0 + policy_types: + onap.policies.Native: + derived_from: tosca.policies.Root + description: a base policy type for all native PDP policies + version: 1.0.0 - { - "ONAPName": "DCAE", - "ONAPComponent": "PolicyHandler", - "ONAPInstance": "622431a4-9dea-4eae-b443-3b2164639c64", - "action": "configure", - "resource": { - "policy-type": "onap.policies.monitoring.cdap.tca.hi.lo.app" - } - } +6.1 Policy Type: onap.policies.native.drools.Controller +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. code-block:: yaml - :caption: Decision Response - Policies for Policy Type query - :linenos: +This policy type supports creation of native PDP-D controllers via policy. A controller is an abstraction on +the PDP-D that groups communication channels, message mapping rules, and +any other arbitrary configuration data to realize an application. - { - "policies": { - "onap.scaleout.tca": { - "type": "onap.policies.monitoring.cdap.tca.hi.lo.app", - "version": "1.0.0", - "metadata": { - "policy-id": "onap.scaleout.tca", - "policy-version": 1, - }, - "properties": { - "tca_policy": { - "domain": "measurementsForVfScaling", - "metricsPerEventName": [ - { - "eventName": "vLoadBalancer", - "controlLoopSchemaType": "VNF", - "policyScope": "type=configuration", - "policyName": "onap.scaleout.tca", - "policyVersion": "v0.0.1", - "thresholds": [ - { - "closedLoopControlName": "ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3", - "closedLoopEventStatus": "ONSET", - "version": "1.0.2", - "fieldPath": "$.event.measurementsForVfScalingFields.vNicPerformanceArray[*] - .receivedBroadcastPacketsAccumulated", - "thresholdValue": 500, - "direction": "LESS_OR_EQUAL", - "severity": "MAJOR" - }, - { - "closedLoopControlName": "ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3", - "closedLoopEventStatus": "ONSET", - "version": "1.0.2", - "fieldPath": "$.event.measurementsForVfScalingFields.vNicPerformanceArray[*] - .receivedBroadcastPacketsAccumulated", - "thresholdValue": 5000, - "direction": "GREATER_OR_EQUAL", - "severity": "CRITICAL" - } - ] - } - ] - } - } - }, - "onap.restart.tca": { - "type": "onap.policies.monitoring.cdap.tca.hi.lo.app", - "version": "1.0.0", - "metadata": { - "policy-id": "onap.restart.tca", - "policy-version": 1 - }, - "properties": { - "tca_policy": { - "domain": "measurementsForVfScaling", - "metricsPerEventName": [ - { - "eventName": "Measurement_vGMUX", - "controlLoopSchemaType": "VNF", - "policyScope": "DCAE", - "policyName": "DCAE.Config_tca-hi-lo", - "policyVersion": "v0.0.1", - "thresholds": [ - { - "closedLoopControlName": "ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e", - "version": "1.0.2", - "fieldPath": "$.event.measurementsForVfScalingFields.additionalMeasurements[*].arrayOfFields[0] - .value", - "thresholdValue": 0, - "direction": "EQUAL", - "severity": "MAJOR", - "closedLoopEventStatus": "ABATED" - }, - { - "closedLoopControlName": "ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e", - "version": "1.0.2", - "fieldPath": "$.event.measurementsForVfScalingFields.additionalMeasurements[*].arrayOfFields[0] - .value", - "thresholdValue": 0, - "direction": "GREATER", - "severity": "CRITICAL", - "closedLoopEventStatus": "ONSET" - } - ] - } - ] - } - } - }, - "onap.vfirewall.tca": { - "type": "onap.policy.monitoring.cdap.tca.hi.lo.app", - "version": "1.0.0", - "metadata": { - "policy-id": "onap.vfirewall.tca", - "policy-version": 1 - }, - "properties": { - "tca_policy": { - "domain": "measurementsForVfScaling", - "metricsPerEventName": [ - { - "eventName": "vLoadBalancer", - "controlLoopSchemaType": "VNF", - "policyScope": "resource=vLoadBalancer;type=configuration", - "policyName": "onap.vfirewall.tca", - "policyVersion": "v0.0.1", - "thresholds": [ - { - "closedLoopControlName": "ControlLoop-vFirewall-d0a1dfc6-94f5-4fd4-a5b5-4630b438850a", - "closedLoopEventStatus": "ONSET", - "version": "1.0.2", - "fieldPath": "$.event.measurementsForVfScalingFields.vNicPerformanceArray[*] - .receivedBroadcastPacketsAccumulated", - "thresholdValue": 500, - "direction": "LESS_OR_EQUAL", - "severity": "MAJOR" - }, - { - "closedLoopControlName": "ControlLoop-vFirewall-d0a1dfc6-94f5-4fd4-a5b5-4630b438850a", - "closedLoopEventStatus": "ONSET", - "version": "1.0.2", - "fieldPath": "$.event.measurementsForVfScalingFields.vNicPerformanceArray[*] - .receivedBroadcastPacketsAccumulated", - "thresholdValue": 5000, - "direction": "GREATER_OR_EQUAL", - "severity": "CRITICAL" - } - ] - } - ] - } - } - } - } - } +Policies of this type are composed using the +`onap.policies.native.drools.Controller policy type specification +`__ specification. -4.4.2 Policy Decision API - Guard Decision API examples -------------------------------------------------------- +6.2 Policy Type: onap.policies.native.drools.Artifact +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -These resource fields are examples on how Drools-PDP implements its "guard" application to make Decision API calls. This -structure is a transition from the legacy guard API calls. So each of these resources are contained under a "guard" object -in the "resource" object of the JSON structure. +This policy type supports the dynamic association of a native PDP-D controller with rules and dependent +java libraries. This policy type is used in conjuction with the onap.policies.native.drools.Controller +type to create or upgrade a drools application on a live PDP-D. -================= ======= ======== ================================================================== -**Field** **R/O** **Type** **Description** -================= ======= ======== ================================================================== -actor O String The actor (eg APPC, SO) that is performing a recipe -recipe O String The recipe (eg Restart, Reboot) that the actor going to execute -clname O String The unique ID for the Control Loop -target O String The target VNF the actor is executing the recipe on -vfCount O String Specific to SO "VF Module Create" - the current count of VNFs +Policies of this type are composed against the +`onap.policies.native.drools.Controller policy type specification +`__ specification. -================= ======= ======== ================================================================== +6.3 Policy Type: onap.policies.native.Xacml +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This example below shows the JSON body of a guard Decision API call. +This policy type supports XACML OASIS 3.0 XML Policies. The policies are URL encoded in order to be easily transported via Lifecycle +API json and yaml Content-Types. When deployed to the XACML PDP (PDP-X), they will be managed by the **native** application. The PDP-X +will route XACML Request/Response RESTful API calls to the **native** application who manages those decisions. -.. code-block:: json - :caption: Decision API Call - Guard - :linenos: +`XACML Native Policy Type `_ - { - "ONAPName": "Policy", - "ONAPComponent": "drools-pdp", - "ONAPInstance": "usecase-template", - "requestId": "unique-request-id-1", - "action": "guard", - "resource": { - "guard": { - "actor": "SO", - "recipe": "VF Module Create", - "clname": "ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3", - "target": "vLoadBalancer-00", - "vfCount": "1" - } - } - } +6.4 Policy Type: onap.policies.native.Apex +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. code-block:: json - :caption: Decision Response - Guard - :linenos: +This policy type supports Apex native policy types. - {"status":"Permit"} +`Apex Native Policy Type `_ -4.4.3 Policy Decision API - Optimize Decision API examples ----------------------------------------------------------- -These resource fields are examples on how OOF project will make Decision API calls. NOTE: The OOF project -has not yet upgraded to the API. This work is scheduled for Frankfurt. +7 Base Policy Type: onap.policies.controlloop.Operational (Deprecated) +---------------------------------------------------------------------- -================= ======= ============== ================================================================== -**Field** **R/O** **Type** **Description** -================= ======= ============== ================================================================== -scope O List of String Optional scope for the policy. -services O List of String One or more services the policy applies to. -resources O List of String The unique ID for the Control Loop -geography O List of String The target VNF the actor is executing the recipe on +This policy type is used to support legacy YAML definitions for actor/action operational policies for control loops. +There are two types of implementations for this policy type: -================= ======= ============== ================================================================== +1. Drools implementations that support runtime Control Loop actions taken on components such as SO/APPC/VFC/SDNC/SDNR +2. Implementations using APEX to support Control Loops. -This example below shows the JSON body of an Optimize Decision API call. +.. note:: + This policy type will be deprecated after Frankfurt and is discouraged from being used. -.. code-block:: json - :caption: Decision API Call - Optimize vCPE service in US +.. code-block:: yaml + :caption: Base Policy Type definition for onap.policies.controlloop.Operational :linenos: - { - "ONAPName": "OOF", - "ONAPComponent": "OOF-component", - "ONAPInstance": "OOF-component-instance", - "action": "optimize", - "resource": { - "scope": [], - "services": ["vCPE"], - "resources": [], - "geography": ["US"] - } - } + tosca_definitions_version: tosca_simple_yaml_1_1_0 + policy_types: + - onap.policies.controlloop.Operational: + derived_from: tosca.policies.Root + version: 1.0.0 + description: Operational Policy for Control Loops + +There are no properties defined for this policy type, instead it is expected that the user submit the REST call with a +special JSON format used to bridge the Casablanca Legacy API to the new Lifecycle API introduced in Dublin release. .. code-block:: json - :caption: Decision Response - - :linenos: + :caption: Example Policy Payload for onap.policies.controlloop.Operational Policy Type { - "policies:" { - ### Omitted for brevity - } + "policy-id" : "operational.restart", + "policy-version" : "1", + "content" : "controlLoop%3A%0A%20%20version%3A%202.0.0%0A%20%20controlLoopName%3A%20ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e%0A%20%20trigger_policy%3A%20unique-policy-id-1-restart%0A%20%20timeout%3A%203600%0A%20%20abatement%3A%20true%0A%20%0Apolicies%3A%0A%20%20-%20id%3A%20unique-policy-id-1-restart%0A%20%20%20%20name%3A%20Restart%20the%20VM%0A%20%20%20%20description%3A%0A%20%20%20%20actor%3A%20APPC%0A%20%20%20%20recipe%3A%20Restart%0A%20%20%20%20target%3A%0A%20%20%20%20%20%20type%3A%20VM%0A%20%20%20%20retry%3A%203%0A%20%20%20%20timeout%3A%201200%0A%20%20%20%20success%3A%20final_success%0A%20%20%20%20failure%3A%20final_failure%0A%20%20%20%20failure_timeout%3A%20final_failure_timeout%0A%20%20%20%20failure_retries%3A%20final_failure_retries%0A%20%20%20%20failure_exception%3A%20final_failure_exception%0A%20%20%20%20failure_guard%3A%20final_failure_guard", + "controllerName" : "frankfurt" } -End of Document +For the **"content"** property, please refer to the `YAML Operational Policy format +`__ to define the +**content** field and URL Encode the yaml. diff --git a/docs/design/draw.io/Guard.drawio b/docs/design/draw.io/Guard.drawio new file mode 100644 index 00000000..40c94023 --- /dev/null +++ b/docs/design/draw.io/Guard.drawio @@ -0,0 +1 @@ +5VjLcpswFP0aL8MA4rmsSZwumpm0nk6bVUcDCtZE6FIhx5CvrwjinaenjROXjbkH6epy7uEIs0BRVp4LnG8uICFsYZtJuUCnC9u2whCpnxqpNOIju0FSQRON9cCa3hENmhrd0oQUo4ESgEmaj8EYOCexHGFYCNiNh10DG6+a45TMgHWM2Rz9QRO5adDANXv8M6Hppl3ZMvWVDLeDNVBscAK7AYTOFigSALI5y8qIsJq9lpdm3uqRq11hgnD5kgk3d8vqF+Vwfv7V/b6+LFbZ7vJEZ7nFbKtvWEIRYyMHRmNKCuNbXV9Tv6xaUnYbKsk6x3Ed71TnF2iJGU25CmNVDhEKuCVCUkXkJ30ho0lSJ1heA5drncxScSEF3HTsonoEZSwCBuJ+ObRSRxTpSlVWUj5KgdURqyRJICNSVGqInoBCr5my61tpOU6DbQZt9HTPsFZP2qXqCVYnmuNX8G3P+AaO855uJWPFBmMAuZFusUiMCLIM+NG0wPY1ta0htA/6oCVO+wy9SUvQrCUzskmiPEGHHHjNIIezAdhzOOAsDE11zNhV5CwVWaL6qQLTcNvwqg7b4LQcRZWOmsrqcp6mX1UPWxGT5598iUVK5HOKnbdz+AQ91K4OFIRhSW/HBT/URL3GJVB1K71exnKx3YkMmvvUk4buN8ljTRJZ00QNEbNE95Lq7nt/lTn/p8rsF6rMPbDKgok6wj1lZnuBgSzHdEI38HzfC92xfJH3pqpzX73dxPfbjbES5PeW8Lj6QjNabybHsv+cdPt92xLn0BuQt2+TLii/wOXRtGb6anD4zvgfyLRJSeVgmoqu9Or1eT+pDg5o9N5hjd7yHcOfeLK5p9d73tOvJv/Y24N9bWPJcHzDaHE8/+u84L05R/ghncN/19YRHNY6nOk7YrCnb0wT/T3jUGH/PakZ3n+WQ2d/AA== \ No newline at end of file diff --git a/docs/design/draw.io/Operational.drawio b/docs/design/draw.io/Operational.drawio new file mode 100644 index 00000000..25e92812 --- /dev/null +++ b/docs/design/draw.io/Operational.drawio @@ -0,0 +1 @@ +3VfbcpswEP0aHsNwM5fHmFzamXbaqWea5FEBBasRLBVyjPP1lSxxETiZJE3bNLyYPUha7TmHFbb8tGzPGarXnyHH1PKcvLX8E8vz3CRMxI9EdhqJHVchBSO5xgZgRe6xBh2NbkiOG2MgB6Cc1CaYQVXhjBsYYgy25rAboGbWGhV4BqwyROfoBcn5WqGxFw74B0yKdZfZ7Sq+RtltwWBT6XyW59/sL/W4RN1autBmjXLYjiD/1PJTBsDVXdmmmEpyO9rUvLMHnvb7ZrjiT5ngqwl3iG506RyaDNk1UJIR3Njf5FbUVvmuo2e7JhyvapTJeCs8YPlLRElRiTATmTETwB1mnAhKj/WDkuS5XGB5AxVf6cVcETecwW3Psy9HEEpToMD26fwzcaXpvDRdrUyE2xGkSz3HUGLOdmLI4Ew1ZTuI6gaBwtYjQUMtD9I+KvqlBi7FjabzMLXBjFqoUD0wK7wrCqcUoLahxgxxIgZQO4WyhOrdcB5pKrtW0L3iIwkCx/kzEvjhTIMZrzgXb74OK6gkWRWcjsCBrhE9SeKIa0ak4GEpqGK7SxE49qILr2TYBSetEe109CDXDWxYho33lSNWYG74TNbxqB5jzx8ivAcZpsKLd2YrPCSDzvEViNhxL7hnCu4tJkKqcvSkcWuarONOFnKnCykSZgvtTdHX/TSfRO/NJ8HcJz+vv1zky4+X9L6h19/bH+WnND9KorfmnniievJC+3hhbPtu4ATJIg6jKEwWpi273vD6bnqU6GcfB9n+OLBPxDcBbd7SqTA7Ag6Y8sFT4ag/djs9gr94LhxWKP49hY5rwcZ70ceLw7cmT/If9WjcEq6mRQsdXun08n6YJQOzsU868et1+vjfNnY3CiQZhqmcF/b2cGLOV/syEOHw30sNH/7h+qe/AA== \ No newline at end of file diff --git a/docs/design/draw.io/Optimization.drawio b/docs/design/draw.io/Optimization.drawio new file mode 100644 index 00000000..4e552d20 --- /dev/null +++ b/docs/design/draw.io/Optimization.drawio @@ -0,0 +1 @@ +7Vtdc5s4FP01fgwDSAh4TJy0nZ3dWTfutJunHYplW7MYeYQc2/31FUF8SCSx8QeasvVL0EUIcc/Rke6VMgLj1e4ji9bLv+gMJyPXnu1G4H7kuk4YAvEnt+ylxQduYVkwMpO22jAlP7A02tK6ITOcKRU5pQkna9UY0zTFMVdsEWN0q1ab00R96zpa4JZhGkdJ2/qNzPiysAaeXds/YbJYlm92bHlnFZWVpSFbRjO6bZjAwwiMGaW8uFrtxjjJvVf6pXjuwxt3q44xnPJjHrD/YMH2zy9fv8SP2+3jOHvazBc3jmzmOUo28os5zeLIWtOExARn1mPeweID+L70ynZJOJ6uozgvbwX0I3AXJWSRimIs+oOZMDxjxonw5K28sSKzWd7A3ZymfCobc0Q544z+V7kX5DVIkoxpQtnL68AH8RuPZU9Fq3j3pg+cyrOCk5iuMGd7UaUiJCoe2dZYOhAWtmUDRyRBiyR9FlVTtYfFhXRyF4e7LYfTNFrX/v57zcmK/Ig4oelw/B5If5YyUA7vJg5lnX5wAC0cWt7GMyEFspjSNHdhSh8axtqJDaeFoS1+LfcK79wJb7H9P6JgW15ZfMqLZeF+p5T2slT0LO/O+/4XvacbFuMjBjyP2ALzg0RtI9pEzH4FscrIcCJI/Kx2+TUc5TsmlIiPqSjjqoxxPY0JxZfKh5qyp7XjaA05ekOFJ1oNvbCq+u4ziAb/p0RzjyWaZ5houjaFJzLNRYEFHGjD0AuQ76PQUxkMUL/E8w7MNLQx01hTzJ6JAHQoM44uH7A94VSA9DPhoC5wPGI5wAaDR4AOA9LvSsz/hYQZ7wgvHvM9WXySr8+v66fyglE1R2bV3PFh7iKFavaJgo40yva9cgi7KEZWCLj1eYPZfpJX2Q9GPG5coMo5cNvqAWCf8UPZgW7gTDffs5iR75gNHSFoG0eoHWn3qO+Oou612J+98D6swKFhBQbIcu3656gj91QxdkNNAoLj1PiWsWjfqLbOK2Tvdl99j6ek1cRF0eJFpd41mo3oyNV6LWJmKeIdORAaWVYzAwGqA8H1VWI5J44EPaMB9ID1UiMBapIO+hgJ7XTJO/Mqk2GSdTufk5TwoS18oA61+XVPp6xChc89yXiU5uweNj6hcXw6pRkqfD5NbgcODUTGoWknHI6BprkhNHCMPGAco+AkjCYxGTg0yHw81ykdUkHzlaz+nZPhbGG3gPFNA1MO2q7ApPOBjxn/lRx3z9C0j3e0vH29uPLGtmwbqcElAuDo8NI9Pr58aWKCGRF+y+lx8aBTLqsOB53wdYr0F3QGCgcvFmVCqDV0oSgTQC0s9gKN9leIMstDaIb2fozlBl3De+1lMu3sbCB0fStEjeQKVNtF4nZwHb5qnwDVY3dX4qvZ00qn5gc7CLgRrTa8VwmQNhpO1Wqob76AfrQahn1w3+wBqqFy3zc9E1woG65z39OnlCtx30N9cL+dbf3N/fO5HwyV+34/3Ed97ASBdib7N/fP577h0wFX4z7qKT717T64b/ZsorH4FBjesr9cfKqx09dpfqVo1PfPYqco1v+QVlSv/68PPPwE \ No newline at end of file diff --git a/docs/design/images/Guard.svg b/docs/design/images/Guard.svg new file mode 100644 index 00000000..b9f95e8c --- /dev/null +++ b/docs/design/images/Guard.svg @@ -0,0 +1,3 @@ + + +
tosca.policies.Root
tosca.policies.Root
onap.policies.controlloop.guard.Common
onap.policies.controlloop.guard.Common
onap.policies.controlloop.guard.common.FrequencyLimiter
onap.policies.controlloop.guard.common.FrequencyLimiter
onap.policies.controlloop.guard.common.MinMax
onap.policies.controlloop.guard.common.MinMax
onap.policies.controlloop.guard.common.Blacklist
onap.policies.controlloop.guard.common.BlacklistViewer does not support full SVG 1.1 \ No newline at end of file diff --git a/docs/design/images/Operational.svg b/docs/design/images/Operational.svg new file mode 100644 index 00000000..8c356aca --- /dev/null +++ b/docs/design/images/Operational.svg @@ -0,0 +1,3 @@ + + +
tosca.policies.Root
tosca.policies.Root
onap.policies.controlloop.operational.Common
onap.policies.controlloop.operational.Common
onap.policies.controlloop.operational.common.Drools
onap.policies.controlloop.operational.common.Drools
onap.policies.controlloop.operational.common.Apex
onap.policies.controlloop.operational.common.ApexViewer does not support full SVG 1.1 \ No newline at end of file diff --git a/docs/design/images/Optimization.svg b/docs/design/images/Optimization.svg new file mode 100644 index 00000000..f1f9fc17 --- /dev/null +++ b/docs/design/images/Optimization.svg @@ -0,0 +1,3 @@ + + +
tosca.policies.Root
tosca.policies.Root
onap.policies.Optimization
onap.policies.Optimization
onap.policies.optimization.Service
onap.policies.optimization.Service
onap.policies.optimization.Resource
onap.policies.optimization.Resource
onap.policies.optimization.service.QueryPolicy
onap.policies.optimization.service.QueryPolicy
onap.policies.optimization.service.SubscriberPolicy
onap.policies.optimization.service.SubscriberPolicy
onap.policies.optimization.resource.AffinityPolicy
onap.policies.optimization.resource.AffinityPolicy
onap.policies.optimization.resource.DistancePolicy
onap.policies.optimization.resource.DistancePolicy
onap.policies.optimization.resource.HPAPolicy
onap.policies.optimization.resource.HPAPolicy
onap.policies.optimization.resource.OptimizationPolicy
onap.policies.optimization.resource.OptimizationPolicy
onap.policies.optimization.resource.PciPolicy
onap.policies.optimization.resource.PciPolicy
onap.policies.optimization.resource.Vim_fit
onap.policies.optimization.resource.Vim_fit
onap.policies.optimization.resource.VnfPolicy
onap.policies.optimization.resource.VnfPolicyViewer does not support full SVG 1.1 \ No newline at end of file diff --git a/docs/design/images/PolicyImplPDPSubGroup.svg b/docs/pap/images/PolicyImplPDPSubGroup.svg similarity index 100% rename from docs/design/images/PolicyImplPDPSubGroup.svg rename to docs/pap/images/PolicyImplPDPSubGroup.svg diff --git a/docs/pap/pap.rst b/docs/pap/pap.rst index 964712e6..ff6aac51 100644 --- a/docs/pap/pap.rst +++ b/docs/pap/pap.rst @@ -21,6 +21,64 @@ PDP group to arbitrarily appear and disappear and for policy consistency across maintained. The PAP is responsible for controlling the state across the PDPs in a PDP group. The PAP interacts with the policy database and transfers policies to PDPs. +The unit of execution and scaling in the Policy Framework is a *PolicyImpl* entity. A *PolicyImpl* entity runs on a PDP. +As is explained above, a *PolicyImpl* entity is a *PolicyTypeImpl* implementation parameterized with a TOSCA *Policy*. + +.. image:: images/PolicyImplPDPSubGroup.svg + +In order to achieve horizontal scalability, we group the PDPs running instances of a given *PolicyImpl* entity logically +together into a *PDPSubGroup*. The number of PDPs in a *PDPSubGroup* can then be scaled up and down using Kubernetes. In +other words, all PDPs in a subgroup run the same *PolicyImpl*, that is the same policy template implementation (in +XACML, Drools, or APEX) with the same parameters. + +The figure above shows the layout of *PDPGroup* and *PDPSubGroup* entities. The figure shows examples of PDP groups for +Control Loop and Monitoring policies on the right. + +The health of PDPs is monitored by the PAP in order to alert operations teams managing policies. The PAP manages the life +cycle of policies running on PDPs. + +The table below shows the deployment methods in which *PolicyImpl* entities can be deployed to PDP Subgroups. + +========== =========================================== ============================== ================================== +**Method** **Description** **Advantages** **Disadvantages** +========== =========================================== ============================== ================================== +Cold The *PolicyImpl* (*PolicyTypeImpl* and No run time configuration Very restrictive, no run time + TOSCA *Policy*) are predeployed on the PDP. required and run time configuration of PDPs is possible. + PDP is fully configured and ready to administration is simple. + execute when started. + + PDPs register with the PAP when they + start, providing the *pdpGroup* they + have been preconfigured with. + +Warm The *PolicyTypeImpl* entity is predeployed The configuration, parameters, Administration and management is + on the PDP. A TOSCA *Policy* may be loaded and PDP group of PDPs may be required. The configuration and + at startup. The PDP may be configured or changed at run time by loading life cycle of the TOSCA policies + reconfigured with a new or updated TOSCA or updating a TOSCA *Policy* can change at run time and must be + *Policy* at run time. into the PDP. administered and managed. + + PDPs register with the PAP when they start, Support TOSCA *Policy* entity + providing the *pdpGroup* they have been life cycle managgement is + predeployed with if any. The PAP may update supported, allowing features + the TOSCA *Policy* on a PDP at any time such as *PolicyImpl* Safe Mode + after registration. and *PolicyImpl* retirement. + +Hot The *PolicyImpl* (*PolicyTypeImpl* and The policy logic, rules, Administration and management is + TOSCA *Policy*) are deployed at run time. configuration, parameters, and more complex. The *PolicyImpl* + The *PolicyImpl* (*PolicyTypeImpl* and PDP group of PDPs may be itself and its configuration and + TOSCA *Policy*) may be loaded at startup. changed at run time by loading life cycle as well as the life + The PDP may be configured or reconfigured or updating a TOSCA *Policy* cycle of the TOSCA policies can + with a new or updated *PolicyTypeImpl* and *PolicyTypeImpl* into the change at run time and must be + and/or TOSCA *Policy* at run time. PDP. administered and managed. + + PDPs register with the PAP when they Lifecycle management of TOSCA + start, providing the *pdpGroup* they have *Policy* entities and + been preconfigured with if any. The PAP may *PolicyTypeImpl* entites is + update the TOSCA *Policy* and supported, allowing features + *PolicyTypeImpl* on a PDP at any time after such as *PolicyImpl* Safe Mode + registration and *PolicyImpl* retirement. +========== =========================================== ============================== ================================== + 1 APIs ====== diff --git a/docs/xacml/decision-api.rst b/docs/xacml/decision-api.rst index e0d4f446..e475e1dc 100644 --- a/docs/xacml/decision-api.rst +++ b/docs/xacml/decision-api.rst @@ -3,9 +3,11 @@ .. _decision-api-label: Decision API -####################### +############ -The Decision API is used by ONAP components that enforce policies and need a decision on which policy to enforce for a specific situation. The Decision API mimics closely the XACML request standard in that it supports a subject, action and resource. +The Decision API is used by ONAP components that enforce policies and need a decision on which policy to enforce for a +specific situation. The Decision API mimics closely the XACML request standard in that it supports a subject, action +and resource. .. csv-table:: :header: "Field", "Required", "XACML equivalent", "Description" diff --git a/docs/xacml/xacml.rst b/docs/xacml/xacml.rst index 1972a43c..f129a017 100644 --- a/docs/xacml/xacml.rst +++ b/docs/xacml/xacml.rst @@ -110,9 +110,14 @@ This is an example Decision API payload made to retrieve a decision for a Guard .. literalinclude:: decision.guard.json :language: JSON +.. _xacml-optimization-label: + Optimization Policy Types ========================= -These Policy Types are designed to be used by the OOF Project support several domains including VNF placement in ONAP. The OOF Platform makes a call to the Decision API to request these Policies based on the values specified in the onap.policies.Optimization properties. Each of these properties are treated relative to each other as an "AND". In addition, each value for each property itself is treated as an "OR". +These Policy Types are designed to be used by the OOF Project support several domains including VNF placement in ONAP. +The OOF Platform makes a call to the Decision API to request these Policies based on the values specified in the +onap.policies.Optimization properties. Each of these properties are treated relative to each other as an "AND". In +addition, each value for each property itself is treated as an "OR". .. csv-table:: :header: "Policy Type", "Action" @@ -130,7 +135,12 @@ These Policy Types are designed to be used by the OOF Project support several do "onap.policies.optimization.resource.Vim_fit", "optimize" "onap.policies.optimization.resource.VnfPolicy", "optimize" -The optimization application extends the StdMatchablePolicyTranslator in that the application applies a "closest match" algorithm internally after a XACML decision. This filters the results of the decision to return the one or more policies that match the incoming decision request as close as possible. In addition, there is special consideration for the Subscriber Policy Type. If a decision request contains subscriber context attributes, then internally the application will apply an initial decision to retrieve the scope of the subscriber. The resulting scope attributes are then added into a final internal decision call. +The optimization application extends the StdMatchablePolicyTranslator in that the application applies a "closest match" +algorithm internally after a XACML decision. This filters the results of the decision to return the one or more policies +that match the incoming decision request as close as possible. In addition, there is special consideration for the +Subscriber Policy Type. If a decision request contains subscriber context attributes, then internally the application +will apply an initial decision to retrieve the scope of the subscriber. The resulting scope attributes are then added +into a final internal decision call. This is an example Decision API payload made to retrieve a decision for an Optimization Policy Type. -- 2.16.6