...
The sequence diagram below is a high level view of SDC-triggered concrete policy generation for some arbitrary entity EntityA.
PolicyDesign contains a component PolicyDesignSDCHandler for managing SDC-triggered concrete policy creation and update requests. PolicyDesignSDCHandler is an API_User, it uses the Policy Design API to execution policy creation and update. It reads the information it needs to populate the policy template from SDC and then uses this information to automatically generate a policy.
...
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).
The GUI implementation in another ONAP component such as SDC or the DCAE-DS uses the API_User API to create and edit ONAP policies. Note that this puts an impact on those components.
...
Service policies such as optimization and placement policies can be captured via TOSCA models during design time. These models can be used to generate concrete policies.
One straightforward way of generating concrete policies from Policy metadata in TOSCA, YAML, or other such modelling languages combined with directives specified in a script file is to use a command line utility. The command line utility is an API_User. It reads the policy model from the model file, and/or the directives from a script file and uses the information from those files to drive the concrete policy generation process.
...
The sequence diagram below shows the actions of the PAP at startup.
The PAP is the run time point of coordination for the ONAP Policy Framework. When it is started, it initializes itself. It then waits for periodic PDP status updates and for administration requests.
...
The sequence diagram below shows the actions of the PDP at startup.
At startup, the PDP initializes itself. At this point it is in PASSIVE mode. The PDP begins sending periodic Status messages to the PAP.
...
Policy execution is the execution of a policy in a PDP. Policy enforcement occurs in the component that receives a policy decision.
Policy execution can be synchronous or asynchronous. In synchronous policy execution, the component requesting a policy decision requests a policy decision and waits for the result. The PDP-X uses synchronous policy execution. In asynchronous policy execution, the component that requests a policy decision does not wait for the decision. Indeed, the decision may be passed to another component. The PDP-D uses asynchronous policy execution.
...
The sequence diagram below shows how a Policy Set is loaded into a PDP.
This sequence can be initiated in three ways; from the PDP, from Nexus, or from a user action.
...
A policy set steps through a number of life cycle modes when it is rolled out.
The user rolls out a policy set. It is deployed to a PDP group and is initially in PASSIVE mode. The user sets the PDP Group into TEST mode. The policies are run in a test or sandboxed environment for a period of time. The test results are passed back to the user. The user may revert the policy set to PASSIVE mode a number of times and upgrade the policy set during test operation.
...