Open Stack

Hi,

I believe that we restricted to have a single solution only: Murano is an
Application Catalog now, and Catalog is the thing where multiple similar
solutions can be present, and the user makes the final decision on what to
pick for their environments.
So, I would suggest to bundle a solution based on OS::Neutron::LoadBalancer
- and have a blueprint describing that homemade HAProxy-based solution -
someone will implement it sooner or later, as the demand for such a service
clearly exists (and will definitely increase when we introduce the ability
to share a single VM for multiple applications).

--
Regards,
Alexander Tivelkov


2013/11/15 Serg Melikyan <smelikyan at mirantis.com>

> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131115/648f3da3/attachment.html>