Improve matchmaker to register hosts & have better lookups
The matchmaker per Folsom is simple and static. This was fine for Folsom's Nova and cinder, but does not scale nicely for notifications or the requirements in Ceilometer or Quantum.
The static nature of the current implementations limits dependent drivers from having dynamic queue/exchange registrations as is performed in other implementations.
Currently, only the ZeroMQ driver depends on the matchmaker. However, it is designed to be used by any number of drivers. It is necessary for peer-to-peer messaging, but can also be used as part of message discovery.
These changes may build upon the service-group-api changes, if merged.
The intention of this blueprint is to extend the rpc and matchmaker abstractions such that the matchmaker can dynamically register hosts and to provide an example implementation of a Matchmaker module that does such.
Blueprint information
- Status:
- Complete
- Approver:
- Mark McLoughlin
- Priority:
- Low
- Drafter:
- Erica Windisch
- Direction:
- Approved
- Assignee:
- Erica Windisch
- Definition:
- Approved
- Series goal:
- Accepted for grizzly
- Implementation:
-
Implemented
- Milestone target:
-
2013.1
- Started by
- Mark McLoughlin
- Completed by
- Mark McLoughlin
Related branches
Related bugs
Sprints
Whiteboard
Could do with more work detailing the proposed design
For reference, the existing matchmaker code is https:/
---
Ideally, several backend modules will be available at some point in the future. Note, too, this work overlaps greatly with the ServiceGroup API, although that module is not in oslo and is moving in a direction that will make it difficult to integrate into oslo due to the no-db-compute blueprint (this advanced matchmaker work may, in the short-term, break the no-db-compute guarantee)
Initially, I'm considering a data-store driven design. This won't be the most secure and may not be the most scalable from an absolute perspective, but is something we can put in as a workable default for moderate levels of scale.
- SQLAlchemy is possible with the common-db blueprint. Advantage is that it leverages existing SQL infrastructure, but the disadvantage is that we don't need SQL and the troubles it brings.
- Another solution is a pure rpc mechanism. This could leverage the trusted-messaging blueprint. However, this has circular dependency issues since the matchmaker is used by impl_zmq. Additionally Russell has already expressed difficulties in attempting to build a similar implementation for ServiceGroup API.
- Far-from-finally, we have Redis. It is simple to update, simple to query, and has pub/sub built-in to handle scale-out. It also has key expiration and durability built-in. There are much better implementations that can be made, but this is something that is relatively quick and easy to put together and use as a baseline for creating more complex matchmakers down the road.
--
Patch here: https:/
Work Items
Work items:
Finish design: DONE
Draft lookups: DONE
Create and integrate rpc hooks for topic registration: DONE
Draft heartbeat updates: DONE
Draft heartbeat expiration: DONE
Implement local caching (optional): TODO
Write tests: DONE
Code-review: INPROGRESS
Dependency tree
* Blueprints in grey have been implemented.
