<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body 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<br>
<br>
<div class="moz-cite-prefix">On 04/17/2014 09:01 PM, Stephen
Balukoff wrote:<br>
</div>
<blockquote
cite="mid:CAAGw+Zqg5HGt8nefSix+e7Db=-1hQzQLXYR8RaaL2WGfVSe+bQ@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<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 moz-do-not-send="true"
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 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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true" href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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 class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>