Comment 6 for bug 1445295

So there are a couple of points I wanted to add here for more contextl:

1. The way Trove is deployed in devstack is to deploy Trove into the user's tenant directly and is inherently insecure. However it is the simplest way to deploy Trove and suffices for dev testing. For a production deploy, I'd suggest deploying Trove into its own tenant or even in its own private cloud. If Trove is deployed in its own Tenant, the Trove guest images are uploaded only for this tenant, and should NOT be made public. Also users cannot access cinder volumes in the Trove tenant. The Trove deployment docs are lacking in this regard, and this is identified as something that we need to work on updating in Liberty.

2. Also Trove should not use the same RabbitMQ server as the rest of the services (undercloud). The reason for this is that this RabbitMQ server is usually on bare metal, and the Trove services are all usually deployed as a workload in the cloud. Having a users' instances reach out from inside the cloud to something on bare-metal is not a good idea. Given Trove should use a separate RabbitMQ server for its use (one user is sufficient, not one user per tenant), it does not need access to the infrastructure RabbitMQ.