<div dir="ltr">Hi Stephen,<div><br></div><div>Please see my comments inline.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 5:19 AM, 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: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">Hi y'all!<div><br></div><div>I've been reading through the LoadBalancerInsance description as outlined here and have some feedback: <a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance" target="_blank">https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance</a></div>
<div><br></div><div>First off, I agree that we need a container object and that the pool shouldn't be the object root. This container object is going to have some attributes associated with it which then will apply to all related objects further down on the chain. (I'm thinking, for example, that it may make sense for the loadbalancer to have 'network_id' as an attribute, and the associated VIPs, pools, etc. will inherit this from the container object.)</div>
</div></blockquote><div> </div><div>Particularly, network_id could be different for vip and a pool in case the balancer works in routed mode (e.g. connects to different networks)</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><br></div><div>One thing that was not clear to me just yet: Is the 'loadbalancer' object meant, at least eventually, to be associated with an actual load balancer device of some kind (be that the neutron node with haproxy, a vendor appliance or a software appliance)?</div>
</div></blockquote><div> </div><div>Yes, that is one of the proposed roles of 'loadbalancer' object. But not the only. Appliance is not the only representation of the balancer that we are working with, it could also be a process on the host that is controlled by the agent. So other types of associations also are necessary (like association between the agent and the '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><br></div><div>If not, then I think we should use a name other than 'Loadbalancer' so we don't confuse people. I realize I might just be harping on one of the two truly difficult problems in software engineering (which are: Naming things, cache invalidation, and off-by-one errors). But if a 'loadbalancer' object isn't meant to actually be synonymous with a load balancer appliance of some kind, the object needs a new name.</div>
</div></blockquote><div> </div><div>I don't mind to have other name like 'instance', for example. But appliance (would it be a device or a process+agent) is really a synonym of what I am proposing. </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><br></div><div>If the object and the device are meant to essentially be synonymous, then I think we're starting off too simplistic here, and the model proposed is going to need another significant revision when we add additional features later on. I suspect we'll be painting ourselves into a corner with the LoadBalancerInstance as proposed. Specifically, I'm thinking about:</div>
<div><br></div><div><ul><li>Operational concerns around the life cycle of a physical piece of infrastructure. If we're going to replace a physical load balancer, it often makes sense to have both the old and new load balancer defined in the system at the same time during the transition. If you then swap all the VIPs from the old to the new, suddenly all the child objects have their loadbalancer_id changed, which will often wreak havoc on client application code (who really shouldn't be hard-coding things like loadbalancer_id, but will do so anyway. :P ) Such transitions are much easier accomplished if both load balancers can exist within an overarching container object (ie. "cluster" in my proposal) which will never need to be swapped out.<br>
</li></ul></div></div></blockquote><div>I'd like to understand that better. I guess no model is complex enough to describe each end every use case. What I'm trying to address with the lb instance is both simplistic cases that are only supported by the current code plus some more complex configurations like multiple pools (L7) and multiple vips. And at the same time we need to consider backward compatibility and plus we need to make some progress. The bigger is the change, the harder it is to make a progress. So we need to find an iterative way of increasing API and model complexity.</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><ul><li>Having tenants know about loadbalancer_id (if it corresponds with physical hardware) feels inherently un-cloud-like to me. Better that said tenants know about the container object (which doesn't actually correspond with any single physical piece of infrastructure) and not concern themselves with physical hardware.<br>
</li></ul></div></div></blockquote><div>Having loadbalancer_id has nothing to do with the appliance or particular backend, so that even might not give any clue to a tenant about the backend type. However, tenant may want to know something about the backend and he/she may want to use the single appliance for their needs (due to quotas, billing or topology limitations), and that's where loadbalancer_id helps to envelop resources and group them to just one (some!) physical backend.</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><ul><li><br></li><li>In an active-standby or active-active HA load balancer topology (ie. anything other than 'single device' topology), multiple load balancers will carry the same configuration, as far as VIPs, Pools, Members, etc. are concerned. Therefore, it doesn't make sense for the 'container' object to be synonymous with a single device. It might be possible to hide this complexity from the model by having HA features exist/exposed only within the driver, but this seems like really backward thinking to me: Why shouldn't we allow API-based configuration of load balancer cluster topology within our model, or force clients to talk to a driver directly for these features? (This is one of the hack-ish work-arounds I alluded to in my e-mail from Monday which is both annoying and corrected with a model which can accurately reflect the topology we're working with.)<br>
</li></ul></div></div></blockquote><div>HA is a valid question, and HA is definitely not represented by two different loadbalancer configurations. It is a property of one instance. Remember that loadbalancer and all its child objects are logical config, it could be deployed in HA or in single mode, depending on user's choice and driver capabilities. </div>
<div>And regarding allowing users to talk directly to a driver - that's a big question. I think it can be desirable in some cases.</div><div>You know, lb appliances nowadays can make cookies and fly to space and I'm not sure we want all that in the generic lb API, but that could be provided via specific extensions. Even in a public cloud case, where you want your tenants to be completely unaware of the backend, it's still possible that there are some tenants with specific demands (willing to pay) where more control could be useful. </div>
<div><br></div><div>And going back to HA, this is a common feature that needs to be introduced into generic API.</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><ul><li>Side note: It's possible to still have drivers / load balancer appliances which do not support certain types of HA or auto-scaling topologies. In this case, it probably makes sense to add some kind of 'capabilities' list that the driver publishes to the lbaas daemon when it's loaded.<br>
</li></ul></div></div></blockquote><div> Yes, that makes sense and was discussed previously, but not implemented so far.</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><ul><li>
</li></ul></div><div>So, I won't elaborate on the model I would propose we use instead of the above, since I've already done so before. I'll just say that what we're trying to solve with the LoadBalancerInstance resource in this proposal can also be solved with the 'cluster' and 'loadbalancer' resources in the model I've proposed, and my proposal is also capable of supporting HA and auto-scaling topologies without further significant model changes.</div>
<div><br></div><div>Beyond this, other feedback I have:</div><div><br></div><div><ul><li>I don't recommend having loadbalancer_id added to the pool, member, and healthmonitor objects. I see no reason a pool (and its child objects) needs to be restricted to a single load balancer (and it may be very advantageous in large clusters for it not to be).<br>
</li></ul></div></div></blockquote><div>That is something we need to evaluate. Currently we already have that with the difference that pool is our 'loadbalancer object'.</div><div>Ability to share objects between appliances definitely makes sense, but I'm not sure we need to address it right now.</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><ul><li>I general, I prefer DRY code, so if we can avoid adding the loadbalancer_id attribute to existing resources except for where it's really needed, that's what I'd recommend. (Do we expect significant savings by repeating this attribute in various locations and avoiding one SQL query? It seems to me we're inviting annoying bugs we'll have to work out by having that field essentially act as a cache for the authoritative source of information-- ie. the load balancer (cluster) object itself.)<br>
</li></ul></div></div></blockquote><div>Well, DRY principle is good, but save on sql queries is good also, because the more queries we do, the more are the chances of different races, not to say that it could just eat up a bit of performance if DB is large enough. </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><ul><li>
<br></li><li>Having loadbalancer_id (cluster_id in my model) an attribute of the VIP makes sense. I can't think of any reason a given VIP would be associated with multiple load balancer (clusters).<br></li></ul></div>
<div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,</div><div class="gmail_extra">Stephen</div><div class="gmail_extra"><br></div></div></div></blockquote><div><br></div><div>One of the important properties of proposed loadbalancer object is not just another entity of API, but also a helper object for various coding problems that mostly don't affect API consumers.</div>
<div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div></div></div></div>