<div dir="ltr">Hi Stephen,<br><div class="gmail_extra"><br><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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><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></div></blockquote><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<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></div>
</div></blockquote><div>The need of that is understood, however, I think there are other options based on smarter scheduling and SLAs.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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><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></div></div></blockquote><div>To me it seems that  loadbalancer/VIPs/Listeners is only needed for multiple l2 enpoints, e.g.:</div><div>container / n x L2 / m x L4+</div>
<div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<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></div></div></blockquote><div>Agree. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>* To larger customers with advanced load balancing needs:  Yes.</div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>* To operators of any size: Yes.</div></div></div></div></blockquote><div>While operators may want to operate/monitor backends directly, that seems to be out of tenant API scope.</div>
<div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I've outlined my reasoning for thinking so in the other discussion thread.</div></div></div></div></blockquote><div>The reasoning seems clear to me, I just suggest that there are other options that could help in supporting those advanced cases.</div>
<div><br></div><div>Thanks,</div><div>Eugene.</div></div></div></div>