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
