Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Dev

Re: [openstack-dev] Announcing proof-of-concept Load Balancing as a Service project

 

 

OpenStack dev RSS feed   Index | Next | Previous | View Threaded


ekirpichov at gmail

Jul 24, 2012, 8:37 PM

Post #1 of 8 (380 views)
Permalink
Re: [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> 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> 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/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.
>
> 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
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> 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
> 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
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


ekirpichov at gmail

Jul 25, 2012, 1:33 PM

Post #2 of 8 (362 views)
Permalink
Re: [openstack-dev] Announcing proof-of-concept Load Balancing as a Service project [In reply to]

Hi Dan,

On Tue, Jul 24, 2012 at 8:30 PM, Dan Wendlandt <dan [at] nicira> 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> 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?

>
> 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
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> 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
> 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
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


Youcef.Laribi at eu

Jul 25, 2012, 1:54 PM

Post #3 of 8 (363 views)
Permalink
Re: [openstack-dev] Announcing proof-of-concept Load Balancing as a Service project [In reply to]

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 [mailto:openstack-bounces+youcef.laribi=citrix.com [at] lists] On Behalf Of Eugene Kirpichov
Sent: Tuesday, July 24, 2012 8:38 PM
To: OpenStack Development Mailing List
Cc: Samuel Bercovici; openstack [at] lists; 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> 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> 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
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> 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
> 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
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

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


dan at nicira

Jul 25, 2012, 6:22 PM

Post #4 of 8 (365 views)
Permalink
Re: [openstack-dev] Announcing proof-of-concept Load Balancing as a Service project [In reply to]

On Wed, Jul 25, 2012 at 1:33 PM, Eugene Kirpichov <ekirpichov [at] gmail>wrote:

>
> >>>
> >>> 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
>

This is where naming gets tricky :) I would tend to think of LBaaS a
service as an independently loadable component within Quantum, which is to
say, your choice of a LBaaS back-end would be completely independent of
your choice of a "core" Quantum plugin. As a result, a provider could
choose to expose only the load-balancer API to tenants, if that is what
that operator wanted. I'm not sure if this is the same as what you
suggest. Either way, I think the right thing here is to focus on what
different deployment scenarios we see this being used in, then we can
figure out how tightly coupled it should be to the man quantum service.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~


dan at nicira

Jul 25, 2012, 6:30 PM

Post #5 of 8 (363 views)
Permalink
Re: [openstack-dev] Announcing proof-of-concept Load Balancing as a Service project [In reply to]

On Wed, Jul 25, 2012 at 1:54 PM, Youcef Laribi
<Youcef.Laribi [at] eu>wrote:

> 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.
>

Hi Youcef,

Yes, we recognize the efforts of the existing Atlas contributors and I
definitely want to make sure the atlas folks play a key role in figuring
out how LBaaS works in OpenStack moving forward. I get asked about LBaaS
fairly often, and I've always been a bit fuzzy on what to do about Atlas
for two reasons: 1) L4-L7 services are generally within the scope of what
Quantum expects to cover and 2) its java-based, and core projects like
Quantum are required to use python. I'm hoping the efforts of Eugene and
others is a first step in helping move existing Atlas functionality and
team members into a more permanent home as part of a core OpenStack
project. As I mentioned, my feeling is that LBaaS makes sense as a fairly
independent sub-component of the Quantum project, but ultimately, such
questions are determined by the PPB.

Dan


>
> Regards,
> Youcef
>
>
>
> -----Original Message-----
> From: openstack-bounces+youcef.laribi=citrix.com [at] lists[mailto:
> openstack-bounces+youcef.laribi=citrix.com [at] lists] On Behalf
> Of Eugene Kirpichov
> Sent: Tuesday, July 24, 2012 8:38 PM
> To: OpenStack Development Mailing List
> Cc: Samuel Bercovici; openstack [at] lists; 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> 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>
> 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
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to : openstack [at] lists
> >> 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
> > 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
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~


asalkeld at redhat

Jul 25, 2012, 7:52 PM

