<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div>Support for deploying the Neutron LBaaS is on the roadmap for the Fuel project, yes – but most likely not before IceHouse at current velocity.</div><div><br></div><div><div>- David J. Easter</div><div>  Product Line Manager,  Mirantis </div></div><span id="OLK_SRC_BODY_SECTION"><div dir="ltr"><div><br><div class="gmail_quote">---------- Forwarded message ----------<br>

From: <b class="gmail_sendername">Serg Melikyan</b> <span dir="ltr"><<a href="mailto:smelikyan@mirantis.com">smelikyan@mirantis.com</a>></span><br>Date: Wed, Nov 27, 2013 at 6:52 PM<br>Subject: Re: [openstack-dev] [Murano] [Neutron] [Fuel] Implementing Elastic Applications<br>

To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, <a href="mailto:fuel-dev@lists.launchpad.net">fuel-dev@lists.launchpad.net</a><br><br><br><div dir="ltr">I had added Neutron and Fuel teams to this e-mail thread: Guys what is your thoughts on the subject?<div><br></div><div>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).</div><div><br></div><div>Previously we was using Heat and AWS::ElasticLoadBalancing::LoadBalancer resource, but this way have certain limitations. </div><div><br></div><div>Does Fuel team have plans to implement support for Neutron LBaaS any time soon? <br></div><div><br></div><div>Guys from Heat suggest Neutron LBaaS as a best long-term solution. Neutron Team - what is your thoughts? </div><div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 15, 2013 at 6:53 PM, Thomas Hervé <span dir="ltr"><<a href="mailto:therve@gmail.com" target="_blank">therve@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>On Fri, Nov 15, 2013 at 12:56 PM, Serg Melikyan <<a href="mailto:smelikyan@mirantis.com" target="_blank">smelikyan@mirantis.com</a>> wrote:<br>
> Murano has several applications which support scaling via load-balancing,<br>
> this applications (Internet Information Services Web Farm, <a href="http://ASP.NET" target="_blank">ASP.NET</a><br>
> Application Web Farm) currently are based on Heat, particularly on resource<br>
> called AWS::ElasticLoadBalancing::LoadBalancer, that currently does not<br>
> support specification of any network related parameters.<br>
><br>
> Inability to specify network related params leads to incorrect behavior<br>
> during deployment in tenants with advanced Quantum deployment configuration,<br>
> like Per-tenant Routers with Private Networks and this makes deployment of<br>
> our * Web Farm applications to fail.<br>
><br>
> We need to resolve issues with our * Web Farm, and make this applications to<br>
> be reference implementation for elastic applications in Murano.<br>
><br>
> This issue may be resolved in three ways: via extending configuration<br>
> capabilities of AWS::ElasticLoadBalancing::LoadBalancer, using another<br>
> implementation of load balancing in Heat - OS::Neutron::LoadBalancer or via<br>
> implementing own load balancing application (that going to balance other<br>
> apllications), for example based on HAProxy (as all previous ones).<br>
><br>
> Please, respond with your thoughts on the question: "Which implementation we<br>
> should use to resolve issue with our Web Farm applications and why?". Below<br>
> you can find more details about each of the options.<br>
><br>
> AWS::ElasticLoadBalancing::LoadBalancer<br>
><br>
> AWS::ElasticLoadBalancing::LoadBalancer is Amazon Cloud Formation compatible<br>
> resource that implements load balancer via hard-coded nested stack that<br>
> deploys and configures HAProxy. This resource requires specific image with<br>
> CFN Tools and specific name F17-x86_64-cfntools available in Glance. It's<br>
> look like we miss implementation of only one property in this resource -<br>
> Subnets.<br>
><br>
> OS::Neutron::LoadBalancer<br>
><br>
> OS::Neutron::LoadBalancer is another Heat resource that implements load<br>
> balancer. This resource is based on Load Balancer as a Service feature in<br>
> Neutron. OS::Neutron::LoadBalancer is much more configurable and<br>
> sophisticated but underlying implementation makes usage of this resource<br>
> quite complex.<br>
> LBaaS is a set of services installed and configured as a part of Neutron.<br>
> Fuel does not support LBaaS; Devstack has support for LBaaS, but LBaaS not<br>
> installed by default with Neutron.<br>
><br>
> Own, Based on HAProxy<br>
><br>
> We may implement load-balancer as a regular application in Murano using<br>
> HAProxy. This service may look like our Active Directory application with<br>
> almost same user-expirience. User may create load-balancer inside of the<br>
> environment and join any web-application (with any number of instances)<br>
> directly to load-balancer.<br>
> Load-balancer may be also implemented on Conductor workflows level, this<br>
> implementation strategy not going to change user-experience (in fact we<br>
> changing only underlying implementation details for our * Web Farm<br>
> applications, without introducing new ones).<br><br></div></div>Hi,<br><br>
I would strongly encourage using OS::Neutron::LoadBalancer. The AWS<br>
resource is supposed to mirror Amazon capabilities, so any extension,<br>
while not impossible, is frowned upon. On the other hand the Neutron<br>
load balancer can be extended to your need, and being able to use an<br>
API gives you much more flexibility. It also in active development and<br>
will get more interesting features in the future.<br><br>
If you're having concerns about deploying Neutron LBaaS, you should<br>
bring it up with the team, and I'm sure they can improve the<br>
situation. My limited experience with it in devstack has been really<br>
good.<br><br>
Cheers,<span class="HOEnZb"><font color="#888888"><br><span><font color="#888888"><br>
--<br>
Thomas<br></font></span><div><div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div></div></font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Serg Melikyan, Senior Software Engineer at Mirantis, Inc.<br></div><div><a href="http://mirantis.com/" target="_blank">http://mirantis.com</a> | <a href="mailto:smelikyan@mirantis.com" target="_blank">smelikyan@mirantis.com</a><br></div></div></font></span></div></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br><br></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Mike Scherbakov</div><div>#mihgen</div></div></div></div></span></body></html>