| Table of Contents | ||
|---|---|---|
|
Overview
...
This release of MUSIC provides a shared 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).
Use Cases
- Targeted goal for R2: OOF-Homing Optimizer (HAS) uses MUSIC for its state persistence (as a queue) and as a highly available distributed messaging service.
- Stretch goal for R2: ONAP Portal will use MUSIC to store its http session state across sites in a persistent manner.
...
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 OOF.
Functionalities
Epics
Jira Legacy server System Jira columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery project=music and issuetype in (epic) serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176
...
In the long term we hope that MUSIC will be common, shared state-management system for all ONAP components and micro-services to manage geo-redundancy. 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. Further, we envision that these services will use the MUSIC recipes (mdbc, prom, musicCAS, musicQ) to achieve the goal of a multi-site active-active federated ONAP solution.
...
| Area | Actual Level | Targeted Level for current Release | How, Evidences | Comments |
|---|---|---|---|---|
| Performance | 1 | 1 | This file shows basic performance benchmarks performed for MUSIC on a 10 node cluster. |
|
| Stability | 1 | 1 | As shown in this file, our experimental runs were all over 1 hour. |
|
| Resiliency | 12 | 2 | Within each container we have scripts that will detect failure of MUSIC and restart it. However, if the entire container fails, we will need OOM to bring it up. |
|
| Security | 2 | 2 |
|
|
| Scalability | 01 | 1 | Among the MUSIC components [tomcat, zookeeper, cassandra], new MUSIC nodes with the tomcat and cassandra can be added seamlessly to scale the cluster (MUSIC itself is state-less). However, our current version of Zookeeper (3.4.0) does not support dynamic reconfiguration. Will move to Zookeeper 3.5.0 that supports dynamic reconfiguration and test MUSIC sclability. We will also need to work with OOM support to spin new containers on demand for the scalability needsZookeeper nodes ideally should not be scaled since there are major performance implications. However, this can be done with reconfiguration. |
|
| Manageability | 1 | 1 | Using EELF with logback as the logging provider. |
|
| Usability | 1 | 1 | Use SWAGGER for the REST API and Installation Docs. Will need to enhance and update the documentation. |
|
...
None identified so far.
Resources
Udated the Resources Committed to the Release centralized page.
Release Milestone
...