Open Stack

Just a couple of quick comments since it is super late here and I don't want to reply to the entire email just yet...

Firstly, I think most of us at Rackspace like the way your proposal handles L7 (hopefully my team actually agrees and I am not speaking out of turn, but I definitely like it), so I wouldn't really consider that as a difference because I think we'd like to incorporate your method into our proposal anyway. Similarly, upon further review I think I would agree that our SSL cert handling is also a bit wonky, and could be much improved by another draft. In fact, I'd like to assume that what we're really discussing is making a third revision of the proposal, rather than whether to use one or the other verbatim.

Secondly, technical descriptions are great, but I'd like to talk about the term "load balancer" in a more approachable manner. I forget which thread I used this example in before, but to get an idea of what we mean by the term, I like to use it in some sentences.
"My web servers are behind a load balancer, so they can better serve traffic to my customers."
"I used to only have one MySQL server, but now I have three, so I put a load balancer in front of them to ensure they get an equal amount of traffic."
This isn't highly technical talk -- and it is definitely very generic -- but this is how REAL PEOPLE see the technology we're developing here. That is part of why the definitions we're using are so vague. I refuse to get tied down by an object graph full of pools and VIPs and listeners!
There are two very similar points I'd like to make here, and I feel that both are very important:
1. We shouldn't be looking at the current model and deciding which object is the root object, or what object to rename as a  "loadbalancer"... That's totally backwards! *We don't define which object is named the "loadbalancer" by looking for the root object -- we define which object is the root by looking for the object named "loadbalancer".* I had hoped that was clear from the JSON examples in our API proposal, but I think maybe there was too much focus on the object model chart, where this isn't nearly as clearly communicated.
2. As I believe I have also said before, if I'm using "<X> as a Service" then I expect to get back an object of type "<X>". I would be very frustrated/confused if, as a user, LBaaS returned me an object of type "VIP" when I POST a Create for my new load balancer. On this last point, I feel like I've said this enough times that I'm beating a dead horse...

Anyway, I should get at least a little bit of sleep tonight, so I'll see you all in IRC in a few hours!

  --Adam

PS: I really hope that colloquialism translates appropriately. I've got nothing against horses. :)

On May 7, 2014 7:44 PM, Stephen Balukoff <sbalukoff at bluebox.net> wrote:
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/20140508/708db7cf/attachment.html>