This page will track our test plans for S3P functionality (if applicable). When successful, we will update the Release Planning wiki on our status: Beijing Release Platform Maturity
Platform Maturity Integration Testing
| Area | Actual Level | Targeted Level for current Release | Integration Test Plan | Comments |
|---|
| Performance | Level 1 | Level 1 | | Jira Legacy |
|---|
| server | System Jira |
|---|
| columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
|---|
| serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
|---|
| key | POLICY-392 |
|---|
|
Platform Maturity: Performance | - 0 -- none
- 1 – baseline performance criteria identified and measured
- 2 & 3 – performance improvement plans created & implemented
|
| Stability | Level 1 | Level 1 | | Jira Legacy |
|---|
| server | System Jira |
|---|
| columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
|---|
| serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
|---|
| key | POLICY-512 |
|---|
|
Policy Drools PDP 72 Hour Stability Testing Plan Policy XACML PDP 72 Hour Stability Testing Plan | - 0 – none
- 1 – 72 hours component level soak w/random transactions
- 2 – 72 hours platform level soak w/random transactions
- 3 – 6 months track record of reduced defect rate
|
| Resiliency | Level 1 | Level 2 | | Jira Legacy |
|---|
| server | System Jira |
|---|
| columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
|---|
| serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
|---|
| key | POLICY-513 |
|---|
|
/wiki/spaces/DW/pages/16286803 | - 0 – none
- 1 – manual failure and recovery (< 30 minutes)
- 2 – automated detection and recovery (single site)
- 3 – automated detection and recovery (geo redundancy)
|
| Security | Level 1 | Level 1 | | Jira Legacy |
|---|
| server | System Jira |
|---|
| columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
|---|
| serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
|---|
| key | POLICY-514 |
|---|
|
100% pass | - 0 – none
- 1 – CII Passing badge + 50% Test Coverage
- 2 – CII Silver badge; internal communication encrypted; role-based access control and authorization for all calls
- 3 – CII Gold
|
| Scalability | Level 0 | Level 1 | | Jira Legacy |
|---|
| server | System Jira |
|---|
| columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
|---|
| serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
|---|
| key | POLICY-515 |
|---|
|
*NOTE - due to lack of resources, Policy may not be able to do this work. It is "Low" priority per Jason's slides from TSC 1/4/2018. /wiki/spaces/DW/pages/16286803
| - 0 – no ability to scale
- 1 – single site horizontal scaling
- 2 – geographic scaling
- 3 – scaling across multiple ONAP instances
|
| Manageability | Level 1 | Level 1 | | Jira Legacy |
|---|
| server | System Jira |
|---|
| columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
|---|
| serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
|---|
| key | POLICY-516 |
|---|
|
/wiki/spaces/DW/pages/16286803 | - 1 – single logging system across components; instantiation in < 1 hour
- 2 – ability to upgrade a single component; tracing across components; externalized configuration management
|
| Usability | Level 1 | Level 1 | | Jira Legacy |
|---|
| server | System Jira |
|---|
| columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
|---|
| serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
|---|
| key | POLICY-517 |
|---|
|
http://onap.readthedocs.io/en/latest/submodules/policy/engine.git/docs/index.html
| - 1 – user guide; deployment documentation; API documentation
- 2 – UI consistency; usability testing; tutorial documentation
|
HPA Support
Since service design policies are typically defined as a part of a service design model and evaluated/enforced prior to the service instantiation phase. For example, Hardware Platform Enablement (HPA) policies are defined in an SDC service model and evaluated/enforced during the homing optimization process in ONAP. Based on the flow description on OOF-Policy+Interaction+in+R2 and Policy+Specification+and+Retrieval+for+OOF, there are three gaps:
- SDC-to-Policy, the API invoked by SDC to notify a new service model. SDC distributes a service models once the model is stored in the SDC repository. need talk with SDC to check if the existing API could work.
- Policy-to-OOF, new API or another method invoked by OOF to upload the models as template, which is used by Policy to auto-generate policy, whatever one or multi templates. The policy system does not currently offer APIs to upload models. The only available option to manually upload models using the policy portal/GUI. is it acceptable in R2?
- Policy Internal, needs add logic to do auto-generate HPA policies from a service model in R2.