Murano has several applications which support scaling via load-balancing, this applications (Internet Information Services Web Farm, ASP.NETApplication Web Farm) currently are based on Heat <http://launchpad.net/heat>, particularly on resource called AWS::ElasticLoadBalancing::LoadBalancer<http://docs.openstack.org/developer/heat/template_guide/cfn.html#AWS::ElasticLoadBalancing::LoadBalancer>, that currently does not support<http://docs.openstack.org/developer/heat/template_guide/cfn.html#AWS::ElasticLoadBalancing::LoadBalancer-props> specification of any network related parameters.
Inability to specify network related params leads to incorrect behavior during deployment in tenants with advanced Quantum deployment configuration, like Per-tenant Routers with Private Networks and this makes deployment of our ** Web Farm* applications to fail. We need to resolve issues with our ** Web Farm*, and make this applications to be reference implementation for elastic applications in Murano. This issue may be resolved in three ways: via extending configuration capabilities of AWS::ElasticLoadBalancing::LoadBalancer<http://docs.openstack.org/developer/heat/template_guide/cfn.html#AWS::ElasticLoadBalancing::LoadBalancer>, using another implementation of load balancing in Heat - OS::Neutron::LoadBalancer<http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::LoadBalancer> or via implementing own load balancing application (that going to balance other apllications), for example based on HAProxy <http://haproxy.1wt.eu/> (as all previous ones). Please, respond with your thoughts on the question: "*Which implementation we should use to resolve issue with our Web Farm applications and why?*". Below you can find more details about each of the options. *AWS::ElasticLoadBalancing::LoadBalancer* AWS::ElasticLoadBalancing::LoadBalancer is Amazon Cloud Formation compatible resource that implements load balancer via hard-coded nested stack<https://github.com/openstack/heat/blob/master/heat/engine/resources/loadbalancer.py#L24>that deploys and configures HAProxy. This resource requires specific image with CFN Tools <https://github.com/openstack/heat-cfntools> and specific name *F17-x86_64-cfntools* available in Glance. It's look like we miss implementation of only one property in this resource - Subnets. *OS::Neutron::LoadBalancer* OS::Neutron::LoadBalancer<http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::LoadBalancer>is another Heat resource that implements load balancer. This resource is based on Load Balancer as a Service feature in Neutron<https://wiki.openstack.org/wiki/Neutron/LBaaS>. OS::Neutron::LoadBalancer is much more configurable and sophisticated but underlying implementation makes usage of this resource quite complex. LBaaS is a set of services installed and configured as a part of Neutron. Fuel does not support LBaaS; Devstack has support for LBaaS, but LBaaS not installed by default with Neutron. *Own, Based on HAProxy* We may implement load-balancer as a regular application in Murano using HAProxy <http://haproxy.1wt.eu/>. This service may look like our Active Directory application with almost same user-expirience. User may create load-balancer inside of the environment and join any web-application (with any number of instances) directly to load-balancer. Load-balancer may be also implemented on Conductor workflows level, this implementation strategy not going to change user-experience (in fact we changing only underlying implementation details for our * Web Farm applications, without introducing new ones). -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev