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?" _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
