Open Stack

Howdy y'all!

Per the e-mail I sent out earlier today, I wanted to share some thoughts on
the API proposals from Rackspace and Blue Box that we're currently working
on evaluating, presumably to decide which will be the version will be the
"starting point" from which we make revisions going forward.  I'll try to
be relatively brief.

*First, some thanks!*

The Rackspace team really pulled out the stops this last week producing an
abundance of documentation that very thoroughly covers a bunch of the use
cases available at that time in excruciating detail. They've produced a
glossary and suggested object diagram, and their proposal is actually
looking pretty dang good in my opinion.

I'm especially interested in hearing your opinion on the stuff I'm laying
out below-- especially if I'm misunderstanding or mis-representing your
viewpoint on any issue, eh!

*Why the review process we're using probably won't be conclusive*

So, at the last week's meeting we decided that the RAX team and I would
work on producing a spreadsheet listing the use cases in question and go
over how each of these would be accomplished using our API.

Having gone through this exercise, I see the following problems with this
approach to evaluation:

   - While we have thorough documentation, it's probably more than the
   average participant here is going to go through with a fine-toothed comb to
   find the subtle differences. Furthermore, there's already a huge amount of
   documentation produced, and we've only gone over about 1/5th of the use
   cases!
   - Since the BBG version API proposal is actually a revision of the
   Rackspace proposal in many ways, at its core, our models are actually so
   similar that the subtle differences don't come out with general / generic
   use cases in many ways. And the only use cases we've evaluated so far are
   pretty general. :/
   - In fact, the only significant ways in which the proposals differ are:
      - BBG proposal uses "VIP" as single-call interface, and it's the root
      of the object tree from the user's perspective.
      - Rackspace proposal uses "loadbalancer" as single-call interface,
      and it's the root of the object tree from the user's perspective (And the
      Rackspace "loadbalancer" is essentially the same thing as the BBG
      "Listener")
      - Rackspace proposal allows n:m relationship between loadbalancer and
      VIP, mostly to solve the IPv6 + IPv4 use case.
      - BBG proposal just has attributes for both and IPv4 address and an
      IPv6 address in its "VIP" object. (Meaning it's slightly different than a
      "VIP" as people are likely to assume what that term means.)
      - Rackspace and BBG proposals differ quite a bit in how they
      accomplish L7 functionality and SSL certificate functionality.
      Unfortunately, none of use cases we've evaluated touch
significantly on any
      of the differences (with the exception that some L7
functionality has been
      expanded upon in some use cases).

We could go through and add more use cases which touch on the differences
between our models, but that feels to me like those would be pretty
contrived and not reflect real-world demands. Further, given how much
documentation we've produced on this so far, it's unlikely anyone would
read it all, let alone in time for a speedy decision. And it probably
doesn't make sense to expand on specific use cases until we know they're
actually needed by most prospective LBaaS users (ie. once we know the
results of the survey that Sam started.)

I hate to say it, but it feels like we're futilely spinning our wheels on
this one.

In other words, if we're going to come to consensus on this, we need to
change the evaluation process somewhat, eh.

*Maybe we should wait until the survey results are out?*
No sense solving for use cases that nobody cares about, eh.

*Maybe we should just look at the differences?*
The core object models we've proposed are almost identical. Change the term
"Listener" to "Load Balancer" in my model, and you've essentially got the
same thing as the Rackspace model.

So maybe it makes sense just to look at the differences, and how to best
resolve these?

For example, I understand the Rackspace model is using a join object
between "load balancer" and "vip" so these can have a n:m relationship--
and this is almost entirely to solve use case #14 in the document. I solved
this in mine by just twisting slightly the definition of a VIP to include
both an (optional) IPv4 and IPv6 address. However, there might be use cases
that someone comes up with where having a Listener/load balancer associated
with multiple VIPs makes sense (some horizontal scaling algorithms might do
it this way).

In any case, this difference is easily resolved by adding the n:m join
object to my model as well. (Assuming there's a valid use case to justify
this.) All it would mean, from the user perspective, is that when they look
at the attributes of Listener, the vip_id would be an array instead of a
singular UUID.

(There are other differences around monitoring and stats which apply to
these differences in the model, too... but again, we don't have any use
cases which touch on this yet!)

