This epic covers the work to define the Policy Design Developer Environment and build the Policy Lifecycle API and the PAP <–> PDP Software Architecture.

The new Policy Software Architecture is being described on this wiki:

https://wiki.onap.org/display/DW/The+ONAP+Policy+Framework

The goal for Dublin is to establish the underlying framework for these critical features:

1) Establish the Policy Designer Development Environment required for doing Policy Design work intending to create/utilize models/templates that can be used to create concrete policies. In addition, ensure raw policies development is also supported. There will be a minimum set of required policy models to support for Dublin:

• New Control Loop DCAE microservice TOSCA model being developed as part of Control Loop requirements
• Control Loop Guard Policy Model
• New Control Loop Coordination Policy Model
• Control Loop Operational YAML Policy Model
• HPA Placement Policy Model
• TBD existing models which will be dependent on Resources.

2) Create the new Policy Lifecycle API that supports the the Policy Designer Development Environment. Policy Designers utilize the Policy Lifecycle API to CRUD their models/templates to make them available for creation of concrete policies either ad hoc during runtime as well as automated as part of SDC Service Distribution. The API will support the create, read and delete functionality at minimum for models, templates and policies. It will store Policy State into a MariaDB and be able to generate concrete policies into a Nexus repository to make them available to PDP engines during Runtime.

3) Create the new PAP that supports grouping of PDP's together that enforce/make decisions on sets of policies. At minimum there is a default PDP group that PDP's will be added to upon their auto-registration with the PAP (see #4). Not only is the PAP is responsible for organizing the PDP engines into groups, it is also responsible for deploying and un-deploying concrete Policies (as created by the Policy Lifecycle API) to the PDP Engines. 

4) The 3 PDP Engines (Drools, XACML 2nd gen, Apex) will be enhanced to auto-register/unregister with the PAP into a default PDP Group when they are brought online via creation of the Policy PDP SDK that the engines will inherit from. It is required that this functionality meet ONAP S3P guidelines for component resiliency and scalability. In addition, the XACML 2nd gen and Apex PDPs will be enhanced to support deployment and un-deployment of policies to/from the Nexus repositories as directed by the PAP (see #3).

It is agreed beforehand that the code contributions for this epic will follow ONAP Software Development best practices and specifically the best practices being set by the Policy Framework team for https://wiki.onap.org/display/DW/Policy+Framework+Project%3A+Software+Development+Best+Practices

• Setting developer environment appropriately
• Removal of sonar/checkstyle issues ASAP they are introduced
• JUnit code coverage 80%+
• For the Policy Lifecycle API, must meet these requirements (NOTE: Internal API's do not need to)
  • https://wiki.onap.org/display/DW/ONAP+API+Common+Versioning+Strategy+%28CVS%29+Guideline
• Appropriate CSIT tests developed to support code merges in order to not break functionality
• S3P functionality for stability and performance created and continually enhanced for any components that support a healthcheck API
• Document-as-you-go - requested by Documentation team for this release.