<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 13, 2015 at 5:42 PM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.</blockquote></div><br>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:</div><div class="gmail_extra">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?</div><div class="gmail_extra"><br></div><div class="gmail_extra">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. </div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">5. Stable API is good. However open and standardized API like AMQP is even better.  </div><div class="gmail_extra"><br></div><div class="gmail_extra">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.<br><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small">Sincerely yours,<br>Stan Lagun<br>Principal Software Engineer @ Mirantis</span></span><br><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small"><br><a href="mailto:slagun@mirantis.com" target="_blank"></a></span></span></div></div></div>
</div></div>