Open Stack

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.