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