Open Stack

On 06/04/2013 10:31 AM, Sandy Walsh wrote:
> Hi Rosa!
> 
> On 06/04/2013 10:13 AM, Rosa, Andrea (HP Cloud Services) wrote:
>> Hi all,
>>
>> I am looking at the rpc_notifier and I noticed that, as the system is designed, we can have queues on the broker (like RabbitMQ) with a lot of unread messages.
>> Please consider this scenario:
>> We have two external systems one is using a notification called "monitor" and the other one a notification called "billing".
>> The first notification needs to get all notifications with the priority equal to  ERROR or INFO (let assume that we have just these two values for priority), the billing notification is interested just in the INFO notifications.
>> The results of this configuration is that we have 4 queues in the system:
>> Monitor.info => queue with consumer(s)
>> Monitor.error => queue with consumer(s)
>> Billing.info => queue with consumer(s)
>> Billing.error => queue without consumer(s)
>>
>> Messages in the last queue will never get fetched ,  but they will be on the sever consuming resources. Is that correct?
> 
> Yes, that is correct.
> 
>> If so, what about change the logic in the rpc_notifier  so as we can filter notification  messages by the priority types?
> 
> I think Dragon has a branch that allows for event filtering in the
> notifier. I'll let him comment on that.
> 
>> We could do that putting this information in the "notification_topics" parameter, I was thinking to something like that: monitor, billing:info
>> If no priorities are defined, the notify will happen for each priority type otherwise a filter will be applied, in that case for the billing notification only the priority type equal to info will be send.
> 
> That would be a handy addition.
> 
>> Does that make sense or I am completely missing any points?
> 
> Yep, sounds reasonable. I would check to see if Dragon's branch might
> help solve this?

What branch?


-- 
Russell Bryant