On Jan 19, 2014, at 8:19 AM, Clint Byrum <cl...@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@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