Excerpts from Vishvananda Ishaya's message of 2014-01-21 12:16:12 -0800: > > 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
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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
