...
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?
>> We will need to support geo-redundancy in R3 (maybe HAS is ahead of the curve), but HAS should also be able to support local deployments using alternate persistence/messaging mechanisms.
[MUSIC teams response (Bharath Balasubramanian, PTL): While the MUSIC team understands that OOF may want to support other persistence mechanisms for local deployments, we do advice that due care is taken to ensure that when going from local to multi-site, performance, availability and correctness are not compromised. ]