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

Reply via email to