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 <[email protected]> > 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 | [email protected] > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
