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

AreaActual LevelTargeted Level for current ReleaseIntegration Test PlanComments
PerformanceLevel 1Level 1

Platform Maturity: Performance

  • 0 -- none
  • 1 – baseline performance criteria identified and measured
  • 2 & 3 – performance improvement plans created & implemented
StabilityLevel 1Level 1

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
ResiliencyLevel 1Level 2

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)
SecurityLevel 1Level 1

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
ScalabilityLevel 0Level 1

*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
ManageabilityLevel 1Level 1

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
UsabilityLevel 1Level 1

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.