Open Stack

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