Hi Brandon,

Yep! I agree that both those definitions are correct: It all depends on

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

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.)


"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

>  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> 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
> _______________________________________________
> OpenStack-dev mailing 
> listOpenStack-dev@lists.openstack.orghttp://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

Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
OpenStack-dev mailing list

Reply via email to