Open Stack

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
 * 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140121/f92c443b/attachment.pgp>