<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 9, 2014 at 7:40 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" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, Rackspace has users that have multiple IPv4 and IPv6 VIPs on a<br>
single load balancer.  </blockquote><div>For sure that can be supported by particular physical appliance, but I doubt we need to translate it to logical loadbalancer.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


However, I don't think it is a matter of it being<br>
needed.  It's a matter of having an API that makes sense to a user.<br>
Just because the API has multiple VIPs doesn't mean every VIP needs its<br>
own port. In fact creating a port is an implementation detail (you know</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
that phrase that everyone throws out to stonewall any discussions?).<br>
The user doesn't care how many neutron ports are set up underneath, they<br>
only care about the VIPs.<br></blockquote><div>Right, port creation is implementation detail, however, L2 connectivity for the frontend is a certain API expectation. </div><div>I think VIP creation should have clear semantics: user creates L2 endpoint, e.g. l2 port + ipv4[+ipv6] address.</div>
<div>If we agree that we only need 1 L2 port per logical loadbalancer, then it could be handled by two API/objmodel approaches:</div><div><br></div><div>1) loadbalancer + VIPs,  1:n relationship</div><div>2) VIP + listeners, 1:n relationship</div>
<div>You see that from API and obj model structure perspective those approaches are exactly the same.</div><div>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+</div>
<div>To me it seems a little bit confusing (per our glossary)</div><div><br></div>
<div>While in second approach VIP remains a keeper of L2/L3 information, while listeners keep L4+ information.</div><div>That seems to be more clear.</div><div><br></div><div>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.</div>
<div>However, per discussed on the last meeting, we don't want to let user have direct control over the backend.</div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, the load balancer wouldn't just be a container, the load balancer<br>
would have flavor, affinity, and other metadata on it.  Plus, a user<br>
will expect to get a load balancer back.  Since this object can only be<br>
described as a load balancer, the name of it shouldn't be up for debate.<br></blockquote><div>Per comments above - VIP can also play this role.</div><div><br></div><div>Thanks,</div><div>Eugene.</div></div></div></div>