Open Stack

On 10/10/2012 07:47 AM, Doug Hellmann wrote:
> 
> 
> On Oct 10, 2012, at 6:40 AM, Russell Bryant <rbryant at redhat.com> wrote:
> 
>> On 10/09/2012 09:21 PM, Mark McClain wrote:
>>> Notifications are only used for plugin -> agent communication.  (Data flows the other way via RPC).  Generally, I am not in favor of using RPC for broadcasting information.  RPC requires the plugin know in advance where that data is routed on the receiver and often results in lots of redundent boilerplate interface code.  Also creating a private interface for notifications, results in another API layer that must be maintained.  Eventually one of the apis will suffer from bit rot without duplicative work to ensure they stay in sync.
>>
>> I'm not sure what you're suggesting here.  Using rpc fanout_cast results
>> in the same messaging pattern used with notifications from the plugin to
>> agent today, but uses an API intended for internal communications.
> 
> The delivery pattern is the same in the message bus, but the publisher and subscriber must follow specific conventions in order to connect the two endpoints. For example, the name of the method in the client configured to receive the message must be included in the message payload by the sender. That makes the current RPC library poorly suited for publishers that want to send information to multiple or unknown receiver implementations because the sender and receiver are tightly coupled by the library API.

Right.  The quantum plugin to agent communication is doing rpc in this
manner and basically following this convention, but by going an odd
route using notifications to do it.

> Part of what I want to discuss in the "Using the messaging bus for messages" session at the summit is requirements for a new API for general message publishing that meets some of the needs of ceilometer in a way that would be useful for other tools that need to share data.
> 
>>
>>> Ceilometer consumes notifications across all projects that emit them, so I'm not sure they would back your proposal about privatizing this communication channel.  The summit will feature sessions to discuss the notification framework in common and how to improve it  I'm looking forward to those sessions.
>>
>> Part of the purpose of this thread was that I wanted to find out if
>> anything (including Celiometer) uses the notifications from Quantum.  I
>> certainly am not proposing getting rid of notifications in general.  If
>> they are only in Quantum for plugin to agent communications, then
>> notifications are not the ideal API to be using.
> 
> Ceilometer is consuming these notifications. We are, at this point, consuming notifications from most of the other OpenStack projects.

Ok, thanks.  That is the key bit I needed.  That means that the current
notifications need to stay, which is fine.

It still seems odd to rely on notifications for the private plugin ->
agent communication.  It seems worthwhile to separate these private
communications from what is intended to be used by things outside of
quantum, such as celiometer.

-- 
Russell Bryant