...
In this release we plan to provide to address the following items:
- MUSIC as a service: while MUSIC was consumed internally by components in the Beijing release, in Dublin we intend to provide MUSIC as an independent multi-site clustered service
- Enable automated failure detection and consistent failover across sites for ONAP components using MUSIC through the PROM recipe. It will require no change to the code of the ONAP components and just a few scripting/configuration steps to achieve single-step automated failover while ensuring that the new leader/owner has access to the latest state information.
- Provide the design to make MUSIC a Provide MUSIC as a fully sharded, scale out systemcommon service, where as many ONAP sites/component replicas can be added as required for performance. The significant technical challenge is to eliminate the need for Zookeeper and build MUSIC completely based on Cassandra while preserving all its guarantees. We expect this change to improve both deployabiity (just one tool – Cassandra) and performance (initial benchmarks indicate a factor of at least 4-5 times in terms of throughput). This is a crucial precursor for its use in edge computing and as the state management service for a federated ONAP.
- Provide the design seed code to allow MUSIC to support database (RDBMS) clustering across sites using the mdbc recipe wherein ONAP components that require it can continue using a SQL database within a site while using MUSIC is as the underlying transport layer across sites, with much better performance than standard solutions like Gallera clustering.
- Continued adherence to ONAP S3P requirements in Dublin
...
- Targeted goal for Dublin
- Stretch goal for Dublin: SDN-C will use the MUSIC PROM recipe for automated and consistent failover across sites.
...