72 hour stability run to ensure containers
...
stability of APIs and internal interfaces to the list for carrier grade
we should have the concept of unique transaction id/correlation id on each component for traceability perspective so we can investigate/trouble shoot call flow even under load - it does improve operability
We have to narrow down the redundancy schemes to be supported by each component of the ONAP platform.
...
- Modular architecture where one can mix and match ONAP components with other open source/commercial options
- Flexible deployment options where selected ONAP components can be deployed on a regional and/or global basis and coordinated with each other
- Scalability and availability should be completely configurable option by each SP for each module and the platform as a whole and not stipulated to be any specific number. The only requirement should be that each ONAP component is built as a cloud application (eg., state is maintained externally to the application), so then it is easy to support any kind of scaling (eg., horizontal) and availability (1+1, n:1 ..) by having mechanisms external to the application (such as stateless load balancer ..)
VNFs lifecycle and availability need to be handled through ONAP, to get ONAP best added value using closed loop control and lifecycle orchestration.
Therefore, we definitely need RESILIENCY, especially concerning the closed loop modules (DCAE, Policy, controllers,...)
On top of resiliency, we do need to be able to efficiently operate ONAP itself, and to operate the vnf service through ONAP efficiently.
To sum up: resiliency, ONAP operability and VNF operability through ONAP are key