Improve scalability by eliminating agent DB polling
The current openvswitch and linuxbridge plugins have agents on each compute node that periodically poll their DBs looking for relevant state changes. This requires a DB connection from each compute node, and polling results in significant average latency in responding to state changes. Nova's RPC mechanism, which is being moved to openstack-common and supports various messaging mechanisms (rabbitmq, qpid, zeromq), should be used for Quantum server<->agent communications in place of DB polling.
Blueprint information
- Status:
- Complete
- Approver:
- dan wendlandt
- Priority:
- High
- Drafter:
- Robert Kukura
- Direction:
- Approved
- Assignee:
- Gary Kotton
- Definition:
- New
- Series goal:
- Accepted for folsom
- Implementation:
- Implemented
- Milestone target:
- 2012.2
- Started by
- Gary Kotton
- Completed by
- dan wendlandt
Related branches
Related bugs
Sprints
Whiteboard
Following everones comments we have:
https:/
This task is based on common configuration and rpc code in openstack common. It is too risky for folsom 2
Gerrit topic: https:/
Addressed by: https:/
RPC support for Linux Bridge Plugin and Agent
Addressed by: https:/
Enable quantum agents to work with global cfg.CONF
[Debo]: Awesome work. A few comments/questions:
* Do you think it might be good to have a publish mechanism from the agent to the controller (in which case you need a publish semantics)
* Might want to make the publish semantics flexible (maybe via extensions) for richer info exchange. Say we use lldp to discover uplinks and publish that to the controller.
Addressed by: https:/
RPC support for OVS Plugin and Agent
Gerrit topic: https:/
Gerrit topic: https:/
Gerrit topic: https:/