<p dir="ltr">Other that #1 that's exactly the same design we used for Trove. Glad to see someone else using it too for validation. Thanks. </p>
<div class="gmail_extra"><br><div class="gmail_quote">On Sep 22, 2016 11:39 PM, "Serg Melikyan" <<a href="mailto:smelikyan@mirantis.com">smelikyan@mirantis.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Joe,<br>
<br>
I can share some details on how murano is configured as part of the<br>
default Mirantis OpenStack configuration and try to explain why it's<br>
done in that way as it's done, I hope it helps you in your case.<br>
<br>
As part of Mirantis OpenStack second instance of the RabbitMQ is<br>
getting deployed specially for the murano, but it's configuration is<br>
different than for the RabbitMQ instance used by the other OpenStack<br>
components.<br>
<br>
Why to use separate instance of the RabbitMQ?<br>
     1. Prevent possibility to get access to the RabbitMQ supporting<br>
whole cloud infrastructure by limiting access on the networking level<br>
rather than rely on authentication/authorization<br>
     2. Prevent possibility of DDoS by limiting access on the<br>
networking level to the infrastructure RabbitMQ<br>
<br>
Given that second RabbitMQ instance is used only for the murano-agent<br>
<-> murano-engine communications and murano-agent is running on the<br>
VMs we had to make couple of changes in the deployment of the RabbitMQ<br>
(bellow I am referencing RabbitMQ as RabbitMQ instance used by Murano<br>
for m-agent <-> m-engine communications):<br>
<br>
1. RabbitMQ is not clustered, just separate instance running on each<br>
controller node<br>
2. RabbitMQ is exposed on the Public VIP where all OpenStack APIs are exposed<br>
3. It's has different port number than default<br>
4. HAProxy is used, RabbitMQ is hidden behind it and HAProxy is always<br>
pointing to the RabbitMQ on the current primary controller<br>
<br>
Note: How murano-agent is working? Murano-engine creates queue with<br>
uniq name and put configuration tasks to that queue which are later<br>
getting picked up by murano-agent when VM is booted and murano-agent<br>
is configured to use created queue through cloud-init.<br>
<br>
#1 Clustering<br>
<br>
* Given that per 1 app deployment from we create 1-N VMs and send 1-M<br>
configuration tasks, where in most of the cases N and M are less than<br>
3.<br>
* Even if app deployment will be failed due to cluster failover it's<br>
can be always re-deployed by the user.<br>
* Controller-node failover most probably will lead to limited<br>
accessibility of the Heat, Nova & Neutron API and application<br>
deployment will fail regardless of the not executing configuration<br>
task on the VM.<br>
<br>
#2 Exposure on the Public VIP<br>
<br>
One of the reasons behind choosing RabbitMQ as transport for<br>
murano-agent communications was connectivity from the VM - it's much<br>
easier to implement connectivity *from* the VM than *to* VM.<br>
<br>
But even in the case when you are connecting to the broker from the VM<br>
you should have connectivity and public interface where all other<br>
OpenStack APIs are exposed is most natural way to do that.<br>
<br>
#3 Different from the default port number<br>
<br>
Just to avoid confusion from the RabbitMQ used for the infrastructure,<br>
even given that they are on the different networks.<br>
<br>
#4 HAProxy<br>
<br>
In case of the default Mirantis OpenStack configuration is used mostly<br>
to support non-clustered RabbitMQ setup and exposure on the Public<br>
VIP, but also helpful in case of more complicated setups.<br>
<br>
P.S. I hope my answers helped, let me know if I can cover something in<br>
more details.<br>
--<br>
Serg Melikyan, Development Manager at Mirantis, Inc.<br>
<a href="http://mirantis.com" rel="noreferrer" target="_blank">http://mirantis.com</a> | <a href="mailto:smelikyan@mirantis.com">smelikyan@mirantis.com</a><br>
<br>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
</blockquote></div></div>