docs/design/design.rst

   1 .. This work is licensed under a
   2 .. Creative Commons Attribution 4.0 International License.
   3 .. http://creativecommons.org/licenses/by/4.0
   4
   5 .. _design-label:
   6
   7 Policy Design and Development
   8 -----------------------------
   9
  10 .. contents::
  11     :depth: 3
  12
  13 The figure below shows the Artifacts (Blue) in the ONAP Policy
  14 Framework, the Activities (Yellow) that manipulate them, and important
  15 components (Pink) that interact with them.
  16
  17 .. image:: design.png
  18
  19 Please see the `TOSCA Policy
  20 Primer <tosca-label>`__ page for an
  21 introduction to TOSCA policy concepts.
  22
  23 TOSCA defines a *PolicyType*, the definition of a type of policy that
  24 can be applied to a service. It also defines a *Policy*, the definition
  25 of an instance of a *PolicyType*. In the Policy Framework, we must
  26 handle and manage these TOSCA definitions and tie them to real
  27 implementations of policies that can run on PDPs.
  28
  29 The diagram above outlines how this is achieved. Each TOSCA *PolicyType*
  30 must have a corresponding *PolicyTypeImpl* in the Policy Framework. The
  31 TOSCA \ *PolicyType* definition can be used to create a TOSCA *Policy*
  32 definition, either directly by the Policy Framework, by CLAMP, or by
  33 some other system. Once the \ *Policy* artifact exists, it can be used
  34 together with the *PolicyTypeImpl* artifact to create a *PolicyImpl*
  35 artifact. A *PolicyImpl* artifact is an executable policy implementation
  36 that can run on a PDP.
  37
  38 The TOSCA *PolicyType* artifact defines the external characteristics of
  39 the policy; defining its properties, the types of entities it acts on,
  40 and its triggers.  A *PolicyTypeImpl* artifact is an XACML, Drools, or
  41 APEX implementation of that policy definition. *PolicyType* and
  42 *PolicyTypeImpl* artifacts may be preloaded, may be loaded manually, or
  43 may be created using the Lifecycle API. Alternatively, *PolicyType*
  44 definitions may be loaded over the Lifecycle API for preloaded
  45 *PolicyTypeImpl* artifacts. A TOSCA *PolicyType* artifact can be used by
  46 clients (such as CLAMP or CLI tools) to create, parse, serialize, and/or
  47 deserialize an actual Policy.
  48
  49 The TOSCA *Policy* artifact is used internally by the Policy Framework,
  50 or is input by CLAMP or other systems. This artifact specifies the
  51 values of the properties for the policy and specifies the specific
  52 entities the policy acts on. Policy Design uses the TOSCA *Policy*
  53 artifact and the *PolicyTypeImpl* artifact to create an executable
  54 *PolicyImpl* artifact.
  55
  56 1 ONAP Policy Types
  57 ===================
  58
  59 Policy Type Design manages TOSCA *PolicyType* artifacts and their
  60 *PolicyTypeImpl* implementations\ *.*
  61
  62 *TOSCA PolicyType* may ultimately be defined by the modeling team but
  63 for now are defined by the Policy Framework project. Various editors and
  64 GUIs are available for creating *PolicyTypeImpl* implementations.
  65 However, systematic integration of *PolicyTypeImpl* implementation is
  66 outside the scope of the ONAP Dublin release.
  67
  68 The \ *PolicyType* definitions and implementations listed below are
  69 preloaded and are always available for use in the Policy Framework.
  70
  71 ====================================== ==================================================================================================
  72 **Policy Type**                        **Description**
  73 ====================================== ==================================================================================================
  74 onap.policies.Monitoring               Overarching model that supports Policy driven DCAE microservice components used in a Control Loops
  75 onap.policies.controlloop.Operational  Used to support actor/action operational policies for control loops
  76 onap.policies.controlloop.Guard        Control Loop guard policies for policing control loops
  77 onap.policies.controlloop.Coordination Control Loop Coordination policies to assist in coordinating multiple control loops at runtime
  78 ====================================== ==================================================================================================
  79
  80 1.1 onap.policies.Monitoring Policy Type
  81 ----------------------------------------
  82
  83 This is a base Policy Type that supports Policy driven DCAE microservice
  84 components used in a Control Loops. The implementation of this Policy
  85 Type is developed using the XACML PDP to support question/answer Policy
  86 Decisions during runtime for the DCAE Policy Handler.
  87
  88 **Base Policy Type definition for onap.policies.Monitoring**
  89
  90 .. codeblock:: yaml
  91
  92     tosca_definitions_version: tosca_simple_yaml_1_0_0
  93     topology_template:
  94         policy_types:
  95             - onap.policies.Monitoring:
  96                 derived_from: tosca.policies.Root
  97                 version: 1.0.0
  98                 description: a base policy type for all policies that govern monitoring provision
  99
 100 The \ *PolicyTypeImpl* implementation of the *onap.policies.Montoring*
 101 Policy Type is generic to support definition of TOSCA *PolicyType*
 102 artifacts in the Policy Framework using the Policy Type Design API.
 103 Therefore many TOSCA *PolicyType* artifacts will use the same
 104 *PolicyTypeImpl* implementation with different property types and
 105 towards different targets. This allows dynamically generated DCAE
 106 microservice component Policy Types to be created at Design Time.
 107
 108 DCAE microservice components can generate their own TOSCA \ *PolicyType*
 109 using TOSCA-Lab Control Loop guard policies in SDC (Stretch Goal) or can
 110 do so manually. See `How to generate artefacts for SDC catalog using
 111 Tosca Lab
 112 Tool <file://localhost/display/DW/How+to+generate+artefacts+for+SDC+catalog+using+Tosca+Lab+Tool>`__
 113 for details on TOSCA-LAB in SDC. For Dublin, the DCAE team is defining
 114 the manual steps required to build policy models \ `Onboarding steps for
 115 DCAE MS through SDC/Policy/CLAMP
 116 (Dublin) <file://localhost/pages/viewpage.action%3fpageId=60883710>`__.
 117
 118 NOTE: For Dublin, mS Policy Types will be pre-loaded into the SDC
 119 platform and be available as a Normative. The policy framework will
 120 pre-load support for those mS Monitoring policy types.
 121
 122
 123 End of Document
 124