...
MUSIC is a shared service with recipes that individual ONAP components can use for state-management. While its intended granularity is at the ONAP component level, it will work well even for micro-services. For example, we envisage the use of MUSIC for multi-site state management in SO (to store Camunda state across sites), <SDN-C, AppC> (to store ODL related state across sites) , A&AI (to store its graph data) and most other ONAP components that need to manage state across sites.
Out of Scope:
While MUSIC is an optional solution for state-management of ONAP components across sites, OOM will continue to manage component level and platform level deployment, scalability, redundancy, resiliency, self-healing and high availability across sites for ONAP.
...
The figures below how MUSIC can be used in a general context and also provide a specific example of its potential usage in ONAP MSO.
A specific example:
...
Seed Code Status:
MUSIC and its recipes have all been open sourced in github:MUSIC.
Here is an overview of MUSIC's REST API: https://github.com/att/music/blob/master/RestMusicOverview.pdf
MUSIC and mdbc together can support the following databases: Cassandra, MySQL, MariaDB, H2.
OOF-Homing Optimizer (HAS) uses MUSIC for its state persistence (as a queue) and as a highly available distributed messaging service. This is currently being run in production within ATT's ECOMP.
Architecture Alignment:
How does this project fit into the rest of the ONAP Architecture?
MUSIC will be available as a common service like DMaap or AAF as shown in the red, oblong box below:
What other ONAP projects does this project depend on?
Since OOM is responsible for the life-cycle of ONAP components, it will also need to manage the deployment of MUSIC.
How does this align with external standards/specifications?
MUSIC and its recipes export a REST API apart from mdbc which is implemented as a jdbc driver to enable seamless integration with SQL-based ONAP components.
...