Open Stack

On 09/10/2014 07:29 PM, Clint Byrum wrote:
> Excerpts from Gordon Sim's message of 2014-09-10 06:18:52 -0700:
>> On 09/10/2014 09:58 AM, Flavio Percoco wrote:
>>>      Other OpenStack components can integrate with Zaqar to surface events
>>> to end users and to communicate with guest agents that run in the
>>> "over-cloud" layer.
>>
>> I may be misunderstanding the last sentence, but I think *direct*
>> integration of other OpenStack services with Zaqar would be a bad idea.
>>
>> Wouldn't this be better done through olso.messaging's notifications in
>> some way? and/or through some standard protocol (and there's more than
>> one to choose from)?
>>
>
> It's not direct, nobody is suggesting that.
>
> What people are suggesting is that a user would be able to tell Nova
> to put any messages that would want to deliver in a _user_ focused
> queue/inbox.
>
> This has nothing to do with oslo.messaging. Users don't want many options
> for backends. They want a simple message passing interface so they don't
> have to babysit one and choose one.
>
> Certainly the "undercloud" Zaqar API could be based on the existing
> oslo.messaging notifications. A simple daemon that sits between the oslo
> notifications firehose and Zaqar's user queues would be quite efficient.

Right, that's what I meant. The interface applications have to it would 
of course not be oslo.messaging notifications.

> However, putting the whole burden of talking directly to a notification
> bus on the users is unnecessarily complex... especially if they use Java
> and have no idea what oslo is.

Agreed. I actually think for applications, making them accessible 
through standard protocols would be an advantage. E.g. for java as you 
mention, there are JMS clients for AMQP or STOMP. Thats not to say that 
Zaqar's protocol as built on top of HTTP is not also an option, just 
that - in my opinion - it shouldn't be the only possible one. (I.e. Nova 
shouldn't be directly tied to Zaqar as the only way for users to get 
relevant message from it).

>> Communicating through a specific, fixed messaging system, with its own
>> unique protocol is actually a step backwards in my opinion, especially
>> for things that you want to keep as loosely coupled as possible. This is
>> exactly why various standard protocols emerged.
>>
>
> You're thinking like an operator. Think like an application developer.
> They're asking you "how do I subscribe to notifications about _just my
> instances_ from Nova?", not "how do I pump 40,000 messages per second
> through a message bus that I fully control?"

I'm not sure why you think that from my statement. I wasn't talking 
about performance. I was talking about choice both for deployment *and* 
application developers.