Open Stack

On 04/09/2015 08:00 PM, Min Pae wrote:
> Not sure whether Zaqar is the best method for this (although I’m not
> saying it isn’t yet).  Zaqar has a REST API, so it meets the “web
> centric” requirement.  However, I believe Zaqar is meant to be a message
> queue for end users, whereas a "notification system” would be for just
> notifications.  It’s certainly possible to implement the latter over the
> former, but I personally favor simple implementations, because simple is
> usually easier to scale.

I think this thread has driven me to believe even more that Zaqar has
all the semantic options we need for Heat notifications (point-to-point,
broadcast, etc).

> Also for the purpose of providing Openstack service notifications,
> coupling the transport/mechanism for those service notifications with a
> message queue service that can be used by customer applications would
> risk a denial of service (whether malicious or not) for the service
> notifications.  This isn’t necessarily just from malicious attacks, it
> could happen just by having a really busy end user application for the
> message queue service.

I disagree with this as an argument. The point of a multi-tenant service
is that tenants are sufficiently isolated from each other in security,
performance, and management terms.

If Zaqar (or any other OpenStack consumer-facing service) can't separate
tenants sufficiently, that's a bug that needs to be fixed, not something
we should be designing around. Zaqar is built* to be a busy message
queue service and will handle that workload, or be replaced by something
that can.

*if it weren't, that would also be a bug.

> 
> - Min
> ... [snip] ...

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.