Open Stack

I  also want to point the community to the Atlas project which is still ongoing, and the code base is available on github at:

http://github.com/openstack-atlas/atlas-lb

This is based on the original code contributed by Rackspace more than a year ago, from their Cloud LoadBalancers Service and since then it has been evolved to support multiple adapters (or "drivers"). The next big thing for the project is integration with Quantum and Nova, so would love to see a common approach to this integration.

Regards,
Youcef 



-----Original Message-----
From: openstack-bounces+youcef.laribi=citrix.com at lists.launchpad.net [mailto:openstack-bounces+youcef.laribi=citrix.com at lists.launchpad.net] On Behalf Of Eugene Kirpichov
Sent: Tuesday, July 24, 2012 8:38 PM
To: OpenStack Development Mailing List
Cc: Samuel Bercovici; openstack at lists.launchpad.net; John Gruber; Gilad Zlotkin; Avi Chesla
Subject: Re: [Openstack] [openstack-dev] Announcing proof-of-concept Load Balancing as a Service project

Hi Dan,

Thanks for the feedback. I will answer in detail tomorrow; for now just providing a working link to the project overview:

http://goo.gl/LrRik

On Tue, Jul 24, 2012 at 8:30 PM, Dan Wendlandt <dan at nicira.com> 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 at redhat.com> 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.
>
>>>
>>>
>>> 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.
>
>>>
>>>
>>> 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/loadbalance
>> r.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/Develop
>> erGuide/US_MonitoringLoadBalancerWithCW.html
>>
>> Anyways, nice project.
>
>
> Integration with Heat would be great regardless of the above decisions.
>
> dan
>
>
>
>>
>>
>> Regards
>> Angus Salkeld
>>
>>
>>>
>>> All of the documents and code are not set in stone and we're writing 
>>> here specifically to ask for feedback and collaboration from the 
>>> community.
>>>
>>> We would like to start holding weekly IRC meetings at 
>>> #openstack-meeting; we propose 19:00 UTC on Thursdays (this time 
>>> seems free according to http://wiki.openstack.org/Meetings/ ), starting Aug 2.
>>>
>>> --
>>> Eugene Kirpichov
>>> http://www.linkedin.com/in/eugenekirpichov
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack at lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--
Eugene Kirpichov
http://www.linkedin.com/in/eugenekirpichov

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp