New features in Dublin
- Provide MUSIC as a fully sharded, scale out common 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 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.
Dependency Graph
No incoming dependencies, but this is the basic architecture:
MUSIC Deployment graph (OOM)
MUSIC runs as a common pod that can be used by different components.
S3P Updates
Area | Actual Level | Targeted Level for current Release | How, Evidences | Comments |
|---|---|---|---|---|
Area | Actual Level | Targeted Level for current Release | How, Evidences | Comments |
| Manageability | 1 | 1 | Using EELF with logback as the logging provider. |
|
| Performance | 1 | 1 | This file shows basic performance benchmarks performed for MUSIC on a 10 node cluster. |
|
| Resiliency | 2 | 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. |
|
| Scalability | 1 | 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). Zookeeper nodes ideally should not be scaled since there are major performance implications. However, this can be done with reconfiguration. |
|
| Security | 1 | 1 |
|
|
| Stability | 1 | 1 | As shown in this file, our experimental runs were all over 1 hour. |
|
| Usability | 1 | 1 | Use SWAGGER for the REST API and Installation Docs. Will need to enhance and update the documentation. |
|
S3P Updates 
OOF repos in Dublin
| Repo | Status |
|---|---|
| optf/cmso | seed-code upstreamed in Casablanca, POC |
| optf/has | part of ONAP releases since Beijing release |
| optf/fgps | seed-code being upstreamed in Dublin, POC |
| optf/osdf | part of ONAP releases since Beijing release |
IM/DM Alignment
Service and Resource Info, from: AAI
Network Topology for CM: AAI
HPA Flavors/Capabilities/CapacityInfo, from : AAI
Policy Models (homing, PCI) from: Policy
Infrastructure Metrics Info (capacity), from: MultiCloud
Cloud agnostic Intent Info, from: MultiCloud
AZ level capacity Info, from: MultiCloud (for F-GPS)
PCI configuration data(not yet a part of SDC model)
Provided APIs
Service Orchestrator (Homing, Traffic Distribution): https://wiki.onap.org/pages/viewpage.action?pageId=25435066 (updated for Traffic Distribution)
Change Management Simulator: https://wiki.onap.org/display/DW/CMSO+API+v1_v2 (updated)
PCI Handler MS: https://wiki.onap.org/display/DW/PCI+Optimization+API (updated for joint ANR optimization)
SDNC: https://wiki.onap.org/display/DW/Route+Optimization
HAS -- FGPS: https://wiki.onap.org/display/DW/FGPS+Dependencies+and+APIs (new)
Consumed APIs
AAI REST API Documentation - Casablanca, CMSO, TD and FGPS expect to use existing AAI interfaces.
MultiCloud: https://docs.onap.org/en/latest/submodules/multicloud/framework.git/docs/specs/multicloud_resource_capacity_check.html (updated API for F-GPS)
MUSIC: Casablanca API
SDNC(R) Config DB: https://wiki.onap.org/download/attachments/28382769/SDNC_ConfigDB_API_Ver2.json?api=v2 (updated API for PCI/ANR)
Provided/Consumed Interfaces
