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
ativel...@mirantis.comwrote:
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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thanks,
Dmitry Teselkin
Deployment Engineer
Mirantis
http://www.mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
