Re: [openstack-dev] [Murano] [Neutron] [Fuel] Implementing Elastic Applications
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 smelik...@mirantis.com 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@lists.openstack.org, fuel-...@lists.launchpad.net 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é the...@gmail.com wrote: On Fri, Nov 15, 2013 at 12:56 PM, Serg Melikyan smelik...@mirantis.com 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
Re: [openstack-dev] [Murano] [Neutron] [Fuel] Implementing Elastic Applications
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é the...@gmail.com wrote: On Fri, Nov 15, 2013 at 12:56 PM, Serg Melikyan smelik...@mirantis.com wrote: Murano has several applications which support scaling via load-balancing, this applications (Internet Information Services Web Farm, 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
