Open Stack

On Wed, May 13, 2015 at 5:42 PM, Zane Bitter <zbitter at redhat.com> wrote:

> There is more to multi-tenancy than just authentication/authorisation.
> It's also things like making sure one tenant's use of resources doesn't
> affect another tenant's (e.g. creating a denial of service by maxing out
> capacity); being able to measure and bill for usage; quotas to prevent
> accidental overuse &c.


This is a indeed a strong point that makes sense for shared MQ broker.
However I'm not convinced that Zaqar approach is an optimal one:
1. There are a several dozens of message-oriented middleware solutions
around (QPID, ActiveMQ, Camel, Kafka, HortnetQ and many more). Many of them
are well know, well tested, have significant user base, published books
etc. Does no one of them could be used instead with additional wrapping or
special configs or additional plugins/extensions? So that is would left
just to implement the integration layer instead of build MQ solution from
scratch?

2. Even RabbitMQ has a lot of things pluggable and just maybe all those
requirements can be met by a set of RabbitMQ plugins. It is also possible
to contribute something to RabbitMQ or any other OSS MQ.

3. I'm not sure that noisy neighbor problem and other QoS related issues
are a big problem here. The question is who is the consumer of MQ? If
consumers are user-land applications running on OpenStack instance VMs a
better solution could be just to set dedicated RabbitMQ/somethingMQ on a VM
for those apps instead of a single shared server. I do understand that a
common shared resource is easier to mange and administrate. On the other
hand it is less secure and subject to QoS issues. There are so many
software configuration management tools around (docker containers and
container managers, prebuilt images, puppet manifests and so on) that it is
not a real challenge any more. And if consumers are other OpenStack
services QoS is unlikely to be a problem because in each OpenStack
distribution there are fixed number of tested services with known shape of
MQ workload.

4. Another option could be just to bring new MQ broker per tenant. For
example to run docker RabbitMQ container per tenant + something small to
manage them (to sync containers with tenant list). Docker has resource
quotas that can be used.

5. Stable API is good. However open and standardized API like AMQP is even
better.

Maybe all of those possible solutions are bad and I'm sure there are
downsides to each approach. It is just not obvious that development of yet
another MQ solution worth it.

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

<slagun at mirantis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150513/ed428319/attachment.html>