...

All policies must be certified as being fit for deployment prior to run time deployment. In the case of design-time via the SDC portalapplication, it is assumed the lifecycle being implemented by SDC will suffice . However, when performing policy design and CRUD operations within the Policy Portal, the Policy Lifecycle API will support the same lifecycle process: design → testing → approval → distribution. How governance is setup can be configured by the ONAP installation.Image Removedfor any policies that are declared within the ONAP Service CSAR. For Policy Templates and raw policies, the lifecycle associated with software development process will suffice. Since models, templates and raw policies will be deployed to a Nexus repository, software development best practices can utilized and configured for various environments (eg. development, testing, production) as desired.

2.2 Policy Runtime Architecture

...

2.2.7 PEP Registration and Enforcement Guidelines

- Pamela Dragosh

How do we set that up?

How do we ensure the API's allow flexibility for getting policy decisions?

PDP specific? May not relevant to drools or apex?

https://ericsson.github.io/apex-docs/policy-guide/pg-policy-matrix.html

How does the Policy framework work with OOF? Somehow the sequence diagram on the Optimization Service Design Framework page below looks a bit odd. One would have thought that SO should call maybe DCAE analytics to find out the current situation, then call Policy to decide what sort of optimization algorithm to run, then call OOF with instructions to run a particular optimization algorithm, and then implement the optimization towards the network (APPC/SDC/VFC). In other words, SO acts on a set of tools that provide certain metadata driven capabilities to SO. Then in SO, the appropriate set of tools can be called int he appropriate order to orchestrate services. In the sequence diagram, it looks like OOF is really in control of the orchestration and not SO.

Pamela Dragosh - No SO should never call DCAE it should only call OOF (which is considered a part of DCAE). OOF is the project where optimization is performed. OOF calls Policy for a policy decision on how to calculate the optimization. OOF then goes through that calculation. OOF returns the optimization to SO which has all the logic and implementation to perform the orchestration. Its debatable as to whether that optimization logic should be done in SO and/or Policy. But having it be the responsibility of OOF is where it is right nowIn ONAP there are several applications outside the Policy Framework that enforce policy decisions based on models provided to the Policy Framework. These applications are considered Policy Enforcement Engines (PEP) and roles will be provided to those applications using AAF/CADI to ensure only those applications can make calls to the Policy Decision API's. Some example PEP's are: DCAE, OOF, and SDNC.

3. APIs Provided by the Policy Framework and how to use them

...