Hi Brandon,
Yep! I agree that both those definitions are correct: It all depends
on context.
I'm usually OK with going with whatever definition is in popular use
by the user-base. However, "load balancer" as a term is so ambiguous
among people actually developing a cloud load balancing system that a
definition or more specific term is probably called for. :)
In any case, all I'm really looking for is a glossary of defined terms
attached to the API proposal, especially for terms like this that can
have several meanings depending on context. (That is to say, I don't
think it's necessary to define "IP address" for example-- unless,
say, the distinction between IPv4 or IPv6 becomes important to the
conversation somehow.)
In any case note that I actually like your API thus far and think it's
a pretty good start: Y'all put forth the laudable effort to actually
create it, there's obviously a lot of forethought put into your
proposal, and that certainly deserves respect! In fact, my team and I
will probably be building off of what you've started in creating our
proposal (which, again, I hope to have in a "showable" state before
next week's meeting, and which I'm anticipating won't be the final
form this API revision takes anyway.)
Thanks,
Stephen
"There are only two truly difficult problems in computer science:
Naming things, cache invalidation, and off-by-one errors."
On Thu, Apr 17, 2014 at 6:31 PM, Brandon Logan
<brandon.lo...@rackspace.com <mailto:brandon.lo...@rackspace.com>> wrote:
Stephen,
Thanks for elaborating on this. I agreed and still do that our
proposal's load balancer falls more in line with that glossary's
term for "listener" and now can see the discrepancy with "load
balancer". Yes, in this case the term "load balancer" would have
to be redefined, but that doesn't mean it is the wrong thing to do.
I've always been on the side of the Load Balancing as a Service
API using a root object called a "load balancer". This just really
makes sense to me and others, but obviously it doesn't for
everyone. However, in our experience end users just understand
the service better when the service takes in load balancer objects
and returns load balancer objects.
Also, since it has been tasked to defined a new API we felt that
it was implied that some definitions were going to change,
especially those that are subjective. There are definitely many
definitions of a load balancer. Is a load balancer an appliance
(virtual or physical) that load balances many protocols and ports
and is it also one that load balances a single protocol on a
single port? I would say that is definitely subjective.
Obviously I, and others, feel that both of those are true. I
would like to hear arguments as to why one of them is not true,
though.
Either way, we could have named that object a "sqonkey" and given
a definition in that glossary. Now we can all agree that while
that word is just an amazing word, its a terrible name to use in
any context for this service. It seems to me that an API can
define and also redefine subjective terms.
I'm glad you don't find this as a deal breaker and are okay with
redefining the term. I hope we all can come to agreement on an
API and I hope it satisfies everyone's needs and ideas of a good API.
Thanks,
Brandon
On 04/17/2014 07:03 PM, Stephen Balukoff wrote:
Hi Brandon!
Per the meeting this morning, I seem to recall you were looking
to have me elaborate on why the term 'load balancer' as used in
your API proposal is significantly different from the term 'load
balancer' as used in the glossary at:
https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary
As promised, here's my elaboration on that:
The glossary above states: "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." and references the diagram here:
https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#Loadbalancer_instance_solution
On that diagram, it's clear that VIPs, & etc. are subordinate
objects to a load balancer. What's more, attributes like
'protocol' and 'port' are not part of the load balancer object in
that diagram (they're part of a 'VIP' in one proposed version,
and part of a 'Listener' in the others).
In your proposal, you state "only one port and one protocol per
load balancer," and then later (on page 9 under "GET /vips") you
show that a vip may have many load balancers associated with it.
So clearly, "load balancer" the way you're using it is
subordinate to a VIP. So in the glossary, it sounds like the
object which has a single port and protocol associated with it
that is subordinate to a VIP: A listener.
Now, I don't really care if y'all decide to re-define "load
balancer" from what is in the glossary so long as you do define
it clearly in the proposal. (If we go with your proposal, it
would then make sense to update the glossary accordingly.)
Mostly, I'm just trying to avoid confusion because it's exactly
these kinds of misunderstandings which have stymied discussion
and progress in the past, eh.
Also-- I can guess where the confusion comes from: I'm guessing
most customers refer to "a service which listens on a tcp or udp
port, understands a specific protocol, and forwards data from the
connecting client to some back-end server which actually services
the request" as a "load balancer." It's entirely possible that in
the glossary and in previous discussions we've been mis-using the
term (like we have with VIP). Personally, I suspect it's an
overloaded term that in use in our industry means different
things depending on context (and is probably often mis-used by
people who don't understand what load balancing actually is).
Again, I care less about what specific terms we decide on so long
as we define them so that everyone can be on the same page and
know what we're talking about. :)
Stephen
On Wed, Apr 16, 2014 at 7:17 PM, Brandon Logan
<brandon.lo...@rackspace.com
<mailto:brandon.lo...@rackspace.com>> wrote:
You say 'only one port and protocol per load balancer', yet
I don't know how this works. Could you define what a 'load
balancer' is in this case? (port and protocol are
attributes that I would associate with a TCP or UDP listener
of some kind.) Are you using 'load balancer' to mean
'listener' in this case (contrary to previous discussion of
this on this list and the one defined here
https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary#Loadbalancer
<https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary#Loadbalancer>
)?
Yes, it could be considered as a Listener according to that
documentation. The way to have a "listener" using the same
VIP but listen on two different ports is something we call
VIP sharing. You would assign a VIP to one load balancer
that uses one port, and then assign that same VIP to another
load balancer but that load balancer is using a different
port than the first one. How the backend implements it is an
implementation detail (redudant, I know). In the case of
HaProxy it would just add the second port to the same config
that the first load balancer was using. In other drivers it
might be different.
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807 <tel:%28800%29613-4305%20x807>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
