Open Stack

Excerpts from Gordon Sim's message of 2014-09-10 06:18:52 -0700:
> On 09/10/2014 09:58 AM, Flavio Percoco wrote:
> > To clarify the doubts of what Zaqar is or it's not, let me quote what's
> > written in the project's overview section[0]:
> >
> >     "Zaqar is a multi-tenant cloud messaging service for web developers.
> 
> How are different tenants isolated from each other? Can different 
> tenants access the same queue? If so, what does Zaqar do to prevent one 
> tenant from negatively affecting the other? If not, how is communication 
> with other tenants achieved.
> 
> Most messaging systems allow authorisation to be used to restrict what a 
> particular user can access and quotas to restrict their resource 
> consumption. What does Zaqar do differently?
> 
> > It
> > combines the ideas pioneered by Amazon's SQS product with additional
> > semantics to support event broadcasting.
> >
> >     The service features a fully RESTful API, which developers can use to
> > send messages between various components of their SaaS and mobile
> > applications, by using a variety of communication patterns. Underlying
> > this API is an efficient messaging engine designed with scalability and
> > security in mind.
> >
> >     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.

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.

> 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?"