<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div>1) Can you give some best practice for trove?</div><div>2) What about the security for trove components?</div><br><div>--<br><div>Best</div><div>    Li Tianqing</div></div><div id="divNeteaseMailCard"></div><br>At 2015-04-17 11:04:47, "Nikhil Manchanda" <nikhil@manchanda.me> wrote:<br> <blockquote id="isReplyContent" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><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>
</blockquote></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>