<div dir="ltr">Hi Eugene,<div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 9, 2014 at 1:36 PM, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">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><div>For sure that can be supported by particular physical appliance, but I doubt we need to translate it to logical loadbalancer.</div><div class=""><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><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></div></div></blockquote><div><br></div><div>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.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div></blockquote><div><br></div><div>If the VIP subnet/neutron network and Pool subnet/neutron network are not the same, then the load balancer is going to need separate L2 interfaces to each. In fact, a VIP with a Listener that references several different pool via L7 policies, which pools are on different subnets, is going to need an L2 interface on all of them. Unless I'm totally misunderstanding something (which is always a possibility-- this stuff is hard, eh!)</div>
<div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div></blockquote><div><br></div><div>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:</div>
<div><br></div><div>loadbalancer/VIPs/Listeners or VIPs/Listeners.</div><div><br></div><div>To me, that says it's all about: Does the loadbalancer object add something meaningful to this model? And I think the answer is:</div>
<div><br></div><div>* To smaller users with very basic load balancing needs: No (mostly, though to many it's still "yes")</div><div>* To larger customers with advanced load balancing needs: Yes.</div><div>* To operators of any size: Yes.</div>
<div><br></div><div>I've outlined my reasoning for thinking so in the other discussion thread.</div><div> </div><div>Thanks,</div><div>Stephen</div><div><br></div></div><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807
</div></div>