Open Stack

Hi Stephen,

Please see my comments inline.


On Thu, Feb 13, 2014 at 5:19 AM, Stephen Balukoff <sbalukoff at bluebox.net>wrote:

> Hi y'all!
>
> I've been reading through the LoadBalancerInsance description as outlined
> here and have some feedback:
> https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance
>
> 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.)
>

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)


> 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)?
>

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')


> 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.
>

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.


> 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:
>
>
>    - 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.
>
> 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.

>
>    - 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.
>
> 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.

>
>    -
>    - 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.)
>
> 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.
And regarding allowing users to talk directly to a driver - that's a big
question. I think it can be desirable in some cases.
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.

And going back to HA, this is a common feature that needs to be introduced
into generic API.


>
>    - 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.
>
>  Yes, that makes sense and was discussed previously, but not implemented
so far.

>
>    -
>
> 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.
>
> Beyond this, other feedback I have:
>
>
>    - 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).
>
> That is something we need to evaluate. Currently we already have that with
the difference that pool is our 'loadbalancer object'.
Ability to share objects between appliances definitely makes sense, but I'm
not sure we need to address it right now.


>    - 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.)
>
> 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.

>
>    -
>    - 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).
>
>
> Thanks,
> Stephen
>
>
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.

Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140213/7b47a121/attachment.html>