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

• 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

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)

2

2

• SSL Communication’s between Cassandra Cluster Nodes.
• REST over HTTPS with AAF for Authentication.

• 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

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

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

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