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