/
Policy R3 Casablanca - Integration Test Plans

Policy R3 Casablanca - Integration Test Plans

Jul 13, 2018

This page will track our test plans for S3P functionality (if applicable). When successful, we will update the Release Planning wiki on our status: Casablanca Release Platform Maturity

 

Platform Maturity Integration Testing

Area

Actual Level

Targeted Level for current Release

Integration Test Plan

Comments

Area

Actual Level

Targeted Level for current Release

Integration Test Plan

Comments

Performance

Level 1

Level 2

https://lf-onap.atlassian.net/browse/POLICY-809

Policy R3 Platform Maturity: Performance

 

  • 0 -- none

  • 1 – baseline performance criteria identified and measured

  • 2 & 3 – performance improvement plans created & implemented

Stability

Level 1

Level 1

https://lf-onap.atlassian.net/browse/POLICY-814

Policy R3 Policy Drools PDP 72 Hour Stability Testing Plan

Policy R3 Policy XACML PDP 72 Hour Stability Testing Plan

Apex?

  • 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 2

Level 2

https://lf-onap.atlassian.net/browse/POLICY-819

Policy on OOM

  • 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+

https://lf-onap.atlassian.net/browse/POLICY-824

 

  • 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 1

Level 1

https://lf-onap.atlassian.net/browse/POLICY-825

 

Policy on OOM

 

  • 0 – no ability to scale

  • 1 – single site horizontal scaling

  • 2 – geographic scaling

  • 3 – scaling across multiple ONAP instances

Manageability

Level 1

Level 1

https://lf-onap.atlassian.net/browse/POLICY-829

Policy on OOM

  • 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

https://lf-onap.atlassian.net/browse/POLICY-839

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:

  1. 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.

  2. 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?

  3. Policy Internal, needs add logic to do auto-generate HPA policies from a service model in R2.