Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 1 | .. This work is licensed under a |
| 2 | .. Creative Commons Attribution 4.0 International License. |
| 3 | .. http://creativecommons.org/licenses/by/4.0 |
| 4 | |
Pamela Dragosh | 9fcabd0 | 2020-05-13 07:54:15 -0400 | [diff] [blame] | 5 | .. DO NOT REMOVE THIS LABEL - EVEN IF IT GENERATES A WARNING |
| 6 | .. _architecture: |
| 7 | |
| 8 | .. THIS IS USED INTERNALLY IN POLICY ONLY |
liamfallon | 4d1d983 | 2019-05-30 20:53:05 +0000 | [diff] [blame] | 9 | .. _architecture-label: |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 10 | |
Pamela Dragosh | 5f3716b | 2019-06-03 12:19:22 -0400 | [diff] [blame] | 11 | Policy Framework Architecture |
| 12 | ############################# |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 13 | |
| 14 | Abstract |
| 15 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 16 | This document describes the ONAP Policy Framework. It lays out the architecture of the framework and shows the APIs |
| 17 | provided to other components that interwork with the framework. It describes the implementation of the framework, |
| 18 | mapping out the components, software structure, and execution ecosystem of the framework. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 19 | |
| 20 | .. contents:: |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 21 | :depth: 6 |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 22 | |
Pamela Dragosh | 6eec875 | 2020-05-21 11:06:03 -0400 | [diff] [blame] | 23 | .. toctree:: |
| 24 | :caption: References |
| 25 | :maxdepth: 1 |
| 26 | |
| 27 | tosca-policy-primer |
| 28 | |
| 29 | |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 30 | 1. Overview |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 31 | =========== |
| 32 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 33 | The ONAP Policy Framework is a comprehensive policy design, deployment, and execution environment. The Policy Framework |
| 34 | is the decision making component in `an ONAP system |
| 35 | <https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_Architecture_112918FNL.pdf>`__. |
| 36 | It allows you to specify, deploy, and execute the governance of the features and functions in your ONAP system, be they |
| 37 | closed loop, orchestration, or more traditional open loop use case implementations. The Policy Framework is the |
| 38 | component that is the source of truth for all policy decisions. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 39 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 40 | One of the most important goals of the Policy Framework is to support Policy Driven Operational Management during the |
| 41 | execution of ONAP control loops at run time. In addition, use case implementations such as orchestration and control |
| 42 | benefit from the ONAP policy Framework because they can use the capabilities of the framework to manage and execute |
| 43 | their policies rather than embedding the decision making in their applications. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 44 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 45 | The Policy Framework is deployment agnostic, it manages Policy Execution (in PDPs) and Enforcement (in PEPs) regardless |
liamfallon | c5d11f0 | 2020-04-07 12:41:34 +0100 | [diff] [blame] | 46 | of how the PDPs and PEPs are deployed. This allows policy execution and enforcement to be deployed in a manner that |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 47 | meets the performance requirements of a given application or use case. In one deployment, policy execution could be |
| 48 | deployed in a separate executing entity in a Docker container. In another, policy execution could be co-deployed with |
| 49 | an application to increase performance. An example of co-deployment is the Drools PDP Control Loop image, which is a |
| 50 | Docker image that combines the ONAP Drools use case application and dependencies with the Drools PDP engine. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 51 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 52 | The ONAP Policy Framework architecture separates policies from the platform that is supporting them. The framework |
| 53 | supports development, deployment, and execution of any type of policy in ONAP. The Policy Framework is metadata (model) |
| 54 | driven so that policy development, deployment, and execution is as flexible as possible and can support modern rapid |
liamfallon | c5d11f0 | 2020-04-07 12:41:34 +0100 | [diff] [blame] | 55 | development ways of working such as `DevOps |
| 56 | <https://en.wikipedia.org/wiki/DevOps>`__. A metadata driven approach also allows the amount of programmed support |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 57 | required for policies to be reduced or ideally eliminated. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 58 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 59 | We have identified five capabilities as being essential for the framework: |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 60 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 61 | 1. Most obviously, the framework must be capable of being triggered by an event or invoked, and making decisions at run |
| 62 | time. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 63 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 64 | 2. It must be deployment agnostic; capable of managing policies for various Policy Decision Points (PDPs) or policy |
| 65 | engines. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 66 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 67 | 3. It must be metadata driven, allowing policies to be deployed, modified, upgraded, and removed as the system executes. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 68 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 69 | 4. It must provide a flexible model driven policy design approach for policy type programming and specification of |
| 70 | policies. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 71 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 72 | 5. It must be extensible, allowing straightforward integration of new PDPs, policy formats, and policy development |
| 73 | environments. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 74 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 75 | Another important aim of the architecture of a model driven policy framework is that it enables much more flexible |
| 76 | policy specification. The ONAP Policy Framework complies with the `TOSCA |
| 77 | <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.1/TOSCA-Simple-Profile-YAML-v1.1.pdf>`__ modelling |
| 78 | approach for policies, see the :ref:`TOSCA Policy Primer <tosca-label>` for more information on how policies are modeled |
| 79 | in TOSCA. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 80 | |
liamfallon | c5d11f0 | 2020-04-07 12:41:34 +0100 | [diff] [blame] | 81 | 1. A *Policy Type* describes the properties, targets, and triggers that the policy for a feature can have. A Policy type is |
| 82 | implementation independent. It is the metadata that specifies: |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 83 | |
liamfallon | c5d11f0 | 2020-04-07 12:41:34 +0100 | [diff] [blame] | 84 | - the *configuration* data that the policy can take. The Policy Type describes each property that a policy of a |
| 85 | given type can take. A Policy Type definition also allows the default value, optionality, and the ranges of properties |
| 86 | to be defined. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 87 | |
liamfallon | c5d11f0 | 2020-04-07 12:41:34 +0100 | [diff] [blame] | 88 | - the *targets* such as network element types, functions, services, or resources on which a policy of the given type |
| 89 | can act. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 90 | |
liamfallon | c5d11f0 | 2020-04-07 12:41:34 +0100 | [diff] [blame] | 91 | - the *triggers* such as the event type, filtered event, scheduled trigger, or conditions that can activate a policy |
| 92 | of the given type. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 93 | |
liamfallon | c5d11f0 | 2020-04-07 12:41:34 +0100 | [diff] [blame] | 94 | Policy Types are hierarchical, A Policy Type can inherit from a parent Policy Type, inheriting the properties, targets, |
| 95 | and triggers of its parent. Policy Types are developed by domain experts in consultation with the developers that |
| 96 | implement the logic and rules for the Policy Type. |
| 97 | |
| 98 | 2. A *Policy* is defined using a Policy Type. The Policy defines: |
| 99 | |
| 100 | - the values for each property of the policy type |
| 101 | - the specific targets (network elements, functions, services, resources) on which this policy will act |
| 102 | - the specific triggers that trigger this policy. |
| 103 | |
| 104 | 3. A *Policy Type Implementation* or *Raw Policy*, is the logic that implements the policy. It is implemented by a |
| 105 | skilled policy developer in consultation with domain experts. The implementation has software that reads the Policy |
liamfallon | 091a226 | 2020-04-09 08:13:45 +0100 | [diff] [blame] | 106 | Type and parses the incoming configuration properties. The software has domain logic that is triggered when one of the |
liamfallon | c5d11f0 | 2020-04-07 12:41:34 +0100 | [diff] [blame] | 107 | triggers described in the Policy Type occurs. The software logic executes and acts on the targets specified in the |
| 108 | Policy Type. |
| 109 | |
| 110 | |
| 111 | For example, a Policy Type could be written to describe how to manage Service Level Agreements for VPNs. The VPN Policy |
| 112 | Type can be used to create VPN policies for a bank network, a car dealership network, or a university with many campuses. |
| 113 | The Policy Type has two parameters: |
| 114 | |
| 115 | - The *maximumDowntime* parameter allows the maximum downtime allowed per year to be specified |
| 116 | - The *mitigationStrategy* parameter allows one of three strategies to be selected for downtime breaches |
| 117 | |
| 118 | - *allocateMoreResources*, which will automatically allocate more resources to mitigate the problem |
| 119 | - *report*, which report the downtime breach to a trouble ticketing system |
| 120 | - *ignore*, which logs the breach and takes no further action |
| 121 | |
| 122 | The Policy Type defines a trigger event, an event that is received from an analytics system when the maximum downtime |
| 123 | value for a VPN is breached. The target of the policy type is an instance of the VPN service. |
| 124 | |
| 125 | The Policy Type Implementation is developed that can configure the maximum downtime parameter in an analytics system, |
| 126 | can receive a trigger from the analytics system when the maximum downtime is breached, and that can either request more |
| 127 | resources, report an issue to a trouble ticketing system, and can log a breach. |
| 128 | |
liamfallon | 1c7c520 | 2020-04-14 13:42:34 +0100 | [diff] [blame] | 129 | VPN Policies are created by specifying values for the properties, triggers, and targets specified in VPN Policy Type. |
liamfallon | c5d11f0 | 2020-04-07 12:41:34 +0100 | [diff] [blame] | 130 | |
| 131 | In the case of the bank network, the *maximumDowntime* threshold is specified as 5 minutes downtime per year and the |
| 132 | *mitigationStrategy* is defined as *allocateMoreResources*, and the target is specified as being the bank's VPN service |
| 133 | ID. When a breach is detected by the analytics system, the policy is executed, the target is identified as being the |
| 134 | bank's network, and more resources are allocated by the policy. |
| 135 | |
| 136 | For the car dealership VPN policy, a less stringent downtime threshold of 60 minutes per year is specified, and the |
| 137 | mitigation strategy is to issue a trouble ticket. The university network is best effort, so a downtime of 4 days per |
| 138 | year is specified. Breaches are logged and mitigated as routine network administration tasks. |
| 139 | |
| 140 | In ONAP, specific ONAP Policy Types are used to create specific policies that drive the ONAP Platform and Components. |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 141 | For more detailed information on designing Policy Types and developing an implementation for that policy type, see |
| 142 | :ref:`Policy Design and Development <design-label>`. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 143 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 144 | The ONAP Policy Framework for building, configuring and deploying PDPs is extendable. It allows the use of ONAP PDPs as |
| 145 | is, the extension of ONAP PDPs, and lastly provides the capability for users to create and deploy their own PDPs. The |
| 146 | ONAP Policy Framework provides distributed policy management for **all** policies in ONAP at run time. Not only does |
| 147 | this provide unified policy access and version control, it provides life cycle control for policies and allows detection |
| 148 | of conflicts across all policies running in an ONAP installation. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 149 | |
| 150 | 2. Architecture |
| 151 | =============== |
| 152 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 153 | The diagram below shows the architecture of the ONAP Policy Framework at its highest level. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 154 | |
liamfallon | 4d1d983 | 2019-05-30 20:53:05 +0000 | [diff] [blame] | 155 | .. image:: images/PFHighestLevel.svg |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 156 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 157 | The *PolicyDevelopment* component implements the functionality for development of policy types and policies. |
| 158 | *PolicyAdministration* is responsible for the deployment life cycle of policies as well as interworking with the |
| 159 | mechanisms required to orchestrate the nodes and containers on which policies run. *PolicyAdministration* is also |
| 160 | responsible for the administration of policies at run time; ensuring that policies are available to users, that policies |
| 161 | are executing correctly, and that the state and status of policies is monitored. *PolicyExecution* is the set of PDPs |
| 162 | running in the ONAP system and is responsible for making policy decisions and for managing the administrative state of |
| 163 | the PDPs as directed by \ *PolicyAdministration.* |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 164 | |
liamfallon | 091a226 | 2020-04-09 08:13:45 +0100 | [diff] [blame] | 165 | *PolicyDevelopment* provides APIs that allow creation of policy artifacts and supporting information in the policy |
| 166 | database. *PolicyAdministration* reads those artifacts and the supporting information from the policy database whilst |
| 167 | deploying policy artifacts. Once the policy artifacts are deployed, *PolicyAdministration* handles the run-time |
| 168 | management of the PDPs on which the policies are running. *PolicyDevelopment* interacts with the database, and has |
| 169 | no programmatic interface with *PolicyAdministration*, *PolicyExecution* or any other run-time ONAP components. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 170 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 171 | The diagram below shows a more detailed view of the architecture, as inspired by |
| 172 | `RFC-2753 <https://tools.ietf.org/html/rfc2753>`__ and `RFC-3198 <https://tools.ietf.org/html/rfc3198>`__. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 173 | |
liamfallon | 4d1d983 | 2019-05-30 20:53:05 +0000 | [diff] [blame] | 174 | .. image:: images/PFDesignAndAdmin.svg |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 175 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 176 | *PolicyDevelopment* provides a `CRUD <https://en.wikipedia.org/wiki/Create,_read,_update_and_delete>`__ API for policy |
liamfallon | 091a226 | 2020-04-09 08:13:45 +0100 | [diff] [blame] | 177 | types and policies. The policy types and policy artifacts and their metadata (information about policies, policy types, |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 178 | and their interrelations) are stored in the *PolicyDB*. The *PolicyDevGUI*, PolicyDistribution, and other applications |
liamfallon | 091a226 | 2020-04-09 08:13:45 +0100 | [diff] [blame] | 179 | such as *CLAMP* can use the *PolicyDevelopment* API to create, update, delete, and read policy types and policies. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 180 | |
| 181 | *PolicyAdministration* has two important functions: |
| 182 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 183 | - Management of the life cycle of PDPs in an ONAP installation. PDPs register with *PolicyAdministration* when they come |
liamfallon | 091a226 | 2020-04-09 08:13:45 +0100 | [diff] [blame] | 184 | up. *PolicyAdministration* handles the allocation of PDPs to PDP Groups and PDP Subgroups, so that they can be |
| 185 | managed as microservices in infrastructure management systems such as Kubernetes. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 186 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 187 | - Management of the deployment of policies to PDPs in an ONAP installation. *PolicyAdministration* gives each PDP group |
| 188 | a set of domain policies to execute. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 189 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 190 | *PolicyAdministration* handles PDPs and policy allocation to PDPs using asynchronous messaging over DMaaP. It provides |
| 191 | three APIs: |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 192 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 193 | - a CRUD API for policy groups and subgroups |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 194 | |
liamfallon | 091a226 | 2020-04-09 08:13:45 +0100 | [diff] [blame] | 195 | - an API that allows the allocation of policies to PDP groups and subgroups to be controlled |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 196 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 197 | - an API allows policy execution to be managed, showing the status of policy execution on PDP Groups, subgroups, and |
| 198 | individual PDPs as well as the life cycle state of PDPs |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 199 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 200 | *PolicyExecution* is the set of running PDPs that are executing policies, logically partitioned into PDP groups and |
| 201 | subgroups. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 202 | |
liamfallon | 4d1d983 | 2019-05-30 20:53:05 +0000 | [diff] [blame] | 203 | .. image:: images/PolicyExecution.svg |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 204 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 205 | The figure above shows how *PolicyExecution* looks at run time with PDPs running in Kubernetes. A *PDPGroup* is a purely |
| 206 | logical construct that collects all the PDPs that are running policies for a particular domain together. A *PDPSubGroup* |
| 207 | is a group of PDPs of the same type that are running the same policies. *A PDPSubGroup* is deployed as a Kubernetes |
| 208 | `Deployment <https://kubernetes.io/docs/concepts/workloads/controllers/deployment/>`__. PDPs are defined as Kubernetes |
| 209 | `Pods <https://kubernetes.io/docs/concepts/workloads/pods/pod/>`__. At run time, the actual number of PDPs in each |
| 210 | *PDPSubGroup* is specified in the configuration of the *Deployment* of that *PDPSubGroup* in Kubernetes. This |
| 211 | structuring of PDPs is required because, in order to simplify deployment and scaling of PDPs in Kubernetes, we gather |
| 212 | all the PDPs of the same type that are running the same policies together for deployment. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 213 | |
liamfallon | 091a226 | 2020-04-09 08:13:45 +0100 | [diff] [blame] | 214 | For example, assume we have policies for the SON (Self Organizing Network) and ACPS (Advanced Customer Premises Service) |
| 215 | domains. For SON,we have XACML, Drools, and APEX policies, and for ACPS we have XACML and Drools policies. The table |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 216 | below shows the resulting \ *PDPGroup*, *PDPSubGroup*, and PDP allocations: |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 217 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 218 | ============= ================ ========================= ======================================== ================ |
| 219 | **PDP Group** **PDP Subgroup** **Kubernetes Deployment** **Kubernetes Deployment Strategy** **PDPs in Pods** |
| 220 | ============= ================ ========================= ======================================== ================ |
| 221 | SON SON-XACML SON-XACML-Dep Always 2, be geo redundant 2 PDP-X |
| 222 | \ SON-Drools SON-Drools-Dep At Least 4, scale up on 70% load, >= 4 PDP-D |
| 223 | scale down on 40% load, be geo-redundant |
| 224 | \ SON-APEX SON-APEX-Dep At Least 3, scale up on 70% load, scale >= 3 PDP-A |
| 225 | down on 40% load, be geo-redundant |
liamfallon | 091a226 | 2020-04-09 08:13:45 +0100 | [diff] [blame] | 226 | ACPS ACPS-XACML ACPS-XACML-Dep Always 2 2 PDP-X |
| 227 | \ ACPS-Drools ACPS-Drools-Dep At Least 2, scale up on 80% load, scale >=2 PDP-D |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 228 | down on 50% load |
| 229 | ============= ================ ========================= ======================================== ================ |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 230 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 231 | For more details on *PolicyAdministration* APIs and management of *PDPGroup* and *PDPSubGroup*, see the documentation |
| 232 | for :ref:`Policy Administration Point (PAP) Architecture <pap-label>`. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 233 | |
| 234 | 2.1 Policy Framework Object Model |
| 235 | --------------------------------- |
| 236 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 237 | This section describes the structure of and relations between the main concepts in the Policy Framework. This model is |
| 238 | implemented as a common model and is used by *PolicyDevelopment*, *PolicyDeployment,* and *PolicyExecution.* |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 239 | |
liamfallon | 4d1d983 | 2019-05-30 20:53:05 +0000 | [diff] [blame] | 240 | .. image:: images/ClassStructure.svg |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 241 | |
liamfallon | 091a226 | 2020-04-09 08:13:45 +0100 | [diff] [blame] | 242 | The UML class diagram above shows thePolicy Framework Object Model. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 243 | |
| 244 | 2.2 Policy Design Architecture |
| 245 | ------------------------------ |
| 246 | |
liamfallon | 1c7c520 | 2020-04-14 13:42:34 +0100 | [diff] [blame] | 247 | This section describes the architecture of the model driven system used to develop policy types and to create |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 248 | policies using policy types. The output of Policy Design is deployment-ready artifacts and Policy metadata in the Policy |
| 249 | Framework database. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 250 | |
liamfallon | 1c7c520 | 2020-04-14 13:42:34 +0100 | [diff] [blame] | 251 | Policy types that are expressed via natural language or a model require an implementation that allows them to be |
| 252 | translated into runtime policies. Some Policy Type implementations are set up and available in the platform during |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 253 | startup such as Control Loop Operational Policy Models, OOF placement Models, DCAE microservice models. Policy type |
liamfallon | 1c7c520 | 2020-04-14 13:42:34 +0100 | [diff] [blame] | 254 | implementations can also be loaded and deployed at run time. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 255 | |
| 256 | 2.2.1 Policy Type Design |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 257 | ^^^^^^^^^^^^^^^^^^^^^^^^ |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 258 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 259 | Policy Type Design is the task of creating policy types that capture the generic and vendor independent aspects of a |
liamfallon | 1c7c520 | 2020-04-14 13:42:34 +0100 | [diff] [blame] | 260 | policy for a particular domain use case. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 261 | |
liamfallon | 1c7c520 | 2020-04-14 13:42:34 +0100 | [diff] [blame] | 262 | All policy types are specified in TOSCA service templates. Once policy types are defined and created in the system, |
liamfallon | 091a226 | 2020-04-09 08:13:45 +0100 | [diff] [blame] | 263 | *PolicyDevelopment* manages them and uses them to allow policies to be created from these policy types in a uniform |
| 264 | way regardless of the domain that the policy type is addressing or the PDP technology that will execute the policy. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 265 | |
liamfallon | 091a226 | 2020-04-09 08:13:45 +0100 | [diff] [blame] | 266 | A *PolicyTypeImpl* is developed for a policy type for a certain type of PDP (for example XACML oriented for decision |
| 267 | policies, Drools rules or Apex state machines oriented for ECA policies). While a policy type is implementation |
| 268 | independent, a policy type implementation for a policy type is specific for the technology of the PDP on which |
liamfallon | 1c7c520 | 2020-04-14 13:42:34 +0100 | [diff] [blame] | 269 | policies that use that policy type implementation will execute. A Policy Type may have many implementations. A |
| 270 | *PolicyTypeImpl* is the specification of the specific rules or tasks, the flow of the policy, its internal states |
| 271 | and data structures and other relevant information. A *PolicyTypeImpl* can be specific to a particular policy type |
| 272 | or it can be more general, providing the implementation of a class of policy types. Further, the design environment |
| 273 | and tool chain for implementing implementations of policy types is specific to the technology of the PDP on which |
| 274 | the implementation will run. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 275 | |
liamfallon | 3602c18 | 2020-04-16 09:29:45 +0100 | [diff] [blame] | 276 | In the *xacml-pdp* and *drools-pdp*, an *application* is written for a given category of policy types. Such an |
| 277 | application may have logic written in Java or another programming language, and may have additional artifacts such |
| 278 | as scripts and SQL queries. The *application* unmarshals and marshals events going into and out of policies as well |
| 279 | as handling the sequencing of events for interactions of the policies with other components in ONAP. For example, |
| 280 | *drools-applications* handles the interactions for operational policies running in the drools PDP. In the |
| 281 | *apex-pdp*, all unmarshaling, marshaling, and component interactions are captured in the state machine, logic, and |
| 282 | configuraiton of the policy, a Java application is not used. |
| 283 | |
liamfallon | 091a226 | 2020-04-09 08:13:45 +0100 | [diff] [blame] | 284 | *PolicyDevelopment* provides the RESTful :ref:`Policy Design API <design-label>`, which allows other components to query |
| 285 | policy types, Those components can then create policies that specify values for the properties, triggers, and targets |
| 286 | specified in a policy type. This API is used by components such as *CLAMP* and *PolicyDistribution* to create policies |
| 287 | from policy types. |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 288 | |
| 289 | Consider a policy type created for managing faults on vCPE equipment in a vendor independent way. The policy type |
liamfallon | 091a226 | 2020-04-09 08:13:45 +0100 | [diff] [blame] | 290 | implementation captures the generic logic required to manage the faults and specifies the vendor specific information |
| 291 | that must be supplied to the type for specific vendor vCPE VFs. The actual vCPE policy that is used for managing |
| 292 | particular vCPE equipment is created by setting the properties specified in the policy type for that vendor model |
| 293 | of vCPE. |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 294 | |
| 295 | 2.2.1.1 Generating Policy Types |
| 296 | """"""""""""""""""""""""""""""" |
| 297 | |
| 298 | It is possible to generate policy types using MDD (Model Driven Development) techniques. Policy types are expressed |
| 299 | using a DSL (Domain Specific Language) or a policy specification environment for a particular application domain. For |
| 300 | example, policy types for specifying SLAs could be expressed in a SLA DSL and policy types for managing SON features |
| 301 | could be generated from a visual SON management tool. The ONAP Policy framework provides an API that allows tool chains |
liamfallon | 1c7c520 | 2020-04-14 13:42:34 +0100 | [diff] [blame] | 302 | to create policy types, see the :ref:`Policy Design and Development <design-label>` page. |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 303 | |
| 304 | .. image:: images/PolicyTypeDesign.svg |
| 305 | |
liamfallon | 1c7c520 | 2020-04-14 13:42:34 +0100 | [diff] [blame] | 306 | A GUI implementation in another ONAP component (a *PolicyTypeDesignClient*) may use the *API_User* API to create and |
| 307 | edit ONAP policy types. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 308 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 309 | 2.2.1.2 Programming Policy Type Implementations |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 310 | """"""""""""""""""""""""""""""""""""""""""""""" |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 311 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 312 | For skilled developers, the most straightforward way to create a policy type is to program it. Programming a policy type |
| 313 | might simply mean creating and editing text files, thus manually creating the TOSCA Policy Type YAML file and the policy |
| 314 | type implementation for the policy type. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 315 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 316 | A more formal approach is preferred. For policy type implementations, programmers use a specific Eclipse project type |
| 317 | for developing each type of implementation, a Policy Type Implementation SDK. The project is under source control in |
| 318 | git. This Eclipse project is structured correctly for creating implementations for a specific type of PDP. It includes |
| 319 | the correct POM files for generating the policy type implementation and has editors and perspectives that aid |
| 320 | programmers in their work |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 321 | |
| 322 | 2.2.2 Policy Design |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 323 | ^^^^^^^^^^^^^^^^^^^ |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 324 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 325 | The *PolicyCreation* function of *PolicyDevelopment* creates policies from a policy type. The information expressed |
| 326 | during policy type design is used to parameterize a policy type to create an executable policy. A service designer |
| 327 | and/or operations team can use tooling that reads the TOSCA Policy Type specifications to express and capture a policy |
| 328 | at its highest abstraction level. Alternatively, the parameter for the policy can be expressed in a raw JSON or YAML |
| 329 | file and posted over the policy design API described on the :ref:`Policy Design and Development <design-label>` page. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 330 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 331 | A number of mechanisms for policy creation are supported in ONAP. The process in *PolicyDevelopment* for creating a |
| 332 | policy is the same for all mechanisms. The most general mechanism for creating a policy is using the RESTful |
| 333 | *Policy Design API*, which provides a full interface to the policy creation support of *PolicyDevelopment*. This API may |
liamfallon | 1c7c520 | 2020-04-14 13:42:34 +0100 | [diff] [blame] | 334 | be exercised directly using utilities such as *curl*. |
| 335 | |
| 336 | In future releases, the Policy Framework may provide a command line tool that will be a loose wrapper around the API. It |
| 337 | may also provide a general purpose Policy GUI in the ONAP Portal for policy creation, which again would be a general |
| 338 | purpose wrapper around the policy creation API. The Policy GUI would interpret any TOSCA Model that has been loaded into |
| 339 | it and flexibly presents a GUI for a user to create policies from. The development of these mechanisms will be phased |
| 340 | over a number of ONAP releases. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 341 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 342 | A number of ONAP components use policy in manners which are specific to their particular needs. The manner in which the |
| 343 | policy creation process is triggered and the way in which information required to create a policy is specified and |
| 344 | accessed is specialized for these ONAP components. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 345 | |
liamfallon | 1c7c520 | 2020-04-14 13:42:34 +0100 | [diff] [blame] | 346 | For example, *CLAMP* provides a GUI for creation of Control Loop policies, which reads the Policy Type associated |
| 347 | with a control loop, presents the properties as fields in its GUI, and creates a policy using the property values entered |
| 348 | by the user. |
| 349 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 350 | The following subsections outline the mechanisms for policy creation and modification supported by the ONAP Policy |
| 351 | Framework. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 352 | |
| 353 | 2.2.2.1 Policy Design in the ONAP Policy Framework |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 354 | """""""""""""""""""""""""""""""""""""""""""""""""" |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 355 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 356 | Policy creation in *PolicyDevelopment* follows the general sequence shown in the sequence diagram below. An *API_USER* |
| 357 | is any component that wants to create a policy from a policy type. *PolicyDevelopment* supplies a REST interface that |
| 358 | exposes the API and also provides a command line tool and general purpose client that wraps the API. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 359 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 360 | .. image:: images/PolicyDesign.svg |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 361 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 362 | An *API_User* first gets a reference to and the metadata for the Policy type for the policy they want to work on from |
| 363 | *PolicyDevelopment*. *PolicyDevelopment* reads the metadata and artifact for the policy type from the database. The |
| 364 | *API_User* then asks for a reference and the metadata for the policy. *PolicyDevelopment* looks up the policy in the |
| 365 | database. If the policy already exists, *PolicyDevelopment* reads the artifact and returns the reference of the existing |
| 366 | policy to the *API_User* with the metadata for the existing policy. If the policy does not exist, *PolicyDevelopment* |
liamfallon | 1c7c520 | 2020-04-14 13:42:34 +0100 | [diff] [blame] | 367 | informs the *API_User*. |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 368 | |
| 369 | The *API_User* may now proceed with a policy specification session, where the parameters are set for the policy using |
| 370 | the policy type specification. Once the *API_User* is happy that the policy is completely and correctly specified, it |
| 371 | requests *PolicyDevelopment* to create the policy. *PolicyDevelopment* creates the policy, stores the created policy |
| 372 | artifact and its metadata in the database. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 373 | |
| 374 | 2.2.2.2 Model Driven VF (Virtual Function) Policy Design via VNF SDK Packaging |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 375 | """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 376 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 377 | VF vendors express policies such as SLA, Licenses, hardware placement, run-time metric suggestions, etc. These details |
| 378 | are captured within the VNF SDK and uploaded into the SDC Catalog. The `SDC Distribution APIs |
| 379 | <https://wiki.onap.org/display/DW/SDC+Distribution+client+AID>`__ are used to interact with SDC. For example, SLA and |
| 380 | placement policies may be captured via TOSCA specification. License policies can be captured via TOSCA or an XACML |
| 381 | specification. Run-time metric vendor recommendations can be captured via the VES Standard specification. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 382 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 383 | The sequence diagram below is a high level view of SDC-triggered concrete policy generation for some arbitrary entity |
| 384 | *EntityA*. The parameters to create a policy are read from a TOSCA Policy specification read from a CSAR received from |
| 385 | SDC. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 386 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 387 | .. image:: images/ModelDrivenPolicyDesign.svg |
| 388 | |
| 389 | *PolicyDesign* uses the *PolicyDistribution* component for managing SDC-triggered policy creation and update requests. |
| 390 | *PolicyDistribution* is an *API_User*, it uses the Policy Design API for policy creation and update. It reads the |
| 391 | information it needs to populate the policy type from a TOSCA specification in a CSAR received from SDC and then uses |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 392 | this information to automatically generate a policy. |
| 393 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 394 | Note that SDC provides a wrapper for the SDC API as a Java Client and also provides a TOSCA parser. See the |
| 395 | documentation for the `Policy Distribution Component |
Jim Hahn | 182f20f | 2021-03-30 15:02:36 -0400 | [diff] [blame] | 396 | <https://docs.onap.org/projects/onap-policy-parent/en/honolulu/distribution/distribution.html>`__. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 397 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 398 | In Step 4 above, the \ *PolicyDesign* must download the CSAR file. If the policy is to be composed from the TOSCA |
| 399 | definition, it must also parse the TOSCA definition. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 400 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 401 | In Step 11 above, the \ *PolicyDesign* must send back/publish status events to SDC such as DOWNLOAD_OK, DOWNLOAD_ERROR, |
| 402 | DEPLOY_OK, DEPLOY_ERROR, NOTIFIED. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 403 | |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 404 | 2.2.2.3 Scripted Model Driven Policy Design |
| 405 | """"""""""""""""""""""""""""""""""""""""""" |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 406 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 407 | Service policies such as optimization and placement policies can be specified as a TOSCA Policy at design time. These |
| 408 | policies use a TOSCA Policy Type specification as their schemas. Therefore, scripts can be used to create TOSCA policies |
| 409 | using TOSCA Policy Types. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 410 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 411 | .. image:: images/ScriptedPolicyDesign.svg |
| 412 | |
liamfallon | 1c7c520 | 2020-04-14 13:42:34 +0100 | [diff] [blame] | 413 | One straightforward way of generating policies from Policy types is to use commands specified in a script file. A |
| 414 | command line utility such as *curl* is an *API_User*. Commands read policy types using the Policy Type API, parse the |
| 415 | policy type and uses the properties of the policy type to prepare a TOSCA Policy. It then issues further commands to use |
| 416 | the Policy API to create policies. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 417 | |
| 418 | 2.2.3 Policy Design Process |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 419 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 420 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 421 | All policy types must be certified as being fit for deployment prior to run time deployment. Where design is executed |
| 422 | using the SDC application, it is assumed the life cycle being implemented by SDC certifies any policy types that |
| 423 | are declared within the ONAP Service CSAR. For other policy types and policy type implementations, the life cycle |
| 424 | associated with the applied software development process suffices. Since policy types and their implementations are |
| 425 | designed and implemented using software development best practices, they can be utilized and configured for various |
| 426 | environments (eg. development, testing, production) as desired. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 427 | |
| 428 | 2.3 Policy Runtime Architecture |
| 429 | ------------------------------- |
| 430 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 431 | The Policy Framework Platform components are themselves designed as microservices that are easy to configure and deploy |
| 432 | via Docker images and K8S both supporting resiliency and scalability if required. PAPs and PDPs are deployed by the |
| 433 | underlying ONAP management infrastructure and are designed to comply with the ONAP interfaces for deploying containers. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 434 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 435 | The PAPs keep track of PDPs, support the deployment of PDP groups and the deployment of a *policy set* across those PDP |
| 436 | groups. A PAP is stateless in a RESTful sense. Therefore, if there is more than one PAP deployed, it does not matter |
| 437 | which PAP a user contacts to handle a request. The PAP uses the database (persistent storage) to keep track of ongoing |
liamfallon | 3602c18 | 2020-04-16 09:29:45 +0100 | [diff] [blame] | 438 | sessions with PDPs. Policy management on PDPs is the responsibility of PAPs; management of policy sets or policies by |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 439 | any other manner is not permitted. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 440 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 441 | In the ONAP Policy Framework, the interfaces to the PDP are designed to be as streamlined as possible. Because the PDP |
| 442 | is the main unit of scalability in the Policy Framework, the framework is designed to allow PDPs in a PDP group to |
| 443 | arbitrarily appear and disappear and for policy consistency across all PDPs in a PDP group to be easily maintained. |
| 444 | Therefore, PDPs have just two interfaces; an interface that users can use to execute policies and interface to the PAP |
| 445 | for administration, life cycle management and monitoring. The PAP is responsible for controlling the state across the |
| 446 | PDPs in a PDP group. The PAP interacts with the Policy database and transfers policy sets to PDPs, and may cache the |
| 447 | policy sets for PDP groups. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 448 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 449 | See also Section 2 of the :ref:`Policy Design and Development <design-label>` page, where the mechanisms for PDP |
| 450 | Deployment and Registration with PAP are explained. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 451 | |
| 452 | 2.3.1 Policy Framework Services |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 453 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 454 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 455 | The ONAP Policy Framework follows the architectural approach for microservices recommended by the `ONAP Architecture |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 456 | Subcommittee <https://wiki.onap.org/display/DW/Architecture+Subcommittee>`__. |
| 457 | |
liamfallon | 3602c18 | 2020-04-16 09:29:45 +0100 | [diff] [blame] | 458 | The ONAP Policy Framework uses an infrastructure such as Kubernetes `Services |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 459 | <https://kubernetes.io/docs/concepts/services-networking/service/>`__ to manage the life cycle of Policy Framework |
| 460 | executable components at runtime. A Kubernetes service allows, among other parameters, the number of instances (*pods* |
| 461 | in Kubernetes terminology) that should be deployed for a particular service to be specified and a common endpoint for |
| 462 | that service to be defined. Once the service is started in Kubernetes, Kubernetes ensures that the specified number of |
| 463 | instances is always kept running. As requests are received on the common endpoint, they are distributed across the |
| 464 | service instances. More complex call distribution and instance deployment strategies may be used; please see the |
| 465 | `Kubernetes Services <https://kubernetes.io/docs/concepts/services-networking/service/>`__ documentation for those |
| 466 | details. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 467 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 468 | If, for example, a service called *policy-pdpd-control-loop* is defined that runs 5 PDP-D instances. The service has the |
| 469 | end point *https://policy-pdpd-control-loop.onap/<service-specific-path>*. When the service is started, Kubernetes spins |
| 470 | up 5 PDP-Ds. Calls to the end point *https://policy-pdpd-control-loop.onap/<service-specific-path>* are distributed |
| 471 | across the 5 PDP-D instances. Note that the *.onap* part of the service endpoint is the namespace being used and is |
| 472 | specified for the full ONAP Kubernetes installation. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 473 | |
| 474 | The following services will be required for the ONAP Policy Framework: |
| 475 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 476 | ================ ============================== ======================================================================= |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 477 | **Service** **Endpoint** **Description** |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 478 | ================ ============================== ======================================================================= |
| 479 | PAP https://policy-pap The PAP service, used for policy administration and deployment. See |
| 480 | :ref:`Policy Design and Development <design-label>` for details of the |
| 481 | API for this service |
| 482 | PDP-X-\ *domain* https://policy-pdpx-\ *domain* A PDP service is defined for each PDP group. A PDP group is identified |
| 483 | by the domain on which it operates. |
| 484 | |
| 485 | For example, there could be two PDP-X domains, one for admission |
| 486 | policies for ONAP proper and another for admission policies for VNFs of |
| 487 | operator *Supacom*. Two PDP-X services are defined: |
| 488 | |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 489 | | https://policy-pdpx-onap |
| 490 | | https://policy-pdpx-\ *supacom* |
| 491 | PDP-D-\ *domain* https://policy-pdpd-\ *domain* |
| 492 | PDP-A-\ *domain* https://policy-pdpa-\ *domain* |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 493 | ================ ============================== ======================================================================= |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 494 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 495 | There is one and only one PAP service, which handles policy deployment, administration, and monitoring for all policies |
| 496 | in all PDPs and PDP groups in the system. There are multiple PDP services, one PDP service for each domain for which |
| 497 | there are policies. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 498 | |
| 499 | 2.3.2 The Policy Framework Information Structure |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 500 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 501 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 502 | The following diagram captures the relationship between Policy Framework concepts at run time. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 503 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 504 | .. image:: images/RuntimeRelationships.svg |
| 505 | |
| 506 | There is a one to one relationship between a PDP SubGroup, a Kubernetes PDP service, and the set of policies assigned to |
| 507 | run in the PDP subgroup. Each PDP service runs a single PDP subgroup with multiple PDPs, which executes a specific |
| 508 | Policy Set containing a number of policies that have been assigned to that PDP subgroup. Having and maintaining this |
| 509 | principle makes policy deployment and administration much more straightforward than it would be if complex relationships |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 510 | between PDP services, PDP subgroups, and policy sets. |
| 511 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 512 | The topology of the PDPs and their policy sets is held in the Policy Framework database and is administered by the PAP service. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 513 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 514 | .. image:: images/PolicyDatabase.svg |
| 515 | |
| 516 | The diagram above gives an indicative structure of the run time topology information in the Policy Framework database. |
| 517 | Note that the *PDP_SUBGROUP_STATE* and *PDP_STATE* fields hold state information for life cycle management of PDP groups |
| 518 | and PDPs. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 519 | |
| 520 | 2.3.3 Startup, Shutdown and Restart |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 521 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 522 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 523 | This section describes the interactions between Policy Framework components themselves and with other ONAP components at |
| 524 | startup, shutdown and restart. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 525 | |
| 526 | 2.3.3.1 PAP Startup and Shutdown |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 527 | """""""""""""""""""""""""""""""" |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 528 | |
| 529 | The sequence diagram below shows the actions of the PAP at startup. |
| 530 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 531 | .. image:: images/PAPStartStop.svg |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 532 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 533 | The PAP is the run time point of coordination for the ONAP Policy Framework. When it is started, it initializes itself |
| 534 | using data from the database. It then waits for periodic PDP status updates and for administration requests. |
| 535 | |
| 536 | PAP shutdown is trivial. On receipt or a shutdown request, the PAP completes or aborts any ongoing operations and shuts |
| 537 | down gracefully. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 538 | |
| 539 | 2.3.3.2 PDP Startup and Shutdown |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 540 | """""""""""""""""""""""""""""""" |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 541 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 542 | The sequence diagram below shows the actions of the PDP at startup. See also Section 4 of the |
| 543 | :ref:`Policy Design and Development <design-label>` page for the API used to implement this sequence. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 544 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 545 | .. image:: images/PDPStartStop.svg |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 546 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 547 | At startup, the PDP initializes itself. At this point it is in PASSIVE mode. The PDP begins sending periodic Status |
| 548 | messages to the PAP. The first Status message initializes the process of loading the correct Policy Set on the PDP in |
| 549 | the PAP. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 550 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 551 | On receipt or a shutdown request, the PDP completes or aborts any ongoing policy executions and shuts down gracefully. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 552 | |
| 553 | 2.3.4 Policy Execution |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 554 | ^^^^^^^^^^^^^^^^^^^^^^ |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 555 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 556 | Policy execution is the execution of a policy in a PDP. Policy enforcement occurs in the component that receives a |
| 557 | policy decision. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 558 | |
liamfallon | 4d1d983 | 2019-05-30 20:53:05 +0000 | [diff] [blame] | 559 | .. image:: images/PolicyExecutionFlow.svg |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 560 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 561 | Policy execution can be *synchronous* or *asynchronous*. In *synchronous* policy execution, the component requesting a |
| 562 | policy decision requests a policy decision and waits for the result. The PDP-X and PDP-A implement synchronous policy |
| 563 | execution. In *asynchronous* policy execution, the component that requests a policy decision does not wait for the |
| 564 | decision. Indeed, the decision may be passed to another component. The PDP-D and PDP-A implement asynchronous polic |
| 565 | execution. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 566 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 567 | Policy execution is carried out using the current life cycle mode of operation of the PDP. While the actual |
| 568 | implementation of the mode may vary somewhat between PDPs of different types, the principles below hold true for all |
| 569 | PDP types: |
| 570 | |
| 571 | ================== ===================================================================================================== |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 572 | **Lifecycle Mode** **Behaviour** |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 573 | ================== ===================================================================================================== |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 574 | PASSIVE MODE Policy execution is always rejected irrespective of PDP type. |
| 575 | ACTIVE MODE Policy execution is executed in the live environment by the PDP. |
liamfallon | 3602c18 | 2020-04-16 09:29:45 +0100 | [diff] [blame] | 576 | SAFE MODE* Policy execution proceeds, but changes to domain state or context are not carried out. The PDP |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 577 | returns an indication that it is running in SAFE mode together with the action it would have |
| 578 | performed if it was operating in ACTIVE mode. The PDP type and the policy types it is running must |
| 579 | support SAFE mode operation. |
liamfallon | 3602c18 | 2020-04-16 09:29:45 +0100 | [diff] [blame] | 580 | TEST MODE* Policy execution proceeds and changes to domain and state are carried out in a test or sandbox |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 581 | environment. The PDP returns an indication it is running in TEST mode together with the action it has |
| 582 | performed on the test environment. The PDP type and the policy types it is running must support TEST |
| 583 | mode operation. |
| 584 | ================== ===================================================================================================== |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 585 | |
liamfallon | 3602c18 | 2020-04-16 09:29:45 +0100 | [diff] [blame] | 586 | \* SAFE Mode and TEST Mode will be implemented in future versions of the Policy Framework. |
| 587 | |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 588 | 2.3.5 Policy Lifecycle Management |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 589 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 590 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 591 | Policy lifecycle management manages the deployment and life cycle of policies in PDP groups at run time. Policy sets can |
| 592 | be deployed at run time without restarting PDPs or stopping policy execution. PDPs preserve state for minor/patch |
| 593 | version upgrades and rollbacks. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 594 | |
| 595 | 2.3.5.1 Load/Update Policies on PDP |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 596 | """"""""""""""""""""""""""""""""""" |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 597 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 598 | The sequence diagram below shows how policies are loaded or updated on a PDP. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 599 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 600 | .. image:: images/DownloadPoliciesToPDP.svg |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 601 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 602 | This sequence can be initiated in two ways; from the PDP or from a user action. |
| 603 | |
| 604 | 1. A PDP sends regular status update messages to the PAP. If this message indicates that the PDP has no policies or |
| 605 | outdated policies loaded, then this sequence is initiated |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 606 | |
| 607 | 2. A user may explicitly trigger this sequence to load policies on a PDP |
| 608 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 609 | The PAP controls the entire process. The PAP reads the current PDP metadata and the required policy and policy set |
| 610 | artifacts from the database. It then builds the policy set for the PDP. Once the policies are ready, the PAP sets the |
| 611 | mode of the PDP to PASSIVE. The Policy Set is transparently passed to the PDP by the PAP. The PDP loads all the policies |
| 612 | in the policy set including any models, rules, tasks, or flows in the policy set in the policy implementations. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 613 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 614 | Once the Policy Set is loaded, the PAP orders the PDP to enter the life cycle mode that has been specified for it |
liamfallon | 3602c18 | 2020-04-16 09:29:45 +0100 | [diff] [blame] | 615 | (ACTIVE/SAFE*/TEST*). The PDP begins to execute policies in the specified mode (see section 2.3.4). |
| 616 | |
| 617 | \* SAFE Mode and TEST Mode will be implemented in future versions of the Policy Framework. |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 618 | |
| 619 | .. _policy-rollout: |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 620 | |
| 621 | 2.3.5.2 Policy Rollout |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 622 | """""""""""""""""""""" |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 623 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 624 | A policy set steps through a number of life cycle modes when it is rolled out. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 625 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 626 | .. image:: images/PolicyRollout.svg |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 627 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 628 | The user defines the set of policies for a PDP group. It is deployed to a PDP group and is initially in PASSIVE mode. |
| 629 | The user sets the PDP Group into TEST mode. The policies are run in a test or sandboxed environment for a period of |
| 630 | time. The test results are passed back to the user. The user may revert the policy set to PASSIVE mode a number of times |
| 631 | and upgrade the policy set during test operation. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 632 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 633 | When the user is satisfied with policy set execution and when quality criteria have been reached for the policy set, the |
| 634 | PDP group is set to run in SAFE mode. In this mode, the policies run on the target environment but do not actually |
| 635 | exercise any actions or change any context in the target environment. Again, as in TEST mode, the operator may decide to |
| 636 | revert back to TEST mode or even PASSIVE mode if issues arise with a policy set. |
| 637 | |
| 638 | Finally, when the user is satisfied with policy set execution and when quality criteria have been reached, the PDP group |
| 639 | is set into ACTIVE state and the policy set executes on the target environment. The results of target operation are |
| 640 | reported. The PDP group can be reverted to SAFE, TEST, or even PASSIVE mode at any time if problems arise. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 641 | |
liamfallon | 3602c18 | 2020-04-16 09:29:45 +0100 | [diff] [blame] | 642 | \* SAFE Mode and TEST Mode will be implemented in future versions of the Policy Framework. In current versions, policies |
| 643 | transition directly from PASSIVE mode to ACTIVE mode. |
| 644 | |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 645 | 2.3.5.3 Policy Upgrade and Rollback |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 646 | """"""""""""""""""""""""""""""""""" |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 647 | |
liamfallon | 3602c18 | 2020-04-16 09:29:45 +0100 | [diff] [blame] | 648 | There are a number of approaches for managing policy upgrade and rollback. Upgrade and rollback will be implemented in |
| 649 | future versions of the Policy Framework. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 650 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 651 | The most straightforward approach is to use the approach described in section :ref:`policy-rollout` for upgrading and |
| 652 | rolling back policy sets. In order to upgrade a policy set, one follows the process in :ref:`policy-rollout` with the |
| 653 | new policy set version. For rollback, one follows the process in :ref:`policy-rollout` with the older policy set, most |
| 654 | probably setting the old policy set into ACTIVE mode immediately. The advantage of this approach is that the approach is |
| 655 | straightforward. The obvious disadvantage is that the PDP group is not executing on the target environment while the new |
| 656 | policy set is in PASSIVE, TEST, and SAFE mode. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 657 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 658 | A second manner to tackle upgrade and rollback is to use a spare-wheel approach. An special upgrade PDP group service is |
| 659 | set up as a K8S service in parallel with the active one during the upgrade procedure. The spare wheel service is used to |
| 660 | execute the process described in :ref:`policy-rollout`. When the time comes to activate the policy set, the references |
| 661 | for the active and spare wheel services are simply swapped. The advantage of this approach is that the down time during |
| 662 | upgrade is minimized, the spare wheel PDP group can be abandoned at any time without affecting the in service PDP group, |
| 663 | and the upgrade can be rolled back easily for a period simply by preserving the old service for a time. The disadvantage |
| 664 | is that this approach is more complex and uses more resources than the first approach. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 665 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 666 | A third approach is to have two policy sets running in each PDP, an active set and a standby set. However such an |
| 667 | approach would increase the complexity of implementation in PDPs significantly. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 668 | |
| 669 | 2.3.6 Policy Monitoring |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 670 | ^^^^^^^^^^^^^^^^^^^^^^^ |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 671 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 672 | PDPs provide a periodic report of their status to the PAP. All PDPs report using a standard reporting format that is |
| 673 | extended to provide information for specific PDP types. PDPs provide at least the information below: |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 674 | |
| 675 | ===================== =============================================================================== |
| 676 | **Field** **Description** |
| 677 | ===================== =============================================================================== |
liamfallon | 3602c18 | 2020-04-16 09:29:45 +0100 | [diff] [blame] | 678 | State Lifecycle State (PASSIVE/TEST*/SAFE*/ACTIVE) |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 679 | Timestamp Time the report record was generated |
| 680 | InvocationCount The number of execution invocations the PDP has processed since the last report |
| 681 | LastInvocationTime The time taken to process the last execution invocation |
| 682 | AverageInvocationTime The average time taken to process an invocation since the last report |
| 683 | StartTime The start time of the PDP |
| 684 | UpTime The length of time the PDP has been executing |
| 685 | RealTimeInfo Real time information on running policies. |
| 686 | ===================== =============================================================================== |
| 687 | |
liamfallon | 3602c18 | 2020-04-16 09:29:45 +0100 | [diff] [blame] | 688 | \* SAFE Mode and TEST Mode will be implemented in future versions of the Policy Framework. |
| 689 | |
| 690 | Currently, policy monitoring is supported by PAP and by pdp-apex. Policy monitoring for all PDPs will be supported in |
| 691 | future versions of the Policy Framework. |
| 692 | |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 693 | 2.3.7 PEP Registration and Enforcement Guidelines |
liamfallon | e62f711 | 2019-05-24 10:50:57 +0000 | [diff] [blame] | 694 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 695 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 696 | In ONAP there are several applications outside the Policy Framework that enforce policy decisions based on models |
| 697 | provided to the Policy Framework. These applications are considered Policy Enforcement Engines (PEP) and roles will be |
| 698 | provided to those applications using AAF/CADI to ensure only those applications can make calls to the Policy Decision |
| 699 | APIs. Some example PEPs are: DCAE, OOF, and SDNC. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 700 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 701 | See Section 3.4 of the :ref:`Policy Design and Development <design-label>` |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 702 | for more information on the Decision APIs. |
| 703 | |
| 704 | 3. APIs Provided by the Policy Framework |
| 705 | ======================================== |
| 706 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 707 | See the :ref:`Policy Design and Development <design-label>` page. |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 708 | |
| 709 | 4. Terminology |
| 710 | ============== |
| 711 | |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 712 | ================================= ================================================================================== |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 713 | PAP (Policy Administration Point) A component that administers and manages policies |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 714 | ================================= ================================================================================== |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 715 | PDP (Policy Deployment Point) A component that executes a policy artifact (One or many?) |
| 716 | PDP_<> A specific type of PDP |
| 717 | PDP Group A group of PDPs that execute the same set of policies |
| 718 | Policy Development The development environment for policies |
liamfallon | c9e2790 | 2019-05-28 13:27:04 +0000 | [diff] [blame] | 719 | Policy Type A generic prototype definition of a type of policy in TOSCA, see the |
| 720 | :ref:`TOSCA Policy Primer <tosca-label>` |
| 721 | Policy An executable policy defined in TOSCA and created using a Policy Type, see the |
| 722 | :ref:`TOSCA Policy Primer <tosca-label>` |
| 723 | Policy Set A set of policies that are deployed on a PDP group. One and only one Policy Set is |
| 724 | deployed on a PDP group |
| 725 | ================================= ================================================================================== |
Pamela Dragosh | 5fc2fdb | 2019-05-17 09:42:27 -0400 | [diff] [blame] | 726 | |
| 727 | |
| 728 | End of Document |