...
Need to document Music dependency in architecture diagram, need to take this question to the Architecture subcommittee.
[MUSIC teams response (Bharath Balasubramanian, PTL): I have spoken to the architecture committee about it and they essentially leave the decision to individual projects and MUSIC of course. The MUSIC team's recommendation is as follows: While ideally MUSIC should be used as a shared service among ONAP components, for Beijing, it might be easier for teams to use them as its own instance, since MUSIC was accepted only recently as a project and is still working its way through the LF processes. ]
- HAS should ideally be decoupled from the underlying data persistence/messaging layer.
- Current HAS code has no Music specific dependencies, but uses the distributed persistent queuing semantics provided Music for the Active/Active architecture.
- R3+ item: create plugins for effectively realizing the above decoupling
...
>> We'd want this to be Music's responsibility.
[MUSIC teams response (Bharath Balasubramanian, PTL): The MUSIC team will certainly deliver the APIs as required by ONAP HAS and Portal. However, there is still an open question on how MUSIC will be discovered. This will require a discussion with the architecture committee with the inputs of both MSB and OOM that we can have on 3/6/2018.]
Is geo-redundancy a key requirement for all deployments?
...