The Homing and allocation service (HAS) uses Music for two-fold purposes:
- Conventional geo-distributed state store for intermediate state persistence of homing requests.
- Messaging substrate for interaction between the HAS components (Controller - Data, API - Controller, and Solver-Data)
Notes from meeting on 2/26:
Functional testing HAS depends on using Music for interaction between the various components.
How does the architecture committee want the projects to use Music?
(a) Using Music as a service (shared across all ONAP projects)
(b) Each project has its own instance of Music
(c) Hybrid of (a) and (b)
Need to document Music dependency in architecture diagram, need to take this question to the Architecture subcommittee.
- 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
Functional abstraction of features required by Active/Active HAS:
Persistence:
- Strongly consistent, atomic get/put
Geo-distributed RPC mechanism (messaging beween components across multiple replicas across multiple sites):
- Atomic Enqueue, Dequeue operations
- Distributed atomic Test & Set locks for ensuring each job is picked exactly one worker (component)
Open Questions
Who is responsible for the delivery of Music in either of the above approaches?
>> We'd want this to be Music's responsibility.
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.