[openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra

Clint Byrum clint at fewbar.com
Sat Jan 25 15:28:25 UTC 2014


Excerpts from Vishvananda Ishaya's message of 2014-01-21 12:16:12 -0800:
> 
> On Jan 19, 2014, at 8:19 AM, Clint Byrum <clint at fewbar.com> 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.



More information about the OpenStack-dev mailing list