Skip to end of metadata
Go to start of metadata

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

POLICY-392 - Getting issue details... STATUS

Platform Maturity: Performance

  • 0 -- none
  • 1 – baseline performance criteria identified and measured
  • 2 & 3 – performance improvement plans created & implemented
StabilityLevel 1Level 1
  • 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-513 - Getting issue details... STATUS

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

POLICY-514 - Getting issue details... STATUS

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

POLICY-515 - Getting issue details... STATUS

*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-516 - Getting issue details... STATUS

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

  • No labels