DRAFT PROPOSAL FOR COMMENTS
The content of this template is expected to be fill out for M1 Release Planning Milestone.
...
| Project Name | Enter the name of the project |
|---|---|
| Target Release Name | Casablanca |
| Project Lifecycle State | Incubation |
| Participating Company | AT&T, Ericsson, Amdocs, Intel, TechMahindra (Confirming) |
Scope
What is this release trying to address?
- Maintenance of current Platform MVP components (Highest Priority)
- 50% code coverage (Java and Javascript)
- Reliability of S3P functionality
- Security Enhancements to further progress towards Silver badge
- internal communication encrypted
- role-based access control and authorization for all calls
- Logging spec v1.2 requirements
- Auto Scale Out Use Case (High Priority))
- Implement new SO API call for Scale Out
- Support Guard Policies creation by CLAMP (Stretch Goal - not enough resources)
- Implement min/max of instances check similar to VID (Stretch Goal - not enough resources and/or information to fully commit)
- Implement Prov_Status=PROV check (Stretch Goal - not enough resources and/or information to fully commit)
- Implementation of Common Actor API - interface with SO
- ?
- HPA Functional Requirement (Medium Priority)
- Creation of Application that integrates with SDC Service Distribution
- Must support current API and have hooks to support future Policy Lifecycle API
- Health Check, CSIT, Dockerized, K8S HELM Chart, Health Check, CSIT, S3P, 70% code coverage
- Code implementation for automatic creation of HPA Placement policies located in VNF descriptor for OOF to perform placement (Dependent upon creation of Policy SDC Service Distribution application)
- Include CSIT test
- Creation of Application that integrates with SDC Service Distribution
- Re-architecture of the Platform components for long term roadmap (Low Priority)
- Ingest of Apex PDP engine
- Dockerized, HELM Chart, Health Check, CSIT, Dockerized, HELM Chart, S3P, 70% code coverage
- PAP 2nd Generation
- Re-build of PAP ↔ PDP Policy Distribution API using Maven Nexus Repo.
- Re-build of PAP ↔ PDP Grouping
- Above 2 requirements will involve creation of PDP SDK (2nd Generation)
- Policy Lifecycle API
- Dockerized, HELM Chart, Health Check, CSIT, Dockerized, HELM Chart, S3P, 70% code coverage
- XACML PDP 2nd Generation
- Configurability of XACML Combining Algorithms for root engine
- Open support for raw XACML policies
- Integration with PDP SDK (2nd Generation)
- Policy Engineer Development Environment
- Documentation
- Ingest of Apex PDP engine
...
| Jira | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
...
| Deliverable Name | Deliverable Description | |
|---|---|---|
| Policy Portal Dashboard | Executable | |
| Policy PAP web application | Executable | |
| API - internal to the Policy Platform. The Policy PDP engines use this API to synchronize policies being distributed. | ||
| Policy Drools PDP | Executable | |
| Policy XACML PDP | Executable | |
| Existing API - external to ONAP components. The API is used to CRUD Policies, Deploy Policies, and query for Policy Decisions. | ||
| Policy BRMS Gateway | Executable | |
| MariaDB | SQL database
| |
| Nexus Repo | This repository is used by the Policy Drools PDP to retrieve distributed policies and their dependent jars. | |
| Policy SDC Distribution Integration | Executable - receives SDC Service Distribution notifications and translates VNF/Service policies into runtime policies. | |
| Stretch Goals | The following will only be a deliverable if they are available for community to use. As they are not MVP, they will only be a stretch goal | |
| Policy Lifecycle API (2nd Generation) | Description/DocumentationPolicy SDC Distribution Integration | |
| Executable | Policy PAP (2nd Generation) | Executable |
| Policy PDP SDK (2nd Generation) | Code Deliverable | |
| Policy Apex PDP | Executable | |
| Policy XACML PD PDP (2nd Generation) | Executable |
...
Sub-components are repositories and are consolidated in a single centralized place. Edit the Release Components name for your project in the centralized page.
...
| API Name | API Description | API Definition Date | API Delivery date | API Definition link (i.e.swagger) | |||
|---|---|---|---|---|---|---|---|
| Common Actor new SO API | High level description of the API | Date for which the API is reviewed and agreed | To fill out | SO will be designing an API for Scale Out that can be shared by Policy and VID using Dmaap | M3 | M3 timeLink toward the detailed API description | |
| AAI | REST Web Service for AAI | Beijing | |||||
| Control Loop Event Messages | Dmaap messages published by DCAE when a Control Loop Event occurs. | Beijing | n/a | n/a | |||
| APP-C | Dmaap message LCM API for Restart and ModifyConfig | Beijing | |||||
| SO | API for auto scaling (for backwards compatibility until Common Actor API is established) | Beijing | |||||
| DMAAP | API for publish/subscribe to DCAE Control Loop Events and APP-C API | Beijing |
...
| Risk identified | Mitigation Plan | Contingency Plan |
|---|---|---|
| Not enough resources to meet all the functional requirements. | All Epics are assessed a priority. | |
| Need the SO API defined by a reasonable timeframe for implementation to happen | We will use the current SO RESTful API until the new API is in place. |
Resources
Fill out the Resources Committed to the Release centralized page.
Release Milestone
...
Team Internal Milestone
This section is optional and may be used to document internal milestones within a project team or multiple project teams. For instance, in the case the team has made agreement with other team to deliver some artifacts on a certain date that are not in the release milestone, it is erecommended to provide these agreements and dates in this section.
It is not expected to have a detailed project plan.
...
Documentation, Training
http://onap.readthedocs.io/en/beijing/submodules/policy/engine.git/docs/index.html
...