Page History

...

...

What is this release trying to address?

This release of MUSIC MUSIC was released in the ONAP Beijing release and provides a service with recipes that individual ONAP components and micro-service can use for state replication, consistency management and state ownership across geo-distributed sites. This is a crucial component enabling ONAP components to achieve geo-redundancy (platform-maturity resiliency level 3). 

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 Cassablanca 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 fully sharded, scale out system, 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 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 Cassablanca

Use Cases

• Targeted goal for R2R4: 
  • OOF-Homing Optimizer (HAS) uses MUSIC for its state persistence (as a queue) and as a highly available distributed messaging service. (2) 
  Stretch goal for R2: ONAP Portal will
  • ONAP Portal will use MUSIC to store its http session state across sites in a persistent manner.  
• Stretch goal for R4: SDN-C will use the MUSIC PROM recipe for automated and consistent failover across sites. 
  
  

Minimum Viable Product

MUSIC service that can serve the geo-redundancy needs of ONAP HAS and ONAP Portal while satisfying the platform maturity requirements for the Beijing release. For Beijing this will be run as internal services to both Portal and OOFCassablanca release. 

Functionalities

Epics

...