MUSIC Dublin (R4) Architecture Alignment

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.	1 – single logging system across components; instantiation in < 1 hour 2 – ability to upgrade a single component; tracing across components; externalized configuration management
Performance	1	1	This file shows basic performance benchmarks performed for MUSIC on a 10 node cluster.	0 -- none 1 – baseline performance criteria identified and measured 2 & 3 – performance improvement plans created & implemented
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.	0 – none 1 – manual failure and recovery (< 30 minutes) 2 – automated detection and recovery (single site) 3 – automated detection and recovery (geo redundancy)
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.	0 – no ability to scale 1 – single site horizontal scaling 2 – geographic scaling 3 – scaling across multiple ONAP instances
Security	1	1	SSL Communication’s between Cassandra Cluster Nodes. REST over HTTPS with AAF for Authentication. `CII`	0 – none 1 – CII Passing badge + 50% Test Coverage 2 – CII Silver badge; internal communication encrypted; role-based access control and authorization for all calls 3 – CII Gold
Stability	1	1	As shown in this file, our experimental runs were all over 1 hour.	0 – none 1 – 72 hours component level soak w/random transactions 2 – 72 hours platform level soak w/random transactions 3 – 6 months track record of reduced defect rate
Usability	1	1	Use SWAGGER for the REST API and Installation Docs. Will need to enhance and update the documentation.	1 – user guide; deployment documentation; API documentation 2 – UI consistency; usability testing; tutorial 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)