<div dir="ltr">Hi Benoit:<br><br>The rabbitmq server that the trove components use to communicate with<br>each other doesn't (and in fact _shouldn't_) necessarily be the same<br>rabbitmq server that the core openstack services are using for<br>communcation.<br><br>In most real-world deployments of OpenStack Trove that I am aware of,<br>a separate in-cloud rabbitmq cluster is set up for Trove to use. The<br>Trove control plane (api / taskmanager / conductor) is also deployed<br>as a workload in the cloud and guest VMs also run as workloads in the<br>same cloud. Consequently, all communication happens between vms -- all<br>part of the same cloud. There isn't a necessity for the guest agent to<br>be able to communicate with the infrastructure rabbitmq server running<br>on bare-metal, so there really isn't a security concern here.<br><br>Hope this helps to clarify the situation,<br><br>Thanks, <br>Nikhil<br><br></div>