Hi Dan,
On Tue, Jul 24, 2012 at 8:30 PM, Dan Wendlandt <dan@xxxxxxxxxx> wrote:
Hi Eugene, Angus,
Adding openstack-dev (probably the more appropriate mailing list for
discussion a new openstack feature) and some folks from Radware and F5 who
had previously also contacted me about Quantum + Load-balancing as a
service. I'm probably leaving out some other people who have contacted me
about this as well, but hopefully they are on the ML and can speak up.
On Tue, Jul 24, 2012 at 7:51 PM, Angus Salkeld <asalkeld@xxxxxxxxxx> wrote:
On 24/07/12 18:33 -0700, Eugene Kirpichov wrote:
Hello community,
We at Mirantis have had a number of clients request functionality to
control various load balancer devices (software and hardware) via an
OpenStack API and horizon. So, in collaboration with Cisco OpenStack
team and a number of other community members, we’ve started
socializing the blueprints for an elastic load balancer API service.
At this point we’d like to share where we are and would very much
appreciate anyone participate and provide input.
Yes, I definitely think LB is one of the key items that we'll want to tackle
during Grizzly in terms of L4-L7 services.
Great to hear!
The current vision is to allow cloud tenants to request and
provision virtual load balancers on demand and allow cloud
administrators to manage a pool of available LB devices. Access is
provided under a unified interface to different kinds of load
balancers, both software and hardware. It means that API for tenants
is abstracted away from the actual API of underlying hardware or
software load balancers, and LBaaS effectively bridges this gap.
That's the openstack way, no arguments there :)
POC level support for Cisco ACE and HAproxy is currently implemented
in the form of plug-ins to LBaaS called “drivers”. We also started some
work on F5 drivers. Would appreciate hearing input on what other
drivers may be important at this point…nginx?
haproxy is the most common non-vendor solution I hear mentioned.
Another question we have is if this should be a standalone module or a
Quantum plugin…
Based on discussions during the PPB meeting about quantum becoming core,
there was a push for having a single network service and API, which would
tend to suggest it being a sub-component of Quantum that is independently
loadable. I also tend to think that its likely to be a common set of
developers working across all such networking functionality, so it wouldn't
seem like keeping different core-dev teams, repos, tarballs, docs, etc.
probably doesn't make sense. I think this is generally inline with the plan
of allowing Quantum to load additional portions of the API as needed for
additional services like LB, WAN-bridging, but this is probably a call for
the PPB in general.
So, if I'm understanding correctly, you're suggesting LBaaS to be
usable in 2 ways:
* Independently
* As a quantum plugin
Is this right?
In order not to reinvent the wheel, we decided to base our API on
Atlas-LB (http://wiki.openstack.org/Atlas-LB).
Seems like a good place to start.
Here are all the pointers:
* Project overview: http://goo.gl/vZdei
* Screencast: http://www.youtube.com/watch?v=NgAL-kfdbtE
* API draft: http://goo.gl/gFcWT
* Roadmap: http://goo.gl/EZAhf
* Github repo: https://github.com/Mirantis/openstack-lbaas
Will take a look.. I'm getting a permission error on the overview.
The code is written in Python and based on the OpenStack service
template. We’ll be happy to give a walkthrough over what we have to
anyone who may be interested in contributing (for example, creating a
driver to support a particular LB device).
I made a really simple loadbancer (using HAproxy) in Heat
(https://github.com/heat-api/heat/blob/master/heat/engine/loadbalancer.py)
to implement the AWS::ElasticLoadBalancing::LoadBalancer but
it would be nice to use a more complete loadbancer solution.
When I get a moment I'll see if I can integrate. One issue is
I need latency statistics to trigger autoscaling events.
See the statistics types here:
http://docs.amazonwebservices.com/ElasticLoadBalancing/latest/DeveloperGuide/US_MonitoringLoadBalancerWithCW.html
Anyways, nice project.
Integration with Heat would be great regardless of the above decisions.
Yes, sounds like a good idea indeed.
Is Heat mature enough and used enough to warrant doing this in the
near future, or is this better postponed until G at least? Angus?
