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|
|Performance||Level 1||Level 1|
|Stability||Level 1||Level 1|
|Resiliency||Level 1||Level 2|
|Security||Level 1||Level 1|
|Scalability||Level 0||Level 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.
|Manageability||Level 1||Level 1|
|Usability||Level 1||Level 1|
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.