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.
...
For the Beijing R2 release, we should create the targets for supporting redundancy schemes which will eventually lead to higher availability and make the platform carrier grade
I would like to suggest the ONAP community to consider the functionality about operation and management, it will be benefit to SP to manage their network. For example,
1. ONAP should be able to collect alarms/events for different level, and do the correlation and display to network operators of SP.
2. ONAP should be able to persistently store and manage kinds of instances, for example, virtual resources and physical resources, like bare mental servers, physical routes, etc.
3. ONAP should be able to consider how to bring benefits to troubleshooting of ONAP platform itself.
- 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 ..)