<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi folks,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" 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 class="gmail_default" 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 class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" 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 class="gmail_default" 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 class="gmail_default" 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 class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" 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 class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So, we need to find some working solution for this situation.</div><div class="gmail_default" 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 class="gmail_default" 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 class="gmail_default" style="font-size:small">May be something else is possible as well. Any ideas are welcome</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" 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 class="gmail_default" 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 class="gmail_default" style="font-size:small">[3] <a href="http://docs.openstack.org/admin-guide-cloud/content/section_allowed_address_pairs_workflow.html">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>