Policy R3 Casablanca - 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: 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	POLICY-809: Maintain and implement performanceClosed 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	POLICY-814: 72 hour stability testing (component and platform)Closed 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	POLICY-819: Maintain and implement resiliencyClosed 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-824: maintain and implement securityClosed	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	POLICY-825: Maintain and implement scabilityClosed 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-829: Maintain and implement manageabilityClosed 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-839: Maintain and implement usabilityClosed 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.