<div dir="ltr">Hi Brandon,<div><br></div><div>Glad to see more new blood in this project and discussion. (I've also only recently gotten involved in the discussion here. And I've sent my ideas on this front to this list in the last couple of weeks-- let me know if you'd like me to send you links to this discussion.)</div>
<div><br></div><div>I think Jay covered what I understand to be the current state of affairs at this point, but I would point out that largely the discussion so far has been about the right way to implement Layer-7 features and SSL, and not really about how HA and scalability play into this (though I've been trying to foster the discussion in this direction. :) )</div>
<div><br></div><div>As such, I don't think it's fair to say that the Neutron LBaaS community has fully considered the HA or scalability problems just yet, nor what changes are going to need to happen to make these features available. And given that, I don't get the impression that it's at all decided that HA and scalability features will be solely delegated to the driver level-- that is to say, the community may yet decide there are certain entities (like the idea of a logical "load balancer" construct) that make sense to apply to the Neutron LBaaS model which help both driver writers to implement HA features, and help end users to write their applications without having to navigate a minefield of optionally supported features of a given load balancer implementation. (I'm actually looking forward to seeing Jay's fleshed out ideas which I understand counter this point which may make a 'loadbalancer' object unnecessary and thus allow a lot more flexibility in implementation.)</div>
<div><br></div><div>Given we're still struggling to find consensus on the changes that will enable L7 and SSL, it may be a bit premature to start talking about HA and scalability (though, again, I would like it if we could be this forward-thinking about the project. :) ) I'm really hoping we can make significant progress on this at the Atlanta summit in May.</div>
<div><br></div><div>In any case, welcome to the discussion!</div><div><br></div><div>Stephen</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 28, 2014 at 9:51 AM, Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks,<br>
Brandon<br>
________________________________________<br>
From: Jay Pipes [<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>]<br>
Sent: Thursday, February 27, 2014 8:52 PM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Neutron][LBaaS] Enterprise Ready Features<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, 2014-02-26 at 18:46 +0000, Brandon Logan wrote:<br>
> TL;DR: Are enterprise needed features (HA, scalability, resource<br>
> management, etc) on this project's roadmap.<br>
<br>
Yes. Although, due to my disdain for the term "enterprise", I'd point<br>
out that all of those features are things that most everyone wants, not<br>
just shops with stodgy, old, legacy IT departments -- I mean...<br>
"enterprises" ;)<br>
<br>
> If so, how much of a priority is it?<br>
<br>
Not sure.<br>
<br>
> I've been doing some research on Neutron LBaaS to determine the<br>
> viability and what needs to be done to allow for it to become an<br>
> enterprise ready solution.<br>
<br>
Out of curiosity, since you are at Rackspace, what about Atlas LB?<br>
<br>
> Since I am fairly new to this project please forgive me, and also<br>
> correct me, if my understanding of some of these things is false.<br>
> I've already spoken to Eugene about some of this, but I think it would<br>
> be nice to get everyone's opinion. And since the object model<br>
> discussions are going on right now I believe this to be a good time to<br>
> bring it up.<br>
<br>
Ya, no worries. I'm new to the LBaaS discussions myself.<br>
<br>
> As of its current incarnation Neutron LBaaS does not seem to be HA,<br>
> scalable, and doesn't isolate resources for each load balancer. I<br>
> know there is a blueprint for HA for the agent<br>
> (<a href="https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-agent" target="_blank">https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-agent</a>) and HA<br>
> for HaProxy<br>
> (<a href="https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy" target="_blank">https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy</a>).<br>
> That is only for HaProxy, though, and sounds like it has to be<br>
> implemented at the driver level.<br>
<br>
Right. Different drivers will enable HA in different ways.<br>
<br>
> Is that the intended direction for implementing these goals, to<br>
> implement them at the driver level?<br>
<br>
I *believe* that is the intended direction, yes. The ongoing<br>
conversations about Neutron "flavors" as well as the conversation about<br>
the future object model and API have really been about how to expose the<br>
capabilities of different drivers -- and match those capabilities to<br>
requested capabilities from the user -- without leaking any particular<br>
driver's implementation specifics into the public API. I think the hope<br>
is that in the coming few months and during the summit, the community<br>
will coalesce around a game plan for implementing "flavors" (or types,<br>
as I prefer to call them), and from that implementation, contributors<br>
will be able to work on adding these features to drivers and expose this<br>
functionality in a generic fashion.<br>
<br>
> I can definitely see why that is the way to do it because some<br>
> drivers may already implement these features, while others don't. It<br>
> would be nice if there was a way to give those features to drivers<br>
> that do not have it out of the box.<br>
<br>
Well, on the HA and scaling front, one solution is to run multiple<br>
instances of something like HA Proxy and have some healthcheck software<br>
that would fail over operations from one load balancer instance to<br>
another if a failure condition occurred. In fact, that is similar to<br>
what the Libra project does with its node pool manager [1].<br>
<br>
> Basically, I'd like this project to have these enterprise level<br>
> features to that it can be adopted in an enterprise cloud. It will<br>
> require a lot of work to achieve these goals, and I believe it should<br>
> be something that is a goal.<br>
<br>
I don't think you'll get any disagreement from anyone on that :)<br>
Although there has certainly been a fragmentation of effort on the LBaaS<br>
front with Atlas, Libra and Neutron LBaaS, it seems that the community<br>
is now coming together a bit.<br>
<br>
Best,<br>
-jay<br>
<br>
[1] <a href="http://libra.readthedocs.org/en/latest/pool_mgm/index.html" target="_blank">http://libra.readthedocs.org/en/latest/pool_mgm/index.html</a><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807
</div>