Support for deploying the Neutron LBaaS is on the roadmap for the Fuel project, yes but most likely not before IceHouse at current velocity.
- David J. Easter Product Line Manager, Mirantis ---------- Forwarded message ---------- From: Serg Melikyan <[email protected]> Date: Wed, Nov 27, 2013 at 6:52 PM Subject: Re: [openstack-dev] [Murano] [Neutron] [Fuel] Implementing Elastic Applications To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]>, [email protected] I had added Neutron and Fuel teams to this e-mail thread: Guys what is your thoughts on the subject? We see three possible ways to implement Elastic Applications in Murano: using Heat & Neutron LBaaS, Heat & AWS::ElasticLoadBalancing::LoadBalancer resource and own solution using HAProxy directly (see more details in the mail-thread). Previously we was using Heat and AWS::ElasticLoadBalancing::LoadBalancer resource, but this way have certain limitations. Does Fuel team have plans to implement support for Neutron LBaaS any time soon? Guys from Heat suggest Neutron LBaaS as a best long-term solution. Neutron Team - what is your thoughts? On Fri, Nov 15, 2013 at 6:53 PM, Thomas Hervé <[email protected]> wrote: > On Fri, Nov 15, 2013 at 12:56 PM, Serg Melikyan <[email protected]> > wrote: >> > Murano has several applications which support scaling via load-balancing, >> > this applications (Internet Information Services Web Farm, ASP.NET >> <http://ASP.NET> >> > Application Web Farm) currently are based on Heat, particularly on resource >> > called AWS::ElasticLoadBalancing::LoadBalancer, that currently does not >> > support 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, using another >> > implementation of load balancing in Heat - OS::Neutron::LoadBalancer or via >> > implementing own load balancing application (that going to balance other >> > apllications), for example based on HAProxy (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 that >> > deploys and configures HAProxy. This resource requires specific image with >> > CFN Tools 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 is another Heat resource that implements load >> > balancer. This resource is based on Load Balancer as a Service feature in >> > Neutron. 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. 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). > > Hi, > > I would strongly encourage using OS::Neutron::LoadBalancer. The AWS > resource is supposed to mirror Amazon capabilities, so any extension, > while not impossible, is frowned upon. On the other hand the Neutron > load balancer can be extended to your need, and being able to use an > API gives you much more flexibility. It also in active development and > will get more interesting features in the future. > > If you're having concerns about deploying Neutron LBaaS, you should > bring it up with the team, and I'm sure they can improve the > situation. My limited experience with it in devstack has been really > good. > > Cheers, > > -- > Thomas > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com <http://mirantis.com/> | [email protected] _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
