Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
Excerpts from Vishvananda Ishaya's message of 2014-01-21 12:16:12 -0800: > > On Jan 19, 2014, at 8:19 AM, Clint Byrum wrote: > > > Excerpts from Thomas Herve's message of 2014-01-19 01:52:56 -0800: > >> > >>> Hi, > >>> > >>> I haven’t read through those (need to go spend time with family so > >>> replying > >>> quickly) but given the dates the planning phases for Quantum/Neutron LBaaS > >>> and Libra LBaaS were at the same time. > >>> > >>> There was an internal evaluation of the current LBaaS solutions done at > >>> the > >>> time and it was believed by the people evaluating that Atlas was a good > >>> place to start. I came in just as that evaluation had finished (late > >>> August > >>> 2012) and the decision was pretty much made. In retrospect I may have > >>> personally gone the Mirantis LBaaS as a starting point. But either way > >>> there > >>> were some good starting places. > >>> > >>> Libra was initially a few trees so history is hard to track, but we had > >>> something in production by December that year. > >>> > >>> In response to Alex, the Libra team in HP is growing (it is currently > >>> still > >>> pretty small) and that should help us have more engineers to work with the > >>> Neutron team. The current goal is to get 5.x out of the door which adds > >>> things like metering/billing support and then planning how we can > >>> integrate > >>> well with Neutron. I believe the Libra team have a few diagrams flying > >>> around on a mutually beneficial way of doing that. > >> > >> Hi Andrew, > >> > >> Thanks for the all the responses. I certainly didn't want to throw the > >> blame at one of the team, but I think we should try to converge. In > >> particular Neutron LBaaS would benefit greatly from having a big > >> deployment like HP. I hope the 2 teams can find a way to collaborate. > >> > >> There are benefits to have a different endpoint like Libra proposes, > >> although now that LBaaS is integrated in Neutron it's going to be > >> difficult to change. There is a tension in OpenStack currently between > >> keeping the projects lean (by having small, independent code bases) and > >> making deployments easy (by not having to deploy dozens of projects). I > >> feel we haven't found a great answer yet. > >> > > > > I actually don't think having less services makes deployment easier. > > If you're not using automation, sure, its harder to install a bunch of > > things, but I don't think OpenStack should waste any time for people > > stuck in the 1990's. If you have automation, LBaaS as its own service > > is identical to LBaaS as a neutron agent. > > I’m sorry but this comment flatly ignores a huge amount of work. Let me point > out a few of the costs of adding a new service: > > * Gating costs Gating on an agent with a private RPC API inside Neutron doesn't seem all that different to gating a public API service and an agent with a private RPC API outside Neutron. > * Packaging costs > * Automation script costs > > These are non-trivial costs, and many of them are paid multiple times. A lot > of deployers maintain their own packages, and automation scripts need to be > written in many different forms (chef, pupput, salt, custom). Said costs are nearly identical IMO for the same reason. You're either adding a neutron-lbaas-agent package, or a libra package. Same for automation scripts. It is always "deploying something different". To be clear though, I like LBaaS in Neutron. I just don't agree that more services makes things cost more in the long run. SOA wants an API for anything that can operate and scale without the other pieces. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
On Jan 19, 2014, at 8:19 AM, Clint Byrum wrote: > Excerpts from Thomas Herve's message of 2014-01-19 01:52:56 -0800: >> >>> Hi, >>> >>> I haven’t read through those (need to go spend time with family so replying >>> quickly) but given the dates the planning phases for Quantum/Neutron LBaaS >>> and Libra LBaaS were at the same time. >>> >>> There was an internal evaluation of the current LBaaS solutions done at the >>> time and it was believed by the people evaluating that Atlas was a good >>> place to start. I came in just as that evaluation had finished (late August >>> 2012) and the decision was pretty much made. In retrospect I may have >>> personally gone the Mirantis LBaaS as a starting point. But either way there >>> were some good starting places. >>> >>> Libra was initially a few trees so history is hard to track, but we had >>> something in production by December that year. >>> >>> In response to Alex, the Libra team in HP is growing (it is currently still >>> pretty small) and that should help us have more engineers to work with the >>> Neutron team. The current goal is to get 5.x out of the door which adds >>> things like metering/billing support and then planning how we can integrate >>> well with Neutron. I believe the Libra team have a few diagrams flying >>> around on a mutually beneficial way of doing that. >> >> Hi Andrew, >> >> Thanks for the all the responses. I certainly didn't want to throw the blame >> at one of the team, but I think we should try to converge. In particular >> Neutron LBaaS would benefit greatly from having a big deployment like HP. I >> hope the 2 teams can find a way to collaborate. >> >> There are benefits to have a different endpoint like Libra proposes, >> although now that LBaaS is integrated in Neutron it's going to be difficult >> to change. There is a tension in OpenStack currently between keeping the >> projects lean (by having small, independent code bases) and making >> deployments easy (by not having to deploy dozens of projects). I feel we >> haven't found a great answer yet. >> > > I actually don't think having less services makes deployment easier. > If you're not using automation, sure, its harder to install a bunch of > things, but I don't think OpenStack should waste any time for people > stuck in the 1990's. If you have automation, LBaaS as its own service > is identical to LBaaS as a neutron agent. I’m sorry but this comment flatly ignores a huge amount of work. Let me point out a few of the costs of adding a new service: * Gating costs * Packaging costs * Automation script costs These are non-trivial costs, and many of them are paid multiple times. A lot of deployers maintain their own packages, and automation scripts need to be written in many different forms (chef, pupput, salt, custom). Vish > > In this case I think another interesting aspect is that LBaaS being built > in to Neutron means that it can take advantage of where Neutron sits > in the networking stack. Being setup already as the default gateway for > nodes allows for things like LVS-DR where the packets are not rewritten, > they're just sent to the appropriate port's MAC. > > Also another thing to consider is that by growing a service as much as > is possible without forcing people to deploy a service they don't want, > you reduce entropy in both development (less duplication of effort) > and in production (less moving parts). > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
On 19 Jan 2014, at 09:52, Thomas Herve wrote: >> >> Hi, >> >> I haven’t read through those (need to go spend time with family so replying >> quickly) but given the dates the planning phases for Quantum/Neutron LBaaS >> and Libra LBaaS were at the same time. >> >> There was an internal evaluation of the current LBaaS solutions done at the >> time and it was believed by the people evaluating that Atlas was a good >> place to start. I came in just as that evaluation had finished (late August >> 2012) and the decision was pretty much made. In retrospect I may have >> personally gone the Mirantis LBaaS as a starting point. But either way there >> were some good starting places. >> >> Libra was initially a few trees so history is hard to track, but we had >> something in production by December that year. >> >> In response to Alex, the Libra team in HP is growing (it is currently still >> pretty small) and that should help us have more engineers to work with the >> Neutron team. The current goal is to get 5.x out of the door which adds >> things like metering/billing support and then planning how we can integrate >> well with Neutron. I believe the Libra team have a few diagrams flying >> around on a mutually beneficial way of doing that. > > Hi Andrew, > > Thanks for the all the responses. I certainly didn't want to throw the blame > at one of the team, but I think we should try to converge. In particular > Neutron LBaaS would benefit greatly from having a big deployment like HP. I > hope the 2 teams can find a way to collaborate. > > There are benefits to have a different endpoint like Libra proposes, although > now that LBaaS is integrated in Neutron it's going to be difficult to change. > There is a tension in OpenStack currently between keeping the projects lean > (by having small, independent code bases) and making deployments easy (by not > having to deploy dozens of projects). I feel we haven't found a great answer > yet. The good thing about both projects is they are quite modular and both have forms of plugins. It is definitely something that is possible. Sure it will be an Engineering challenge, but I think it will be a fun one to solve. :)___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
On 18 Jan 2014, at 19:02, Jay Pipes wrote: > On Sat, 2014-01-18 at 09:06 +, Andrew Hutchings wrote: >> >> I’m not sure what is public and what isn’t so I won’t name names. >> They are currently talking to us about the best ways of working with >> us. Both companies want to use Libra in different and interesting >> ways. They are not currently deploying it but are both playing with >> it. It is early days, they both approached us just before the >> Christmas break. > > Did these companies say they had looked at Neutron LBaaS and found its > design or implementation lacking in some way? I am not party to the conversations since I handed off my roll before the conversations really got going. So, I can’t answer unfortunately. >> We know that working with the wider community with Libra has not been >> our strong point. It is something I want the team to rectify and they >> are showing signs of making that happen. People that are interested >> in Libra are welcome to hang out in the #stackforge-libra IRC channel >> to talk to us. > > Cutting to the chase... have there been any discussions about the > long-term direction of Libra and Neutron LBaaS. I see little point > having two OpenStack endpoints that implement the same basic load > balancing functionality. > > Is the main problem in aligning Libra and Neutron the fact that Libra is > a wholly-separate endpoint/project and Neutron LBaaS is part of the > Neutron project? There are at least 3 different ways I know of that the two can be integrated at various levels based on an investigation into this a year ago. I am not aware of talks starting yet between the Libra and Neutron teams but I would hope both sides are keen to make this happen. Both have a lot to give to make software load balancing a really good thing.___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
Excerpts from Thomas Herve's message of 2014-01-19 01:52:56 -0800: > > > Hi, > > > > I haven’t read through those (need to go spend time with family so replying > > quickly) but given the dates the planning phases for Quantum/Neutron LBaaS > > and Libra LBaaS were at the same time. > > > > There was an internal evaluation of the current LBaaS solutions done at the > > time and it was believed by the people evaluating that Atlas was a good > > place to start. I came in just as that evaluation had finished (late August > > 2012) and the decision was pretty much made. In retrospect I may have > > personally gone the Mirantis LBaaS as a starting point. But either way there > > were some good starting places. > > > > Libra was initially a few trees so history is hard to track, but we had > > something in production by December that year. > > > > In response to Alex, the Libra team in HP is growing (it is currently still > > pretty small) and that should help us have more engineers to work with the > > Neutron team. The current goal is to get 5.x out of the door which adds > > things like metering/billing support and then planning how we can integrate > > well with Neutron. I believe the Libra team have a few diagrams flying > > around on a mutually beneficial way of doing that. > > Hi Andrew, > > Thanks for the all the responses. I certainly didn't want to throw the blame > at one of the team, but I think we should try to converge. In particular > Neutron LBaaS would benefit greatly from having a big deployment like HP. I > hope the 2 teams can find a way to collaborate. > > There are benefits to have a different endpoint like Libra proposes, although > now that LBaaS is integrated in Neutron it's going to be difficult to change. > There is a tension in OpenStack currently between keeping the projects lean > (by having small, independent code bases) and making deployments easy (by not > having to deploy dozens of projects). I feel we haven't found a great answer > yet. > I actually don't think having less services makes deployment easier. If you're not using automation, sure, its harder to install a bunch of things, but I don't think OpenStack should waste any time for people stuck in the 1990's. If you have automation, LBaaS as its own service is identical to LBaaS as a neutron agent. In this case I think another interesting aspect is that LBaaS being built in to Neutron means that it can take advantage of where Neutron sits in the networking stack. Being setup already as the default gateway for nodes allows for things like LVS-DR where the packets are not rewritten, they're just sent to the appropriate port's MAC. Also another thing to consider is that by growing a service as much as is possible without forcing people to deploy a service they don't want, you reduce entropy in both development (less duplication of effort) and in production (less moving parts). ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
> Hi, > > I haven’t read through those (need to go spend time with family so replying > quickly) but given the dates the planning phases for Quantum/Neutron LBaaS > and Libra LBaaS were at the same time. > > There was an internal evaluation of the current LBaaS solutions done at the > time and it was believed by the people evaluating that Atlas was a good > place to start. I came in just as that evaluation had finished (late August > 2012) and the decision was pretty much made. In retrospect I may have > personally gone the Mirantis LBaaS as a starting point. But either way there > were some good starting places. > > Libra was initially a few trees so history is hard to track, but we had > something in production by December that year. > > In response to Alex, the Libra team in HP is growing (it is currently still > pretty small) and that should help us have more engineers to work with the > Neutron team. The current goal is to get 5.x out of the door which adds > things like metering/billing support and then planning how we can integrate > well with Neutron. I believe the Libra team have a few diagrams flying > around on a mutually beneficial way of doing that. Hi Andrew, Thanks for the all the responses. I certainly didn't want to throw the blame at one of the team, but I think we should try to converge. In particular Neutron LBaaS would benefit greatly from having a big deployment like HP. I hope the 2 teams can find a way to collaborate. There are benefits to have a different endpoint like Libra proposes, although now that LBaaS is integrated in Neutron it's going to be difficult to change. There is a tension in OpenStack currently between keeping the projects lean (by having small, independent code bases) and making deployments easy (by not having to deploy dozens of projects). I feel we haven't found a great answer yet. -- Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
Excerpts from Jay Pipes's message of 2014-01-18 11:02:12 -0800: > Cutting to the chase... have there been any discussions about the > long-term direction of Libra and Neutron LBaaS. I see little point > having two OpenStack endpoints that implement the same basic load > balancing functionality. > > Is the main problem in aligning Libra and Neutron the fact that Libra is > a wholly-separate endpoint/project and Neutron LBaaS is part of the > Neutron project? In the past I've been told the only reason Libra/Atlas persist is that Neutron wasn't ready. To me that means 'lets go make Neutron better'. But then, I haven't been given any crazy short lead times for rolling out LBaaS. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
On Fri, 2014-01-17 at 13:12 -0800, Alex Freedland wrote: > Andrew, Jay and all, > > Thank you for bringing this topic up. Incidentally, just a month ago > at OpenStack Israel I spoke to Monty and other HP folks about getting > the Libra initiatives integrated into LBaaS. I am happy that this > discussion is now happening on the mailing list. > > I remember the history of how this got started. Mirantis was working > with a number of customers (GAP, PayPal, and a few others) who were > asking for LBaaS feature. At that time, Atlas was the default choice > in the community, but its Java-based implementation did not agree with > the rest of OpenStack. > > There was no Libra anywhere in the OpenStack sandbox, so we have > proposed a set of blueprints and Eugene Nikonorov and the team started > moving ahead with the implementation. Even before the code was > accepted into Quantum, a number of customers started to use it and a > number of vendors (F5, Radware, etc.) joined the community to add > there own plugins. > > Consequently, the decision was made to add LBaaS to Quantum (aka > Neutron). Thanks for the above history, Alex, appreciated. > We would love to see the Libra developers join the Neutron team and > collaborate on the ways to bring the two initiatives together. Agreed. However, I'm afraid progress towards alignment won't happen until there's a concerted effort between the two groups to resolve any architectural differences and a create set of blueprints that outline the work required to bring the best of both worlds together. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
On Sat, 2014-01-18 at 09:06 +, Andrew Hutchings wrote: > > On 17 Jan 2014, at 19:53, Jay Pipes wrote: > > > On Fri, 2014-01-17 at 17:03 +, Andrew Hutchings wrote: > > > On 17 Jan 2014, at 16:10, Jay Pipes wrote: > > > > > > > On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote: > > > > > Hi all, > > > > > > > > > > I've been looking at Neutron default LBaaS provider using > > > > > haproxy, and while it's working nicely, it seems to have > > > > > several shortcomings in terms of scalability and high > > > > > availability. The Libra project seems to offer a more robust > > > > > alternative, at least for scaling. The haproxy implementation > > > > > in Neutron seems to continue to evolve (like with > > > > > https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy), but > > > > > I'm wondering why we can't leverage Libra. The APIs are a bit > > > > > different, but the goals look very similar, and there is a waste of > > > > > effort with 2 different implementations. Maybe we could see a Libra > > > > > driver for Neutron LBaaS for example? > > > > > > > > Yep, it's a completely duplicative and wasteful effort. > > > > > > > > It would be great for Libra developers to contribute to Neutron > > > > LBaaS. > > > > > > Hi Jay and Thomas, > > > > > > I am the outgoing technical lead of Libra for HP. But will reply > > > whilst the new technical lead (Marc Pilon) gets subscribed to > > > this. > > > > :( I had no idea, Andrew! > > Not a big deal, I have some cool stuff open source stuff in HP I’m > moving on to which I’m excited about and can help Openstack in other > ways. You should hear about that in a few months time. Cool. I look forward to that -- around summit time, eh? > > So, please don't take this the wrong way... but does anyone other > > than HP run Libra? Likewise, does anyone other than Rackspace run > > Atlas? > > No one else runs it in production that I know about, but there are > several trying it out and appearing to want to contribute. OK. > I find it a little difficult to comprehend why, if Libra preceded work > > on Neutron LBaaS, that it wasn't used as the basis of Neutron's > > LBaaS work. I can understand this for Atlas, since it's Java, but > > Libra is Python code... so it's even more confusing to me. > > > > Granted, I don't know the history of Neutron LBaaS, but it just > > seems to be that this particular area (LBaaS) has such blatantly > > overlapping codebases with separate contributor teams. Just baffling > > really. > > > > Any background or history you can give me (however opinionated!) > > would be very much appreciated :) > > I don’t know if we pre-dated the planning phase, judging by a later > email on this thread our planning phases were at the same time. I > wasn’t a big part of the planning phase so it is difficult to comment > there. But we had something we could use before we were in a place > where we could even try out Neutron. Also to start with our API was > Java based (a Python replacement came later). K, good to understand. > > > After the 5.x release of Libra has been stabilised we will be > > > working towards integration with Neutron. It is a very important > > > thing on our roadmap and we are already working with 2 other large > > > companies in Openstack to figure that piece out. > > > > Which large OpenStack companies? Are these companies currently > > deploying Libra? > > I’m not sure what is public and what isn’t so I won’t name names. > They are currently talking to us about the best ways of working with > us. Both companies want to use Libra in different and interesting > ways. They are not currently deploying it but are both playing with > it. It is early days, they both approached us just before the > Christmas break. Did these companies say they had looked at Neutron LBaaS and found its design or implementation lacking in some way? > We know that working with the wider community with Libra has not been > our strong point. It is something I want the team to rectify and they > are showing signs of making that happen. People that are interested > in Libra are welcome to hang out in the #stackforge-libra IRC channel > to talk to us. Cutting to the chase... have there been any discussions about the long-term direction of Libra and Neutron LBaaS. I see little point having two OpenStack endpoints that implement the same basic load balancing functionality. Is the main problem in aligning Libra and Neutron the fact that Libra is a wholly-separate endpoint/project and Neutron LBaaS is part of the Neutron project? Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
Hi, I haven’t read through those (need to go spend time with family so replying quickly) but given the dates the planning phases for Quantum/Neutron LBaaS and Libra LBaaS were at the same time. There was an internal evaluation of the current LBaaS solutions done at the time and it was believed by the people evaluating that Atlas was a good place to start. I came in just as that evaluation had finished (late August 2012) and the decision was pretty much made. In retrospect I may have personally gone the Mirantis LBaaS as a starting point. But either way there were some good starting places. Libra was initially a few trees so history is hard to track, but we had something in production by December that year. In response to Alex, the Libra team in HP is growing (it is currently still pretty small) and that should help us have more engineers to work with the Neutron team. The current goal is to get 5.x out of the door which adds things like metering/billing support and then planning how we can integrate well with Neutron. I believe the Libra team have a few diagrams flying around on a mutually beneficial way of doing that. Kind Regards Andrew On 17 Jan 2014, at 23:00, Georgy Okrokvertskhov wrote: > Hi, > > > Here are e-mail threads which keeps the history of LBaaS decisions: > LBaaS IIRC meeting minutes: > http://lists.openstack.org/pipermail/openstack-dev/2012-August/000390.html > LBaaS e-mail discussion: > http://lists.openstack.org/pipermail/openstack-dev/2012-August/000785.html > > As you see there was a comparison of existed at that moment LBaaS solutions: > * Atlas-LB > * Mirantis LBaaS > * eBay LBaaS > > Git history shows that the initial commit for Libra was on September 10th > 2012. This commit contains few files without any LBaaS functionality. > > I think it is quite fair to say that OpenStack community did a great job on > carefully evaluating existing and working LBaaS projects and made a decision > to add some of existing functionality to Quantum. > > Thanks > Georgy > > > On Fri, Jan 17, 2014 at 1:12 PM, Alex Freedland > wrote: > Andrew, Jay and all, > > Thank you for bringing this topic up. Incidentally, just a month ago at > OpenStack Israel I spoke to Monty and other HP folks about getting the Libra > initiatives integrated into LBaaS. I am happy that this discussion is now > happening on the mailing list. > > I remember the history of how this got started. Mirantis was working with a > number of customers (GAP, PayPal, and a few others) who were asking for LBaaS > feature. At that time, Atlas was the default choice in the community, but its > Java-based implementation did not agree with the rest of OpenStack. > > There was no Libra anywhere in the OpenStack sandbox, so we have proposed a > set of blueprints and Eugene Nikonorov and the team started moving ahead with > the implementation. Even before the code was accepted into Quantum, a number > of customers started to use it and a number of vendors (F5, Radware, etc.) > joined the community to add there own plugins. > > Consequently, the decision was made to add LBaaS to Quantum (aka Neutron). > > We would love to see the Libra developers join the Neutron team and > collaborate on the ways to bring the two initiatives together. > > > Alex Freedland > Community Team > Mirantis, Inc. > > > > > On Fri, Jan 17, 2014 at 11:53 AM, Jay Pipes wrote: > On Fri, 2014-01-17 at 17:03 +, Andrew Hutchings wrote: > > On 17 Jan 2014, at 16:10, Jay Pipes wrote: > > > > > On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote: > > >> Hi all, > > >> > > >> I've been looking at Neutron default LBaaS provider using haproxy, and > > >> while it's working nicely, it seems to have several shortcomings in > > >> terms of scalability and high availability. The Libra project seems to > > >> offer a more robust alternative, at least for scaling. The haproxy > > >> implementation in Neutron seems to continue to evolve (like with > > >> https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy), but > > >> I'm wondering why we can't leverage Libra. The APIs are a bit different, > > >> but the goals look very similar, and there is a waste of effort with 2 > > >> different implementations. Maybe we could see a Libra driver for Neutron > > >> LBaaS for example? > > > > > > Yep, it's a completely duplicative and wasteful effort. > > > > > > It would be great for Libra developers to contribute to Neutron LBaaS. > > > > Hi Jay and Thomas, > > > > I am the outgoing technical lead of Libra for HP. But will reply whilst > > the new technical lead (Marc Pilon) gets subscribed to this. > > :( I had no idea, Andrew! > > > I would go as far as duplicative or wasteful. Libra existed before Neutron > > LBaaS and is originally based on the Atlas API specifications. Neutron > > LBaaS has started duplicating some of our features recently which we find > > quite flattering. > > I presume yo
Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
On 17 Jan 2014, at 19:53, Jay Pipes wrote: > On Fri, 2014-01-17 at 17:03 +, Andrew Hutchings wrote: >> On 17 Jan 2014, at 16:10, Jay Pipes wrote: >> >>> On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote: Hi all, I've been looking at Neutron default LBaaS provider using haproxy, and while it's working nicely, it seems to have several shortcomings in terms of scalability and high availability. The Libra project seems to offer a more robust alternative, at least for scaling. The haproxy implementation in Neutron seems to continue to evolve (like with https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy), but I'm wondering why we can't leverage Libra. The APIs are a bit different, but the goals look very similar, and there is a waste of effort with 2 different implementations. Maybe we could see a Libra driver for Neutron LBaaS for example? >>> >>> Yep, it's a completely duplicative and wasteful effort. >>> >>> It would be great for Libra developers to contribute to Neutron LBaaS. >> >> Hi Jay and Thomas, >> >> I am the outgoing technical lead of Libra for HP. But will reply whilst the >> new technical lead (Marc Pilon) gets subscribed to this. > > :( I had no idea, Andrew! Not a big deal, I have some cool stuff open source stuff in HP I’m moving on to which I’m excited about and can help Openstack in other ways. You should hear about that in a few months time. >> I would go as far as duplicative or wasteful. Libra existed before Neutron >> LBaaS and is originally based on the Atlas API specifications. Neutron >> LBaaS has started duplicating some of our features recently which we find >> quite flattering. > > I presume you meant you would *not* go as far as duplicative or > wasteful :) Yes, sorry, got back from Seattle a couple of days ago and am extremely jet lagged :) > So, please don't take this the wrong way... but does anyone other than > HP run Libra? Likewise, does anyone other than Rackspace run Atlas? No one else runs it in production that I know about, but there are several trying it out and appearing to want to contribute. > I find it a little difficult to comprehend why, if Libra preceded work > on Neutron LBaaS, that it wasn't used as the basis of Neutron's LBaaS > work. I can understand this for Atlas, since it's Java, but Libra is > Python code... so it's even more confusing to me. > > Granted, I don't know the history of Neutron LBaaS, but it just seems to > be that this particular area (LBaaS) has such blatantly overlapping > codebases with separate contributor teams. Just baffling really. > > Any background or history you can give me (however opinionated!) would > be very much appreciated :) I don’t know if we pre-dated the planning phase, judging by a later email on this thread our planning phases were at the same time. I wasn’t a big part of the planning phase so it is difficult to comment there. But we had something we could use before we were in a place where we could even try out Neutron. Also to start with our API was Java based (a Python replacement came later). >> After the 5.x release of Libra has been stabilised we will be working >> towards integration with Neutron. It is a very important thing on our >> roadmap and we are already working with 2 other large companies in Openstack >> to figure that piece out. > > Which large OpenStack companies? Are these companies currently deploying > Libra? I’m not sure what is public and what isn’t so I won’t name names. They are currently talking to us about the best ways of working with us. Both companies want to use Libra in different and interesting ways. They are not currently deploying it but are both playing with it. It is early days, they both approached us just before the Christmas break. We know that working with the wider community with Libra has not been our strong point. It is something I want the team to rectify and they are showing signs of making that happen. People that are interested in Libra are welcome to hang out in the #stackforge-libra IRC channel to talk to us.___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
Hi, Here are e-mail threads which keeps the history of LBaaS decisions: LBaaS IIRC meeting minutes: http://lists.openstack.org/pipermail/openstack-dev/2012-August/000390.html LBaaS e-mail discussion: http://lists.openstack.org/pipermail/openstack-dev/2012-August/000785.html As you see there was a comparison of existed at that moment LBaaS solutions: * Atlas-LB * Mirantis LBaaS * eBay LBaaS Git history shows that the initial commit for Libra was on September 10th 2012. This commit contains few files without any LBaaS functionality. I think it is quite fair to say that OpenStack community did a great job on carefully evaluating existing and working LBaaS projects and made a decision to add some of existing functionality to Quantum. Thanks Georgy On Fri, Jan 17, 2014 at 1:12 PM, Alex Freedland wrote: > Andrew, Jay and all, > > Thank you for bringing this topic up. Incidentally, just a month ago at > OpenStack Israel I spoke to Monty and other HP folks about getting the > Libra initiatives integrated into LBaaS. I am happy that this discussion > is now happening on the mailing list. > > I remember the history of how this got started. Mirantis was working with > a number of customers (GAP, PayPal, and a few others) who were asking for > LBaaS feature. At that time, Atlas was the default choice in the community, > but its Java-based implementation did not agree with the rest of OpenStack. > > There was no Libra anywhere in the OpenStack sandbox, so we have proposed > a set of blueprints and Eugene Nikonorov and the team started moving ahead > with the implementation. Even before the code was accepted into Quantum, a > number of customers started to use it and a number of vendors (F5, Radware, > etc.) joined the community to add there own plugins. > > Consequently, the decision was made to add LBaaS to Quantum (aka Neutron). > > We would love to see the Libra developers join the Neutron team and > collaborate on the ways to bring the two initiatives together. > > > Alex Freedland > Community Team > Mirantis, Inc. > > > > > On Fri, Jan 17, 2014 at 11:53 AM, Jay Pipes wrote: > >> On Fri, 2014-01-17 at 17:03 +, Andrew Hutchings wrote: >> > On 17 Jan 2014, at 16:10, Jay Pipes wrote: >> > >> > > On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote: >> > >> Hi all, >> > >> >> > >> I've been looking at Neutron default LBaaS provider using haproxy, >> and while it's working nicely, it seems to have several shortcomings in >> terms of scalability and high availability. The Libra project seems to >> offer a more robust alternative, at least for scaling. The haproxy >> implementation in Neutron seems to continue to evolve (like with >> https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy), but >> I'm wondering why we can't leverage Libra. The APIs are a bit different, >> but the goals look very similar, and there is a waste of effort with 2 >> different implementations. Maybe we could see a Libra driver for Neutron >> LBaaS for example? >> > > >> > > Yep, it's a completely duplicative and wasteful effort. >> > > >> > > It would be great for Libra developers to contribute to Neutron LBaaS. >> > >> > Hi Jay and Thomas, >> > >> > I am the outgoing technical lead of Libra for HP. But will reply >> whilst the new technical lead (Marc Pilon) gets subscribed to this. >> >> :( I had no idea, Andrew! >> >> > I would go as far as duplicative or wasteful. Libra existed before >> Neutron LBaaS and is originally based on the Atlas API specifications. >> Neutron LBaaS has started duplicating some of our features recently which >> we find quite flattering. >> >> I presume you meant you would *not* go as far as duplicative or >> wasteful :) >> >> So, please don't take this the wrong way... but does anyone other than >> HP run Libra? Likewise, does anyone other than Rackspace run Atlas? >> >> I find it a little difficult to comprehend why, if Libra preceded work >> on Neutron LBaaS, that it wasn't used as the basis of Neutron's LBaaS >> work. I can understand this for Atlas, since it's Java, but Libra is >> Python code... so it's even more confusing to me. >> >> Granted, I don't know the history of Neutron LBaaS, but it just seems to >> be that this particular area (LBaaS) has such blatantly overlapping >> codebases with separate contributor teams. Just baffling really. >> >> Any background or history you can give me (however opinionated!) would >> be very much appreciated :) >> >> > After the 5.x release of Libra has been stabilised we will be working >> towards integration with Neutron. It is a very important thing on our >> roadmap and we are already working with 2 other large companies in >> Openstack to figure that piece out. >> >> Which large OpenStack companies? Are these companies currently deploying >> Libra? >> >> Thanks, >> -jay >> >> > If anyone else wants to get involved or just wants to play with Libra >> I’m sure the HP team would be happy to hear about it and help where they >> can. >> > >>
Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
Andrew, Jay and all, Thank you for bringing this topic up. Incidentally, just a month ago at OpenStack Israel I spoke to Monty and other HP folks about getting the Libra initiatives integrated into LBaaS. I am happy that this discussion is now happening on the mailing list. I remember the history of how this got started. Mirantis was working with a number of customers (GAP, PayPal, and a few others) who were asking for LBaaS feature. At that time, Atlas was the default choice in the community, but its Java-based implementation did not agree with the rest of OpenStack. There was no Libra anywhere in the OpenStack sandbox, so we have proposed a set of blueprints and Eugene Nikonorov and the team started moving ahead with the implementation. Even before the code was accepted into Quantum, a number of customers started to use it and a number of vendors (F5, Radware, etc.) joined the community to add there own plugins. Consequently, the decision was made to add LBaaS to Quantum (aka Neutron). We would love to see the Libra developers join the Neutron team and collaborate on the ways to bring the two initiatives together. Alex Freedland Community Team Mirantis, Inc. On Fri, Jan 17, 2014 at 11:53 AM, Jay Pipes wrote: > On Fri, 2014-01-17 at 17:03 +, Andrew Hutchings wrote: > > On 17 Jan 2014, at 16:10, Jay Pipes wrote: > > > > > On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote: > > >> Hi all, > > >> > > >> I've been looking at Neutron default LBaaS provider using haproxy, > and while it's working nicely, it seems to have several shortcomings in > terms of scalability and high availability. The Libra project seems to > offer a more robust alternative, at least for scaling. The haproxy > implementation in Neutron seems to continue to evolve (like with > https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy), but I'm > wondering why we can't leverage Libra. The APIs are a bit different, but > the goals look very similar, and there is a waste of effort with 2 > different implementations. Maybe we could see a Libra driver for Neutron > LBaaS for example? > > > > > > Yep, it's a completely duplicative and wasteful effort. > > > > > > It would be great for Libra developers to contribute to Neutron LBaaS. > > > > Hi Jay and Thomas, > > > > I am the outgoing technical lead of Libra for HP. But will reply whilst > the new technical lead (Marc Pilon) gets subscribed to this. > > :( I had no idea, Andrew! > > > I would go as far as duplicative or wasteful. Libra existed before > Neutron LBaaS and is originally based on the Atlas API specifications. > Neutron LBaaS has started duplicating some of our features recently which > we find quite flattering. > > I presume you meant you would *not* go as far as duplicative or > wasteful :) > > So, please don't take this the wrong way... but does anyone other than > HP run Libra? Likewise, does anyone other than Rackspace run Atlas? > > I find it a little difficult to comprehend why, if Libra preceded work > on Neutron LBaaS, that it wasn't used as the basis of Neutron's LBaaS > work. I can understand this for Atlas, since it's Java, but Libra is > Python code... so it's even more confusing to me. > > Granted, I don't know the history of Neutron LBaaS, but it just seems to > be that this particular area (LBaaS) has such blatantly overlapping > codebases with separate contributor teams. Just baffling really. > > Any background or history you can give me (however opinionated!) would > be very much appreciated :) > > > After the 5.x release of Libra has been stabilised we will be working > towards integration with Neutron. It is a very important thing on our > roadmap and we are already working with 2 other large companies in > Openstack to figure that piece out. > > Which large OpenStack companies? Are these companies currently deploying > Libra? > > Thanks, > -jay > > > If anyone else wants to get involved or just wants to play with Libra > I’m sure the HP team would be happy to hear about it and help where they > can. > > > > Hope this helps > > > > Kind Regards > > Andrew > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
On Fri, 2014-01-17 at 17:03 +, Andrew Hutchings wrote: > On 17 Jan 2014, at 16:10, Jay Pipes wrote: > > > On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote: > >> Hi all, > >> > >> I've been looking at Neutron default LBaaS provider using haproxy, and > >> while it's working nicely, it seems to have several shortcomings in terms > >> of scalability and high availability. The Libra project seems to offer a > >> more robust alternative, at least for scaling. The haproxy implementation > >> in Neutron seems to continue to evolve (like with > >> https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy), but I'm > >> wondering why we can't leverage Libra. The APIs are a bit different, but > >> the goals look very similar, and there is a waste of effort with 2 > >> different implementations. Maybe we could see a Libra driver for Neutron > >> LBaaS for example? > > > > Yep, it's a completely duplicative and wasteful effort. > > > > It would be great for Libra developers to contribute to Neutron LBaaS. > > Hi Jay and Thomas, > > I am the outgoing technical lead of Libra for HP. But will reply whilst the > new technical lead (Marc Pilon) gets subscribed to this. :( I had no idea, Andrew! > I would go as far as duplicative or wasteful. Libra existed before Neutron > LBaaS and is originally based on the Atlas API specifications. Neutron LBaaS > has started duplicating some of our features recently which we find quite > flattering. I presume you meant you would *not* go as far as duplicative or wasteful :) So, please don't take this the wrong way... but does anyone other than HP run Libra? Likewise, does anyone other than Rackspace run Atlas? I find it a little difficult to comprehend why, if Libra preceded work on Neutron LBaaS, that it wasn't used as the basis of Neutron's LBaaS work. I can understand this for Atlas, since it's Java, but Libra is Python code... so it's even more confusing to me. Granted, I don't know the history of Neutron LBaaS, but it just seems to be that this particular area (LBaaS) has such blatantly overlapping codebases with separate contributor teams. Just baffling really. Any background or history you can give me (however opinionated!) would be very much appreciated :) > After the 5.x release of Libra has been stabilised we will be working towards > integration with Neutron. It is a very important thing on our roadmap and we > are already working with 2 other large companies in Openstack to figure that > piece out. Which large OpenStack companies? Are these companies currently deploying Libra? Thanks, -jay > If anyone else wants to get involved or just wants to play with Libra I’m > sure the HP team would be happy to hear about it and help where they can. > > Hope this helps > > Kind Regards > Andrew > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
On 17 Jan 2014, at 16:10, Jay Pipes wrote: > On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote: >> Hi all, >> >> I've been looking at Neutron default LBaaS provider using haproxy, and while >> it's working nicely, it seems to have several shortcomings in terms of >> scalability and high availability. The Libra project seems to offer a more >> robust alternative, at least for scaling. The haproxy implementation in >> Neutron seems to continue to evolve (like with >> https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy), but I'm >> wondering why we can't leverage Libra. The APIs are a bit different, but the >> goals look very similar, and there is a waste of effort with 2 different >> implementations. Maybe we could see a Libra driver for Neutron LBaaS for >> example? > > Yep, it's a completely duplicative and wasteful effort. > > It would be great for Libra developers to contribute to Neutron LBaaS. Hi Jay and Thomas, I am the outgoing technical lead of Libra for HP. But will reply whilst the new technical lead (Marc Pilon) gets subscribed to this. I would go as far as duplicative or wasteful. Libra existed before Neutron LBaaS and is originally based on the Atlas API specifications. Neutron LBaaS has started duplicating some of our features recently which we find quite flattering. After the 5.x release of Libra has been stabilised we will be working towards integration with Neutron. It is a very important thing on our roadmap and we are already working with 2 other large companies in Openstack to figure that piece out. If anyone else wants to get involved or just wants to play with Libra I’m sure the HP team would be happy to hear about it and help where they can. Hope this helps Kind Regards Andrew ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote: > Hi all, > > I've been looking at Neutron default LBaaS provider using haproxy, and while > it's working nicely, it seems to have several shortcomings in terms of > scalability and high availability. The Libra project seems to offer a more > robust alternative, at least for scaling. The haproxy implementation in > Neutron seems to continue to evolve (like with > https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy), but I'm > wondering why we can't leverage Libra. The APIs are a bit different, but the > goals look very similar, and there is a waste of effort with 2 different > implementations. Maybe we could see a Libra driver for Neutron LBaaS for > example? Yep, it's a completely duplicative and wasteful effort. It would be great for Libra developers to contribute to Neutron LBaaS. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra
Hi all, I've been looking at Neutron default LBaaS provider using haproxy, and while it's working nicely, it seems to have several shortcomings in terms of scalability and high availability. The Libra project seems to offer a more robust alternative, at least for scaling. The haproxy implementation in Neutron seems to continue to evolve (like with https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy), but I'm wondering why we can't leverage Libra. The APIs are a bit different, but the goals look very similar, and there is a waste of effort with 2 different implementations. Maybe we could see a Libra driver for Neutron LBaaS for example? Thanks, -- Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
