<div dir="ltr"><div>Hi,</div><div><br></div><div>The feature to auto-generate IP for cluster (Cluster Management IP and Availability Group IP) looks good idea. In general there is no need to set these IP addresses to some "special" values. And this feature will simplify end-user interface. However, we must provide the chosen IP addresses to the end user via web interface. Without this it will be quite strange improvement - to create a cluster without knowing its endpoints.</div>
<div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 31, 2014 at 7:31 AM, Alexander Tivelkov <span dir="ltr"><<a href="mailto:ativelkov@mirantis.com" target="_blank">ativelkov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:small">Hi folks,</div><div style="font-size:small"><br></div><div style="font-size:small">
It seems like Murano networking workflow has a problem with the way how it uses the allowed_address_pairs property of Neutron ports.</div>
<div style="font-size:small">This problem causes an intermittent bug preventing "Microsoft SQL Server Cluster" application to be deployed in Murano. We have a bug reported about that - [1]. Seems like this issue became a problem since the time when we introduced the "advanced networking", i.e. the algorithm which attempts to automatically pick the proper networking setting for the newly created environment.</div>
<div style="font-size:small"><br></div><div style="font-size:small">Deployment workflow of MS SQL Server Cluster (and, wider, any Murano Application relying on the virtual ip address) uses Neutron's "Allowed Address Pairs" feature ([2]) to specify its virtual ip address, so Neutron allows the calls to this address through the ports of application's machines. </div>
<div style="font-size:small">However, there is a limitation: Neutron does not allow to specify the address to be equal to the fixed ip address of the port (see the first note at [3]). Murano does not assign the ip addresses of any ports explicitly and relies on the automatic ip allocation provided by Neutron. </div>
<div style="font-size:small">In the situation where the fixed IP address is not defined, but allowed_address_pair is set, I would expect Neutron do a little analysis and not to allocate the address provided in the "allowed pair" as the fixed IP. But Neutron does not do it - and the exception is thrown.</div>
<div style="font-size:small"><br></div><div style="font-size:small">However, even the worse situation may happen if such an address conflict appears not on a single port, but on the two different ones: when the ip of allow_address_pair of port A is equal to the static ip of port B. This situation is perfectly fine from Neutron's point of view, and no exception is thrown. However, later, during the configuration of the cluster, the virtual IP will point to one of the real ports - which may cause two machine sharing the same actual ip at the same time. You may guess the consequences. </div>
<div style="font-size:small"><br></div><div style="font-size:small">So, we need to find some working solution for this situation.</div><div style="font-size:small">
The obvious one would be to exclude the virtual ip address from the allocation pools of the subnet, being generated for the environment. This may be tricky (as the cidrs for subnets are picked automatically), but still definitely doable. The problem which I see here is that we will have to do it at the time when the environment is created - i.e. run Neutron API calls from the Dashboard (but we have to do it anyway now, as we check the user's input for cluster ip to match the target subnet). </div>
<div style="font-size:small">Another solution is to remove the option for user to specify the virtual ip at all, and allocate this IP at the runtime of the workflow, when all the ports of the cluster's instances are already created and their IP known. I don't know if there is a real use-case requiring the user to know the virtual ip in advance and be able to control its value. If there is no such scenario, then we may just hide it, and it will simplify things a lot.</div>
<div style="font-size:small">May be something else is possible as well. Any ideas are welcome</div><div style="font-size:small"><br></div><div style="font-size:small">
<br></div><div style="font-size:small"><br></div><div style="font-size:small">
[1] <a href="https://bugs.launchpad.net/murano/+bug/1274636" target="_blank">https://bugs.launchpad.net/murano/+bug/1274636</a></div><div style="font-size:small">[2] <a href="https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs" target="_blank">https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs</a></div>
<div style="font-size:small">[3] <a href="http://docs.openstack.org/admin-guide-cloud/content/section_allowed_address_pairs_workflow.html" target="_blank">http://docs.openstack.org/admin-guide-cloud/content/section_allowed_address_pairs_workflow.html</a></div>
<div><div dir="ltr"><font>--<br></font><div dir="ltr"><font>Regards,<br>Alexander Tivelkov</font></div></div></div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Thanks,</div>Dmitry Teselkin<br>Deployment Engineer<br>
Mirantis<br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a></div>
</div></div>