Post #6 of 8 (366 views)
Permalink
Re: [openstack-dev] Announcing proof-of-concept Load Balancing as a Service project [In reply to]

On 25/07/12 13:33 -0700, Eugene Kirpichov wrote:
>Hi Dan,
>
>On Tue, Jul 24, 2012 at 8:30 PM, Dan Wendlandt <dan [at] nicira> 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> 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?

Well I have only just add my simple loadbancer implementation. So don't
think there is a great need to rush it (unless a user is asking for it).

It would also need to wait until we can get statistics from the lb.

-Angus

>
>>
>> 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
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack [at] lists
>>> 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
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
>--
>Eugene Kirpichov
>http://www.linkedin.com/in/eugenekirpichov
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev [at] lists
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Youcef.Laribi at eu

Jul 25, 2012, 9:57 PM

Post #7 of 8 (374 views)
Permalink
Re: [openstack-dev] Announcing proof-of-concept Load Balancing as a Service project [In reply to]

Hi Dan,

Thanks. I also get a lot of questions about how Atlas would integrate with Quantum, so we should definitely do something about it :). I'm not aware though that it is a requirement for a core OpenStack project to be written in Python. I would have thought that, as long as the APIs of a service are well defined, it shouldn't matter what language it is written in, and there is an active developer community that is happy with developing and maintaining the project in that language. The only reference to requirements for an OpenStack project that I could find is this old blog post (step 6 talks about languages):

http://www.openstack.org/blog/2011/02/10-steps-to-initiating-an-openstack-cloud-service/

Is there an official position on this issue (requirements for an OS project) from the OpenStack PPB?

Youcef

From: Dan Wendlandt [mailto:dan [at] nicira]
Sent: Wednesday, July 25, 2012 6:31 PM
To: Youcef Laribi
Cc: Eugene Kirpichov; OpenStack Development Mailing List; John Gruber; Gilad Zlotkin; Avi Chesla; Samuel Bercovici; openstack [at] lists
Subject: Re: [Openstack] [openstack-dev] Announcing proof-of-concept Load Balancing as a Service project


On Wed, Jul 25, 2012 at 1:54 PM, Youcef Laribi <Youcef.Laribi [at] eu<mailto:Youcef.Laribi [at] eu>> wrote:
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.

Hi Youcef,

Yes, we recognize the efforts of the existing Atlas contributors and I definitely want to make sure the atlas folks play a key role in figuring out how LBaaS works in OpenStack moving forward. I get asked about LBaaS fairly often, and I've always been a bit fuzzy on what to do about Atlas for two reasons: 1) L4-L7 services are generally within the scope of what Quantum expects to cover and 2) its java-based, and core projects like Quantum are required to use python. I'm hoping the efforts of Eugene and others is a first step in helping move existing Atlas functionality and team members into a more permanent home as part of a core OpenStack project. As I mentioned, my feeling is that LBaaS makes sense as a fairly independent sub-component of the Quantum project, but ultimately, such questions are determined by the PPB.

Dan


Regards,
Youcef



-----Original Message-----
From: openstack-bounces+youcef.laribi=citrix.com [at] lists<mailto:citrix.com [at] lists> [mailto:openstack-bounces+youcef.laribi<mailto:openstack-bounces%2Byoucef.laribi>=citrix.com [at] lists<mailto:citrix.com [at] lists>] On Behalf Of Eugene Kirpichov
Sent: Tuesday, July 24, 2012 8:38 PM
To: OpenStack Development Mailing List
Cc: Samuel Bercovici; openstack [at] lists<mailto:openstack [at] lists>; 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<mailto:dan [at] nicira>> 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<mailto:asalkeld [at] redhat>> 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<mailto:openstack [at] lists>
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists<mailto:openstack [at] lists>
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com<http://www.nicira.com>
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev [at] lists<mailto:OpenStack-dev [at] lists>
> 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<mailto:openstack [at] lists>
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists<mailto:openstack [at] lists>
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com<http://www.nicira.com>
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~


