Open Stack

Hi,

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.



On Fri, Jan 31, 2014 at 7:31 AM, Alexander Tivelkov
<ativelkov at mirantis.com>wrote:

> Hi folks,
>
> It seems like Murano networking workflow has a problem with the way how it
> uses the allowed_address_pairs property of Neutron ports.
> 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.
>
> 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.
> 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.
> 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.
>
> 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.
>
> So, we need to find some working solution for this situation.
> 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).
> 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.
> May be something else is possible as well. Any ideas are welcome
>
>
>
> [1] https://bugs.launchpad.net/murano/+bug/1274636
> [2] https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs
> [3]
> http://docs.openstack.org/admin-guide-cloud/content/section_allowed_address_pairs_workflow.html
> --
> Regards,
> Alexander Tivelkov
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,
Dmitry Teselkin
Deployment Engineer
Mirantis
http://www.mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140131/ade20631/attachment.html>