Hi Stephen, Some comments on comments on comments:
On Fri, May 9, 2014 at 10:25 PM, Stephen Balukoff <[email protected]>wrote: > Hi Eugene, > > 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.) > That seems a minor issue to me. May be we can just introduce a statement that VIP has L2 endpoint first of all? In my mind, the main reasons I would like to see the container object are: > > > - 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...") > > In fact, that can be solved by scheduling, without letting user to control that. Flavor Framework will be able to address that. > > - 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. > > That might be so, but apparently it goes in opposite direction than neutron in general (i.e. more abstraction) > > - 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. > - 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. > > I don't see how 'loadbalancer' is better than 'VIP' here, other than being a bit closer term to 'logical loadbalancer'. > > - 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. > > I don't see any problems with above cases if VIP is the root object > > - 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: > - "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. > - "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. > - "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. > - ...and so on. > > Right, that's how flavors are supposed to work, but that's again unrelated to whether we make VIP or loadbalancer our root object. > > - A logical load balancer object is a great demarcation point > <http://en.wikipedia.org/wiki/Demarcation_point> 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'.) > > That might be fine to have loadbalancer for admin API, but we're discussing tenant API right now. For admin API 'loadbalancer' could be direct representation of a backend. So what are the main arguments against having this container object? In > answering this question, please keep in mind: > > > - 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. > > I personally never used this as an argument. > > - > - 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. > > Right, there could be cases that more 'easily' solved by loadbalancer rather then other methods. Like aforementioned collocation problem. 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. Thanks, Eugene.
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
