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 <sbaluk...@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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
