fuel-dev team mailing list archive

[David Easter <deaster@xxxxxxxxxxxx>]

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 <smelikyan@xxxxxxxxxxxx>
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)"
<openstack-dev@xxxxxxxxxxxxxxxxxxx>, fuel-dev@xxxxxxxxxxxxxxxxxxx


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é <therve@xxxxxxxxx> wrote:
> On Fri, Nov 15, 2013 at 12:56 PM, Serg Melikyan <smelikyan@xxxxxxxxxxxx>
> 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
> OpenStack-dev@xxxxxxxxxxxxxxxxxxx
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com <http://mirantis.com/>  | smelikyan@xxxxxxxxxxxx

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@xxxxxxxxxxxxxxxxxxx
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Mike Scherbakov
#mihgen