Open Stack

Hi Stephen,




>> While in second approach VIP remains a keeper of L2/L3 information, while
>> listeners keep L4+ information.
>> That seems to be more clear.
>>
>
> There's a complication though: Pools may also need some L2/L3 information
> (per the discussion of adding subnet_id as an attribute of the pool, eh.)
>
Right,  pool needs that, but I'm talking about frontend here. Obviously in
case loadbalancer balances traffic over several pools that may be on
different subnets - it may need to have l2 ports on each of them, just as
you said below.


> And actually, there are a few cases that have been discussed where
> operators do want users to be able to have some (limited) control over the
> back end. These almost all have to do with VIP affinity.
>
The need of that is understood, however, I think there are other options
based on smarter scheduling and SLAs.

Also we've heard objection to this approach several times from other core
>> team members (this discussion has been going for more than half a year
>> now), so I would suggest to move forward with single L2 port approach. Then
>> the question goes down to terminology: loadbalancer/VIPs or VIP/Listeners.
>>
>
> To be fair this is definitely about more than terminology. In the examples
> you've listed mentioning loadbalancer objects, it seems to me that you're
> ignoring that this model also still contains Listeners.  So, to be more
> accurate, it's really about:
>
> loadbalancer/VIPs/Listeners or VIPs/Listeners.
>
To me it seems that  loadbalancer/VIPs/Listeners is only needed for
multiple l2 enpoints, e.g.:
container / n x L2 / m x L4+
In single L2 endpoint case (i'm, again, talking about the front end) If we
say that VIP is L4+ only (tcp port, protocol, etc), then to properly handle
multiple VIPs in this case, L2/L3 information should be stored in
loadbalancer.


> To me, that says it's all about: Does the loadbalancer object add
> something meaningful to this model?  And I think the answer is:
>
> * To smaller users with very basic load balancing needs: No (mostly,
> though to many it's still "yes")
>
Agree.

> * To larger customers with advanced load balancing needs:  Yes.
>
* To operators of any size: Yes.
>
While operators may want to operate/monitor backends directly, that seems
to be out of tenant API scope.
We need to evaluate those 'advanced needs' for tenants and see if we can
address that without making lbaas a proxy between user and LB appliance.

I've outlined my reasoning for thinking so in the other discussion thread.
>
The reasoning seems clear to me, I just suggest that there are other
options that could help in supporting those advanced cases.

Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140510/ee797dcf/attachment.html>