...
- Integration with SDC to support future Policy Design GUI integration into SDC
- We are waiting or SDC to produce their SDK for integration at the end of Beijing
- Policy Lifecycle API
- Not enough resources or time to fully implement this and make it available to other Components. We expect to have at the very least appropriate documentation, models, and swagger yaml files.
- Distribution of PDPs across the network - in lieu of support future performance requirements for Control Loops (Eg. a Control Loop must address an issue within X milliseconds of detection in an automated fashion)
- PDP distribution needs to be enhanced to support multiple PDP's being located in edge, core, global datacenters. (i.e geo-distribution)
- This should also support high availability and resiliency within each datacenter
- PDP's designed as Microservices and deployed via OOM registering with MSB
Release Deliverables
Indicate the outcome (Executable, Source Code, Library, API description, Tool, Documentation, Release Note...) of this release.
...
| API Name | API Description | API Definition Date | API Delivery date | API Definition link (i.e.swagger) |
|---|---|---|---|---|
| Policy Client API | This API is used by other ONAP components to create, update and delete policy(s). | Amsterdam version - no changes | Policy API | |
| Policy Query API | This API is used by other ONAP components responsible for enforcing policy during runtime. | Amsterdam version - no changes | Policy API | |
| Policy Lifecycle API | The new Policy Lifecycle API description, documentation, models, etc. | M3 API Freeze. We do not expect our clients to be able to utilize this API in Beijing. | M3 | TBD |
Third Party Products Dependencies
...
Testing and Integration Plans
Provide a description of the testing activities (unit test, functional test, automation,...) that will be performed by the team within the scope of this release.
JUnit tests: 50% code coverage is the goal for all repositories.
Functional tests: cover all possible Control Loop API calls. Simulating CLAMP and DCAE.
- If resources become available, we will add more API calls such as delete, update.
"Describe the plan to integrate and test the release deliverables within the overall ONAP system.
Confirm that resources have been allocated to perform such activities" - at this point I do not have enough resources to help with testing.
Gaps
This section is used to document a limitation on a functionality or platform support. We are currently aware of this limitation and it will be delivered in a future Release.
List identified release gaps (if any), and its impact.
| Gaps identified | Impact | To fill out | To fill out|
|---|---|---|---|
| Template Code is inefficient with respect to threading | Drools is single-threaded. When a RESTful API call is made, it should be done in a thread vs polling. Else it holds up the processing of events/rules. | ||
| Policy GUI limitations | Unable to update templates This visual update of Control Loop Operational Policies is not user-friendly Not a truly model-driven architecture. Code must be written in order to support new models. |
Known Defects and Issues
Provide a link toward the list of all known project bugs.
...
| Risk identified | Mitigation Plan | Contingency Plan |
|---|---|---|
| Resources | Actively seeking community support. | Current resources are only enough to satisfy the Highest Priority Epics (Platform Maturity, JUnit 50% test coverage). But that will be difficult to achieve. |
Resources
Fill out the Resources Committed to the Release centralized page.
...