[openstack-dev] [Neutron][LBaaS] Requirements and API revision progress

Stephen Balukoff sbalukoff at bluebox.net
Fri Apr 18 00:03:31 UTC 2014


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.logan at 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 )?
>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140417/2f0ea5bf/attachment.html>


More information about the OpenStack-dev mailing list