[Openstack-operators] Murano in Production
joe at topjian.net
Mon Sep 19 03:24:36 UTC 2016
I think Matt bringing up Trove is worthwhile, too. If we were to consider
deploying Trove in the future, and now that I've learned it also has an
agent/rabbit setup, there's definitely more weight behind a second
agent-only Rabbit cluster.
On Sun, Sep 18, 2016 at 9:15 PM, Sam Morrison <sorrison at gmail.com> wrote:
> You could also use https://www.rabbitmq.com/maxlength.html to mitigate
> overflowing on the trove vhost side.
> On 19 Sep 2016, at 1:07 PM, Joe Topjian <joe at topjian.net> wrote:
> Thanks for everyone's input. I think I'm going to go with a single Rabbit
> cluster and separate by vhosts. Our environment is nowhere as large as
> NeCTAR or TWC, so I can definitely understand concern about Rabbit blowing
> the cloud up. We can be a little bit more flexible.
> As a precaution, though, I'm going to route everything through a new
> HAProxy frontend. At first, it'll just point to the same Rabbit cluster,
> but if we need to create a separate cluster, we'll swap the backend out.
> That should enable existing Murano agents to continue working.
> If this crashes and burns on us, I'll be more than happy to report
> failure. :)
> On Sun, Sep 18, 2016 at 7:38 PM, Silence Dogood <matt at nycresistor.com>
>> I'd love to see your results on this . Very interesting stuff.
>> On Sep 17, 2016 1:37 AM, "Joe Topjian" <joe at topjian.net> wrote:
>>> Hi all,
>>> We're planning to deploy Murano to one of our OpenStack clouds and I'm
>>> debating the RabbitMQ setup.
>>> For background: the Murano agent that runs on instances requires access
>>> to RabbitMQ. Murano is able to be configured with two RabbitMQ services:
>>> one for traditional OpenStack communication and one for the Murano/Agent
>>> From a security/segregation point of view, would vhost separation on our
>>> existing RabbitMQ cluster be sufficient? Or is it recommended to have an
>>> entirely separate cluster?
>>> As you can imagine, I'd like to avoid having to manage *two* RabbitMQ
>>> clusters. :)
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators