Architecture Changes since Beijing

MUSIC as a service: while MUSIC was consumed internally by components in the Beijing release, in Cassablanca we intend to provide MUSIC as an independent multi-site clustered service
Enable automated failure detection and consistent failover across sites for ONAP components using MUSIC through the PROM recipe. It will require no change to the code of the ONAP components and just a few scripting/configuration steps to achieve single-step automated failover while ensuring that the new leader/owner has access to the latest state information.

Dependency Graph

No incoming dependencies, but this is the basic architecture:

S3P Updates

No updates since Beijing: https://wiki.onap.org/display/DW/MUSIC+Cassablanca+Release+Planning where we satisfied the requirements of Cassablanca as well.
While we had two documented vulnerabilities in Beijing for which we obtained a TSC exception, now we do have new vulnerabilities (critical and severe) that we will address before M4: MUSIC-104 - Getting issue details... STATUS
CII badging – 100% https://bestpractices.coreinfrastructure.org/projects/1722
Code Coverage > 60%

MUSIC repos in R3

music
music/prom
music/distributed-kv-store

IM/DM Alignment

NA

API Update

Enhanced the onboarding admin API to provide callback functionality wherein the onboarded app can specify tables, columns, callback REST URL wherein if a column changes, MUSIC will call the callback REST URL- Used by OOF HAS to efficiently read their job queue maintained in MUSIC.

Provided/Consumed Interfaces

Attachments

Browser not supported