Open Stack

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>
wrote:

> 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
>> communication.
>>
>> 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. :)
>>
>> Thanks,
>> Joe
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160918/63ce3f0f/attachment.html>