<div dir="ltr">Folks, <div><br></div><div>As we're discussing single-call approach, I think it would be helpful to actually implement such API (e,g. practically, in the code) and see how it works, how compatibility is maintained and such.</div>
<div>I think you could start with basic features available for single call - e.g. single vip and single pool (as supported by existing API)</div><div>In other words, let's relax the requirement of supporting everything within one call (it should be the goal eventually), but as a first step something more simple is enough.</div>
<div><br></div><div>Basically I would prefer if there was not a competition between API styles, so I'm strongly against versioning. Let's do it side by side, if single-call API proves to work well - it will be a nice addition for those who expect it.</div>
<div><br></div><div>Thanks,</div><div>Eugene.<br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 18, 2014 at 6:36 AM, 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">
    We look forward to your proposal and I hope that does get us closer
    (if not all the way to) an agreed upon revision.  Also, thank you
    for taking the time to fully understand our thought processes on
    some of the features we want and decisions we made in the proposal.<br>
    <br>
    Thanks,<br>
    Brandon<div><div class="h5"><br>
    <br>
    <div>On 04/17/2014 09:01 PM, Stephen
      Balukoff wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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">
            <div> 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><br>
                  <br>
                  <div>On 04/17/2014 07:03 PM, Stephen Balukoff wrote:<br>
                  </div>
                </div>
              </div>
              <blockquote type="cite">
                <div>
                  <div>
                    <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><span><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></div>

                      <div class="gmail_extra"><span><br>
                        </span></div>
                      <div class="gmail_extra"><span>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></div>
                      <div class="gmail_extra"><span><br>
                        </span></div>
                      <div class="gmail_extra"><span>In your proposal,
                          you state "</span><span>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><br>
                        </span></div>
                      <div class="gmail_extra"><span>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><br>
                        </span></div>
                      <div class="gmail_extra"><span>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><br>
                        </span></div>
                      <div class="gmail_extra"><span>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">
                            <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>
                        <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>
                  <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" target="_blank">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>
        <div><br>
        </div>
        -- <br>
        <span></span>Stephen Balukoff
        <br>
        Blue Box Group, LLC
        <br>
        (800)613-4305 x807
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <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>
    </blockquote>
    <br>
  </div></div></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></div>