Open Stack

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 | smelikyan at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131115/bdea6a2a/attachment.html>