Open Stack

Folks,

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.
I think you could start with basic features available for single call -
e.g. single vip and single pool (as supported by existing API)
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.

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.

Thanks,
Eugene.




On Fri, Apr 18, 2014 at 6:36 AM, Brandon Logan
<brandon.logan at rackspace.com>wrote:

>  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.
>
> Thanks,
> Brandon
>
>
> On 04/17/2014 09:01 PM, Stephen Balukoff wrote:
>
> Hi Brandon,
>
>  Yep! I agree that both those definitions are correct: It all depends on
> context.
>
>  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
> somehow.)
>
>  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.)
>
>  Thanks,
> Stephen
>
>  "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 <
> brandon.logan at rackspace.com> wrote:
>
>>  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.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 <%28800%29613-4305%20x807>
>>
>>
>>   _______________________________________________
>> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at 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 listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140418/90014e59/attachment.html>