...
| 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 |
100% pass |
| ||||||||||
| 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. /wiki/spaces/DW/pages/16286803 |
| ||||||||||
| Manageability | Level 1 | Level 1 |
|
| ||||||||||
| Usability | Level 1 | Level 1 |
http://onap.readthedocs.io/en/latest/submodules/policy/engine.git/docs/index.html |
|
...
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.
...