Difference between revisions of "Ceilometer/blueprints/move-listener-framework-oslo"
| Line 15: | Line 15: | ||
== User stories == | == User stories == | ||
| + | |||
| + | Ceilometer wants to listen to notifications from all of the other [[OpenStack]] components in the collector process. A deployer needs to be able to run multiple copies of the collector, to spread the processing load of the incoming notification messages. No message should be processed more than one time, so the existing fanout subscription model does not work. The messages are not wrapped in RPC envelopes, so the [[ProxyCallback]] class used by the create_worker() API does not work (and we can't just create a different dispatcher). | ||
== Assumptions == | == Assumptions == | ||
| + | |||
| + | 1. The API should not make any assumptions about the format of incoming messages beyond the usual signing and JSON serialization assumptions made for all other messages. | ||
| + | 2. The API should not make any assumptions about which control exchange should be used for listening to incoming messages. | ||
| + | 3. The API should not make any assumptions about the queue name to be used for listening to incoming messages. | ||
== Design == | == Design == | ||
| + | |||
| + | A new method on the Connection class will avoid backwards-compatibility issues. | ||
| + | |||
| + | |||
| + | <pre><nowiki> | ||
| + | def join_consumer_pool(self, pool_name, topic, exchange_name, callback): | ||
| + | """ | ||
| + | </nowiki></pre> | ||
| + | |||
== Implementation == | == Implementation == | ||
Revision as of 17:58, 6 February 2013
- Launchpad Entry: CeilometerSpec:move-listener-framework-oslo
- Created: 05 Feb 2013
- Contributors: Doug Hellmann
Summary
Ceilometer and Quantum use private methods of the RPC connection object to configure themselves to listen to a queue shared among a group of workers. This blueprint discusses how we can make that API public.
Release Note
Rationale
Ceilometer and Quantum are using private methods of the RPC Connection class, which restricts them to the kombu or qpid implementations. We want to make the API public to facilitate implementations in the other RPC drivers.
User stories
Ceilometer wants to listen to notifications from all of the other OpenStack components in the collector process. A deployer needs to be able to run multiple copies of the collector, to spread the processing load of the incoming notification messages. No message should be processed more than one time, so the existing fanout subscription model does not work. The messages are not wrapped in RPC envelopes, so the ProxyCallback class used by the create_worker() API does not work (and we can't just create a different dispatcher).
Assumptions
1. The API should not make any assumptions about the format of incoming messages beyond the usual signing and JSON serialization assumptions made for all other messages. 2. The API should not make any assumptions about which control exchange should be used for listening to incoming messages. 3. The API should not make any assumptions about the queue name to be used for listening to incoming messages.
Design
A new method on the Connection class will avoid backwards-compatibility issues.
def join_consumer_pool(self, pool_name, topic, exchange_name, callback): """
Implementation
UI Changes
Code Changes
Migration
Include:
- data migration, if any
- redirects from old URLs to new ones, if any
- how users will be pointed to the new way of doing things, if necessary.
Test/Demo Plan
This need not be added or completed until the specification is nearing beta.
Unresolved issues
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.