dan at nicira

Jul 25, 2012, 10:23 PM

Post #8 of 8 (364 views)
Permalink
Re: [openstack-dev] Announcing proof-of-concept Load Balancing as a Service project [In reply to]

Here's the comment from Thierry, earlier today, from another thread on the
ML:

"This would be a question for the PPB (or its future replacement, called
the Technical Committee). The current stance is that all core projects
should by Python, unless an extremely compelling argument can be made in
favor of another language. It's far easier to build a development
community around a single language.

That said, it doesn't prevent ecosystem/related projects from being
built in whatever language you prefer."

So while its not impossible to have a CORE project be based on something
other than python code, the burden of proof why python won't work is quite
high.

Dan


On Wed, Jul 25, 2012 at 9:57 PM, Youcef Laribi
<Youcef.Laribi [at] eu>wrote:

> Hi Dan,****
>
> ** **
>
> Thanks. I also get a lot of questions about how Atlas would integrate with
> Quantum, so we should definitely do something about it J. I’m not aware
> though that it is a requirement for a core OpenStack project to be written
> in Python. I would have thought that, as long as the APIs of a service are
> well defined, it shouldn’t matter what language it is written in, and there
> is an active developer community that is happy with developing and
> maintaining the project in that language. The only reference to
> requirements for an OpenStack project that I could find is this old blog
> post (step 6 talks about languages):****
>
> ** **
>
>
> http://www.openstack.org/blog/2011/02/10-steps-to-initiating-an-openstack-cloud-service/
> ****
>
> ** **
>
> Is there an official position on this issue (requirements for an OS
> project) from the OpenStack PPB?****
>
> ** **
>
> Youcef****
>
> ** **
>
> *From:* Dan Wendlandt [mailto:dan [at] nicira]
> *Sent:* Wednesday, July 25, 2012 6:31 PM
> *To:* Youcef Laribi
> *Cc:* Eugene Kirpichov; OpenStack Development Mailing List; John Gruber;
> Gilad Zlotkin; Avi Chesla; Samuel Bercovici; openstack [at] lists
>
> *Subject:* Re: [Openstack] [openstack-dev] Announcing proof-of-concept
> Load Balancing as a Service project****
>
> ** **
>
> ** **
>
> On Wed, Jul 25, 2012 at 1:54 PM, Youcef Laribi <
> Youcef.Laribi [at] eu> wrote:****
>
> 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.****
>
> ** **
>
> Hi Youcef,****
>
> ** **
>
> Yes, we recognize the efforts of the existing Atlas contributors and I
> definitely want to make sure the atlas folks play a key role in figuring
> out how LBaaS works in OpenStack moving forward. I get asked about LBaaS
> fairly often, and I've always been a bit fuzzy on what to do about Atlas
> for two reasons: 1) L4-L7 services are generally within the scope of what
> Quantum expects to cover and 2) its java-based, and core projects like
> Quantum are required to use python. I'm hoping the efforts of Eugene and
> others is a first step in helping move existing Atlas functionality and
> team members into a more permanent home as part of a core OpenStack
> project. As I mentioned, my feeling is that LBaaS makes sense as a fairly
> independent sub-component of the Quantum project, but ultimately, such
> questions are determined by the PPB. ****
>
> ** **
>
> Dan****
>
> ****
>
>
> Regards,
> Youcef****
>
>
>
>
> -----Original Message-----
> From: openstack-bounces+youcef.laribi=citrix.com [at] lists[mailto:
> openstack-bounces+youcef.laribi=citrix.com [at] lists] On Behalf
> Of Eugene Kirpichov
> Sent: Tuesday, July 24, 2012 8:38 PM
> To: OpenStack Development Mailing List
> Cc: Samuel Bercovici; openstack [at] lists; 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> 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>
> 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
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to : openstack [at] lists
> >> 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
> > 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
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp****
>
>
>
> ****
>
> ** **
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt ****
>
> Nicira, Inc: www.nicira.com****
>
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~****
>
> ** **
>



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

OpenStack dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.