Thanks for your response Jay. I'm not a big fan of the term enterprise either but its the best single word term I could come up with to describe large scale, multi tenant deployments. I know these are things every project wants but I'm just gauging how important it is to accomplish these goals in this project.
As for Atlas LB, it has been dead for a year or two now. Unless it somehow got resurrected and we don't know about it. I really liked the API and object models, it allowed for multiple vips and was planned to implement a form of "flavors" (or types), not exactly the same way obviously, but the idea was there. I also like that it was a standalone project. A big problem with that project, though, was that it was going to be written in Java. There were also other political reasons for it dying but those will remain unsaid. The fragmentation is a bit of a concern but hopefully it will end up with the best ideas from all the projects going into one project that the community can agree on. We, Rackspace, are hoping to use Neutron LBaaS it but it does need to get into a more mature state. The Cloud Load Balancing team (the team I am on) is looking to start contributing to this project to help get it to where we need it for this to happen. Obviously, we need some ramp up time to fully understand the project and get more involved in the discussions. Hopefully we can contribute code and also share our experiences in what we learned in our successes and failures. We are all looking forward to working with the community on this. Thanks, Brandon ________________________________________ From: Jay Pipes [jaypi...@gmail.com] Sent: Thursday, February 27, 2014 8:52 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Enterprise Ready Features On Wed, 2014-02-26 at 18:46 +0000, Brandon Logan wrote: > TL;DR: Are enterprise needed features (HA, scalability, resource > management, etc) on this project's roadmap. Yes. Although, due to my disdain for the term "enterprise", I'd point out that all of those features are things that most everyone wants, not just shops with stodgy, old, legacy IT departments -- I mean... "enterprises" ;) > If so, how much of a priority is it? Not sure. > I've been doing some research on Neutron LBaaS to determine the > viability and what needs to be done to allow for it to become an > enterprise ready solution. Out of curiosity, since you are at Rackspace, what about Atlas LB? > Since I am fairly new to this project please forgive me, and also > correct me, if my understanding of some of these things is false. > I've already spoken to Eugene about some of this, but I think it would > be nice to get everyone's opinion. And since the object model > discussions are going on right now I believe this to be a good time to > bring it up. Ya, no worries. I'm new to the LBaaS discussions myself. > As of its current incarnation Neutron LBaaS does not seem to be HA, > scalable, and doesn't isolate resources for each load balancer. I > know there is a blueprint for HA for the agent > (https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-agent) and HA > for HaProxy > (https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy). > That is only for HaProxy, though, and sounds like it has to be > implemented at the driver level. Right. Different drivers will enable HA in different ways. > Is that the intended direction for implementing these goals, to > implement them at the driver level? I *believe* that is the intended direction, yes. The ongoing conversations about Neutron "flavors" as well as the conversation about the future object model and API have really been about how to expose the capabilities of different drivers -- and match those capabilities to requested capabilities from the user -- without leaking any particular driver's implementation specifics into the public API. I think the hope is that in the coming few months and during the summit, the community will coalesce around a game plan for implementing "flavors" (or types, as I prefer to call them), and from that implementation, contributors will be able to work on adding these features to drivers and expose this functionality in a generic fashion. > I can definitely see why that is the way to do it because some > drivers may already implement these features, while others don't. It > would be nice if there was a way to give those features to drivers > that do not have it out of the box. Well, on the HA and scaling front, one solution is to run multiple instances of something like HA Proxy and have some healthcheck software that would fail over operations from one load balancer instance to another if a failure condition occurred. In fact, that is similar to what the Libra project does with its node pool manager [1]. > Basically, I'd like this project to have these enterprise level > features to that it can be adopted in an enterprise cloud. It will > require a lot of work to achieve these goals, and I believe it should > be something that is a goal. I don't think you'll get any disagreement from anyone on that :) Although there has certainly been a fragmentation of effort on the LBaaS front with Atlas, Libra and Neutron LBaaS, it seems that the community is now coming together a bit. Best, -jay [1] http://libra.readthedocs.org/en/latest/pool_mgm/index.html _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
