Good call. 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 <sorri...@gmail.com> wrote: > You could also use https://www.rabbitmq.com/maxlength.html to mitigate > overflowing on the trove vhost side. > > > Sam > > > On 19 Sep 2016, at 1:07 PM, Joe Topjian <j...@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 <m...@nycresistor.com> > wrote: > >> I'd love to see your results on this . Very interesting stuff. >> >> On Sep 17, 2016 1:37 AM, "Joe Topjian" <j...@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@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >>> > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
