<div dir="ltr">Hi Stephen,<br><div class="gmail_extra"><br>Some comments on comments on comments:</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 9, 2014 at 10:25 PM, Stephen Balukoff <span dir="ltr"><<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</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">Hi Eugene,<div><br></div><div>This assumes that 'VIP' is an entity that can contain both an IPv4 address and an IPv6 address. This is how it is in the API proposal and corresponding object model that I suggested, but it is a slight re-definition of the term "virtual IP" as it's used in the rest of the industry. (And again, we're not yet in agreement that 'VIP' should actually contain two ip addresses like this.)</div>
</div></blockquote><div>That seems a minor issue to me. May be we can just introduce a statement that VIP has L2 endpoint first of all? </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>In my mind, the main reasons I would like to see the container object are:</div><div><br></div><div><ul><li>It solves the colocation / apolcation (or affinity / anti-affinity) problem for VIPs in a way that is much more intuitive to understand and less confusing for users than either the "hints" included in my API, or something based off the nova blueprint for doing the same for virtual servers/containers. (Full disclosure: There probably would still be a need for some anti-affinity logic at the logical load balancer level as well, though at this point it would be an operator concern only and expressed to the user in the "flavor" of the logical load balancer object, and probably be associated with different billing strategies. "The user wants a dedicated physical load balancer? Then he should create one with this flavor, and note that it costs this much more...")</li>
</ul></div></div></blockquote><div>In fact, that can be solved by scheduling, without letting user to control that. Flavor Framework will be able to address that. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><ul>
<li>From my experience, users are already familiar with the concept of what a logical load balancer actually is (ie. something that resembles a physical or virtual appliance from their perspective). So this probably fits into their view of the world better.</li>
</ul></div></div></blockquote><div>That might be so, but apparently it goes in opposite direction than neutron in general (i.e. more abstraction) </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><ul>
<li>It makes sense for "Load Balancer as a Service" to hand out logical load balancer objects. I think this will aid in a more intuitive understanding of the service for users who otherwise don't want to be concerned with operations.</li>

<li>This opens up the option for private cloud operators / providers to bill based on number of physical load balancers used (if the "logical load balancer" happens to coincide with physical load balancer appliances in their implementation) in a way that is going to be seen as "more fair" and "more predictable" to the user because the user has more control over it. And it seems to me this is accomplished without producing any undue burden on public cloud providers, those who don't bill this way, or those for whom the "logical load balancer" doesn't coincide with physical load balancer appliances.</li>
</ul></div></div></blockquote><div>I don't see how 'loadbalancer' is better than 'VIP' here, other than being a bit closer term to 'logical loadbalancer'.</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><ul>
<li>Attaching a "flavor" attribute to a logical load balancer seems like a better idea than attaching it to the VIP. What if the user wants to change the flavor on which their VIP is deployed (ie. without changing IP addresses)? What if they want to do this for several VIPs at once? I can definitely see this happening in our customer base through the lifecycle of many of our customers' applications.</li>
</ul></div></div></blockquote><div>I don't see any problems with above cases if VIP is the root object</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div><ul>
<li>Having flavors associated with load balancers and not VIPs also allows for operators to provide a lot more differing product offerings to the user in a way that is simple for the user to understand. For example:</li>
<ul>
<li>"Flavor A" is the cheap load balancer option, deployed on a "shared" platform used by many tenants that has fewer guarantees around performance and costs X.</li><li>"Flavor B" is guaranteed to be deployed on "vendor Q's Super Special Product (tm)" but to keep down costs, may be shared with other tenants, though not among a single tenant's "load balancers" unless the tenant uses the same load balancer id when deploying their VIPs (ie. user has control of affinity among their own VIPs, but no control over whether affinity happens with other tenants). It may experience variable performance as a result, but has higher guarantees than the above and costs a little more.</li>

<li>"Flavor C" is guaranteed to be deployed on "vendor P's Even Better Super Special Product (tm)" and is also guaranteed not to be shared among tenants. This is essentially the "dedicated load balancer" option that gets you the best guaranteed performance, but costs a lot more than the above.</li>

<li>...and so on.</li></ul></ul></div></div></blockquote><div>Right, that's how flavors are supposed to work, but that's again unrelated to whether we make VIP or loadbalancer our root object.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><ul><li>A logical load balancer object is a great <a href="http://en.wikipedia.org/wiki/Demarcation_point" target="_blank">demarcation point </a> between operator concerns and user concerns. It seems likely that there will be an operator API created, and this will need to interface with the user API at some well-defined interface. (If you like, I can provide a couple specific operator concerns which are much more easily accomplished without disrupting the user experience using the demarc at the 'load balancer' instead of at the 'VIP'.)</li>
</ul></div></div></blockquote><div>That might be fine to have loadbalancer for admin API, but we're discussing tenant API right now.</div><div>For admin API 'loadbalancer' could be direct representation of a backend. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>So what are the main arguments against having this container object? In answering this question, please keep in mind:</div>
<div><br></div><div><ul><li>If you say "implementation details," please just go ahead and be more specific because that's what I'm going to ask you to do anyway. If "implementation details" is the concern, please follow this with a hypothetical or concrete example as to what kinds of implementations this object would invalidate simply by existing in the model, or what restrictions this object introduces.<br>
</li></ul></div></div></blockquote><div>I personally never used this as an argument. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ul><li>

</li><li>If you say "I don't see a need" then you're really just asking people to come up with a use case that is more easily solved using the logical load balancer object rather than the VIP without the load balancer. </li>
</ul></div></div></blockquote><div>Right, there could be cases that more 'easily' solved by loadbalancer rather then other methods. Like aforementioned collocation problem. </div><div>But that's where project-wise design considerations apply. It's better if we go with projects direction, which is going to address those cases by other methods rather than by direct user control.</div>
<div><br></div><div>Thanks,</div><div>Eugene.</div></div></div></div>