Policy R2 Beijing - Integration Test Plans

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

Area	Actual Level	Targeted Level for current Release	Integration Test Plan	Comments
Performance	Level 1	Level 1	POLICY-392: Platform Maturity Requirements - Performance Level 1Closed Platform Maturity: Performance	0 -- none 1 – baseline performance criteria identified and measured 2 & 3 – performance improvement plans created & implemented
Stability	Level 1	Level 1	POLICY-512: This epic covers the work to support Platform Maturity Requirements - Stability Level 1Closed 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	POLICY-513: Platform Maturity Requirements - Resiliency Level 2Closed 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	POLICY-514: This epic covers the work to support Platform Maturity Requirements - Security Level 1Closed 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	POLICY-515: This epic covers the work to support Platform Maturity Requirements - Scalability Level 1Closed *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. 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	POLICY-516: This epic covers the work to support Platform Maturity Requirements - Manageability Level 1Closed 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	POLICY-517: This epic covers the work to support Platform Maturity Requirements - Usability Level 1Closed 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.