<div dir="ltr">Hi Brandon,<div><br></div><div>Yep! I agree that both those definitions are correct: It all depends on context.</div><div><br></div><div>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. :)</div>
<div><br></div><div>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.)</div>
<div><br></div><div>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.)</div>
<div><br></div><div>Thanks,</div><div>Stephen</div><div><br></div><div>"There are only two truly difficult problems in computer science: Naming things, cache invalidation, and off-by-one errors."</div><div><br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 17, 2014 at 6:31 PM, Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Stephen,<br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.  <br>
    <br>
    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.<br>
    <br>
    Thanks,<br>
    Brandon<div><div class="h5"><br>
    <br>
    <div>On 04/17/2014 07:03 PM, Stephen
      Balukoff wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      
      <div dir="ltr">
        <div class="gmail_extra">Hi Brandon!</div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">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:  <a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary" target="_blank">https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary</a></div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">As promised, here's my elaboration on
          that:</div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">The glossary above states:  "<span>An
            object that represent a logical load balancer that may have
            multiple resources such as Vips, Pools, Members, etc.</span><span>Loadbalancer
            is a root object in the meaning described above." and
            references the diagram here:  </span><font color="#333333" face="Arial Unicode MS, Arial, sans-serif"><span style="font-size:14.399999618530273px;line-height:20px"><a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#Loadbalancer_instance_solution" target="_blank">https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#Loadbalancer_instance_solution</a></span></font></div>

        <div class="gmail_extra"><font color="#333333" face="Arial
            Unicode MS, Arial, sans-serif"><span style="font-size:14.399999618530273px;line-height:20px"><br>
            </span></font></div>
        <div class="gmail_extra"><font color="#333333" face="Arial
            Unicode MS, Arial, sans-serif"><span style="font-size:14.399999618530273px;line-height:20px">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).</span></font></div>
        <div class="gmail_extra"><font color="#333333" face="Arial
            Unicode MS, Arial, sans-serif"><span style="font-size:14.399999618530273px;line-height:20px"><br>
            </span></font></div>
        <div class="gmail_extra"><font color="#333333" face="Arial
            Unicode MS, Arial, sans-serif"><span style="font-size:14.399999618530273px;line-height:20px">In
              your proposal, you state "</span></font><span style="font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial">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.</span></div>
        <div class="gmail_extra"><span style="font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial"><br>
          </span></div>
        <div class="gmail_extra"><span style="font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial">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.</span></div>
        <div class="gmail_extra"><span style="font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial"><br>
          </span></div>
        <div class="gmail_extra"><span style="font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial">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. :)</span></div>
        <div class="gmail_extra"><span style="font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial"><br>
          </span></div>
        <div class="gmail_extra"><span style="font-size:15px;white-space:pre-wrap;background-color:transparent;font-family:Arial">Stephen</span></div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Wed, Apr 16, 2014 at 7:17 PM,
            Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div>
                <blockquote type="cite">
                  <div dir="ltr">
                    <div>
                      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 <a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary#Loadbalancer" target="_blank">https://wiki.openstack.org/wiki/Neutron/<span>LBaaS</span>/Glossary#Loadbalancer</a>
                      )?<br>
                    </div>
                  </div>
                </blockquote>
                <br>
              </div>
              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.</blockquote>
          </div>
          <br>
          <br>
          <br clear="all">
          <div><br>
          </div>
          -- <br>
          <span></span>Stephen Balukoff
          <br>
          Blue Box Group, LLC
          <br>
          <a href="tel:%28800%29613-4305%20x807" value="+18006134305" target="_blank">(800)613-4305 x807</a>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><div class=""><pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </div></blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807

</div>