*Maybe we should do the evaluation "debate style"?*
So that people don't get buried in too much documentation, maybe we should
just have each team write a short-ish document outlining why they think
their proposal is "better" and what they think is "not as good" with the
competing proposal? Then, give each team a chance to respond to all the
so-called faults found in their proposal. Then a chance for a
counter-response. I think we could do this respectfully, and it would be a
quicker way for our API proposal teams (who are necessarily looking at this
stuff in depth) to communicate the actual meaningful differences between
our APIs and models to the rest of the group more quickly.

We'd probably need to vote on this or something, especially if we can't
come to a solid compromise that works for everyone-- and I have no idea how
that should work. :P

*We need to decide what "load balancer" means and go that.*
This has been something that's come up a lot, and the more we ignore it, it
seems to me, the more it just adds to the confusion to the discussion.

Rackspace is defining a load balancer as:  An entity that contains multiple
VIPs, but only one tcp/udp port and protocol (
http://en.wikipedia.org/wiki/Load_balancing_%28computing%29) . It may have
a default pool (named just pool in API object).  It also may have a content
switching object attached that defines L7 rules.

I also understand Rackspace's definition comes from wikipedia ("For
Internet services, the load balancer is usually a software program that is
listening on the port <http://en.wikipedia.org/wiki/TCP_and_UDP_port> where
external clients connect to access services."). This is usually a pretty
good source for definitions, though I will say it is somewhat vague, as the
article is by its nature addressing an audience not familiar with the
technology. But this definition probably has more to do with what the user
means when they say "load balancer." And, please correct me if I'm wrong,
but there might be some, shall we say "institutional inertia" around the
meaning of the term.

(Techinically, haproxy is a load balancer by the wikipedia definition-- and
haproxy can listen on multiple ports and multiple IPs in a single
configuration. :P )

I am defining a load balancer to be:  An object that represent a logical
load balancer that may have multiple resources such as Vips, Pools,
Members, etc.
Loadbalancer is a root object in the meaning described above.
It's a first entry to be created in the workflow, to receive
provider/flavor properties and an object to turn on and off whole
loadbalancer configuration.

I would like to point out that this doesn't actually contradict the
wikipedia definition (since wikipedia is so vague). This is certainly more
akin to what pretty much every load balancer vendor and most operators (who
buy load balancers from vendors) I've seen use as their definition. (eg:
https://f5.com/glossary/load-balancer ) And yes, we've definitely got
institutional inertia around the meaning of the term.

I've also advocated (mostly as a compromise) dropping the term as "too
vague" for a serious discussion of load balancing services among the people
actually developing said services. I think we should be using more specific
terms whose meaning is more obvious to more of us without explanation. What
do y'all think?

Having said that, we are working on a "Load Balancer as a Service" that
doesn't actually deliver a "load balancer" object under my API proposal
(because it's been shot down as an "implementation detail" every time I've
tried to promote it so far.)

It seems silly to me that we might not be able to come to an agreement over
the use of the term "load balancer," and that this could ultimately lead to
divergence on this project as a whole. :P

So let's please decide somehow how the term "load balancer" should be used
in this discussion and glossaries going forward and stick with it. :P

*What does "the root" mean when we're looking at an object graph, not a
tree? Or maybe the people most likely to use the single-call interface
should have the strongest voices in deciding where it should actually be
placed?*
I think probably the biggest source of contention over the API proposals
thus far are what object should be considered the "root" of the tree.

This whole concept seems to strike me as odd-- because when you have a
graph, even if it's somewhat tree-like (ie. there are leaf nodes), does the
term "root" even apply? Can someone please tell me what criteria they're
using when they say that one object should be a "root" and another should
not?

(For what it's worth, I could probably propose a version of the API that
does single-call through a 'healthmonitor' object. Though it would be
silly, it would still be perfectly functional. :P )

Having said all this, we already know the API is going to support
manipulation of individual objects as a way to provision services. If the
people advocating for making the "VIP" the root of the object tree don't
actually intend to use single-call for manipulating their objects, what do
we care if those who are going to use single-call would rather do this
through the "listener / load balancer" object?

And... that's about it. Sorry for the length of this e-mail, y'all!

Thanks,
Stephen

-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807i
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140507/ab05fa65/attachment.html>