Open Stack

On Fri, May 9, 2014 at 7:40 PM, Brandon Logan
<brandon.logan at rackspace.com>wrote:

> Yes, Rackspace has users that have multiple IPv4 and IPv6 VIPs on a
> single load balancer.

For sure that can be supported by particular physical appliance, but I
doubt we need to translate it to logical loadbalancer.


> However, I don't think it is a matter of it being
> needed.  It's a matter of having an API that makes sense to a user.
> Just because the API has multiple VIPs doesn't mean every VIP needs its
> own port. In fact creating a port is an implementation detail (you know

that phrase that everyone throws out to stonewall any discussions?).
> The user doesn't care how many neutron ports are set up underneath, they
> only care about the VIPs.
>
Right, port creation is implementation detail, however, L2 connectivity for
the frontend is a certain API expectation.
I think VIP creation should have clear semantics: user creates L2 endpoint,
e.g. l2 port + ipv4[+ipv6] address.
If we agree that we only need 1 L2 port per logical loadbalancer, then it
could be handled by two API/objmodel approaches:

1) loadbalancer + VIPs,  1:n relationship
2) VIP + listeners, 1:n relationship
You see that from API and obj model structure perspective those approaches
are exactly the same.
However, in (1) we would need to specify L3 information (ipv4 + ipv6
addresses, subnet_id) for the loadbalancer, and that will be inherited by
VIPs which would keep info about L4+
To me it seems a little bit confusing (per our glossary)

While in second approach VIP remains a keeper of L2/L3 information, while
listeners keep L4+ information.
That seems to be more clear.

In case we want more than one L2 port, then we need to combine those
approaches and have loadbalancer+VIPs+Listeners, where loadbalancer is a
container that maps to a backend.
However, per discussed on the last meeting, we don't want to let user have
direct control over the backend.
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.


Also, the load balancer wouldn't just be a container, the load balancer
> would have flavor, affinity, and other metadata on it.  Plus, a user
> will expect to get a load balancer back.  Since this object can only be
> described as a load balancer, the name of it shouldn't be up for debate.
>
Per comments above - VIP can also play this role.

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