...
PolicyDevelopment creates sets of executable policies (ExecutablePolicySet) for a certain domain, which consist of policies (ExecutablePolicy) and parameters for those policies (PolicyParameters) that can execute on PDPs. Executable policies are created from domain concrete policies (DomainPolicyConcretePolicy) that have been created from template policies (PolicyTemplate).
...
This section describes the architecture of the model driven system used to develop policy templates, to derive executable concrete policies from those policy templates, and to parameterize the concrete policies as executable policies.
See Pamela Dragosh's presentation from Santa Clara, especially the workflow/state diagram for policy design/test/certification
ONAP Beijing Release Developer Forum, Dec. 11-13, 2017, Santa Clara, CA US
...
Policy Template Design
Policy Design can occur in several places during a "design" process. During design time the models should allow a service designer and/or operations team to be able to express and capture policy both at its highest abstraction as well as using a specific policy language if desired.
The information expressed during policy design is used to specialize a policy template to create an executable policy. A policy can be designed in many ways.
Model Driven VF Policy Design via VNF SDK Packaging
VF vendors express policies such as SLA, Licenses, hardware placement, run-time metric suggestions, etc. These details are captured within the VNF SDK and uploaded into the SDC Catalog.
For example, SLA and placement policies may be captured via TOSCA specification. License policies can be captured via TOSCA or XACML specification (TBD). Run-time metric vendor recommendations can be captured via VES Standard specification.
(High level architectural sequence diagram on how this works)
Model Driven Policy Design via SDC GUI
The SDC GUI supports several types of policies that can be captured during design time. DCAE micro service configuration policies can be onboarded via the DCAE-DS (DCAE Design Studio). Service policies such as Optimization, Placement policies can also be captured via TOSCA model during design time.
(High level architectural sequence diagram on how this works)
Model Driven Policy Design via Policy Dashboard (exposed via ONAP Portal SDK)
(High level architectural sequence diagram on how this works)
Policy Template Design
Template Design is the task of creating policy templates that capture the generic and vendor independent aspects of a policy for a particular domain use case. The policy template also specifies and publishes the model information that it requires to generate concrete policies.
A policy template is written for a certain type of PDP. A policy template is developed for a certain type of PDP (for example XACML oriented for decision policies or Drools rules oriented for ECA policies). The design environment and tool chain for a policy template is specific for the type of policy being designed. The policy template is available as a Maven artifact once it has been designed.
All policy templates must implement the ONAP Policy Framework PolicyTemplate interface. This interface allows the Policy Framework to manage policy templates and to generate concrete policies from policy templates in a uniform way regardless of the domain that the policy template is addressing or the PDP technology that will execute the policy. The interface is used by the Policy Framework to determine the PDP technology of the policy template, the structure, type, and definition of the model information that must be supplied to the policy template to generate a concrete policy, and other relevant information.
The ONAP Policy Framework provides an API that allows other components to query policy templates, to determine the model information that they require, and to generate concrete policies from policy templates.
Consider a policy template created for managing faults on vCPE equipment in a vendor independent way. The policy template captures the logic required to manage the faults and specifies the vendor specific information that must be supplied to te template for specific vendor vCPE VFs. The actual concrete vCPE policy that is used for managing particular vCPE equipment is generated using the policy template together with the specific modeled information for that vendor model of vCPEA policy template is a generic policy for a certain type of PDP. A policy template is developed for a certain type of PDP (for example XACML oriented for decision policies or Drools rules oriented for ECA policies). The design environment and tool chain for a policy template is specific for the type of policy being designed. The policy template is available as a Maven artifact once it has been designed.
Programming Policy Templates
...
It is also possible to generate policy templates using MDD (Model Driven Development) techniques. Policies are expressed using a DSL (Domain Specific Language) or a policy specification environment for a particular application domain. For example, policies for specifying SLAs could be expressed in a SLA DSL and policies for managing SON features could be generated from a visual SON management tool. The ONAP Policy framework provides an API that allows tool chains to create policy templates.
Policy Design
Policy Design can occur in several places during a "design" process. During design time the models should allow a service designer and/or operations team to be able to express and capture policy both at its highest abstraction as well as using a specific policy language if desired.
The information expressed during policy design is used to specialize a policy template to create an executable policy. A policy can be designed in many ways.
Model Driven VF Policy Design via VNF SDK Packaging
VF vendors express policies such as SLA, Licenses, hardware placement, run-time metric suggestions, etc. These details are captured within the VNF SDK and uploaded into the SDC Catalog.
For example, SLA and placement policies may be captured via TOSCA specification. License policies can be captured via TOSCA or XACML specification (TBD). Run-time metric vendor recommendations can be captured via VES Standard specification.
(High level architectural sequence diagram on how this works)
Model Driven Policy Design via SDC GUI
The SDC GUI supports several types of policies that can be captured during design time. DCAE micro service configuration policies can be onboarded via the DCAE-DS (DCAE Design Studio). Service policies such as Optimization, Placement policies can also be captured via TOSCA model during design time.
(High level architectural sequence diagram on how this works)
Model Driven Policy Design via Policy Dashboard (exposed via ONAP Portal SDK)
(High level architectural sequence diagram on how this works)
Policy Design Process
All policies must be certified as being fit for deployment prior to run time deployment. This certification may be performed over the ONAP Policy Framework APIs in the case where other ONAP components such as SDC crete policies. For Policies created directly in the PF, governance of policy certification and testing is supported in the system.
...