Hi Dies, On Wed, 2012-08-15 at 18:57 +1000, Koper, Dies wrote: > I've been looking at how to map the load balancer API to FGCP's load > balancer concept better. > > Let me first briefly explain the load balancer concept in the FGCP. > In the FGCP a load balancer module is provided as a 'built-in server'. > I.e. you create one in a similar way as a server instance, need to start > it before you can configure it, it is assigned its own private IP > address and you can map one (or more) public IP addresses to it. > Once running, you can create groups, each having a source port and > protocol (and a few more settings, such as distribution method > (round-robin or least number of connections), service monitoring method > (ping or tcp), consistency guarantee method (source IP, connection, > cookie/url or cookie client id insertion), etc.). > To each group you can add listeners, which consist of a destination > server instance and server instance port each. > > So the main differences to the DC API are: > > 1. load balancer needs to be created first, then started, then > configured. Can't create & configure in a single step. > 2. FGCP load balancer can have multiple groups, each with its own listen > port and protocol, instead of just one. > 3. The instance destination port is specified per instance, not per load > balancer. > > This is how I think we can address them: > > 1. As load balancers are a type of server instances in the FGCP, they > are returned in the list of instances and can be started, stopped and > removed from there.
Is it desirable to expose the load balancer in this way ? Could we suppress load balancer instances in the instances list ? > For the create & configure operation, the best I can > do is create if not already created, and configure if created and > running. Yes, I agree. As long as the operation is idempotent (i.e., if you make a call to DC to create a LB, and some of the intermediate steps of creating/configuring fail, we kick back an error to the client; when the client repeats its request, we pick up the LB creation if it still needs to be done) > 2. Instead of mapping a DC load balancer to an FGCP load balancer, I > think I can map a DC load balancer to an FGCP load balancer group. That > solves the single versus multiple listen ports and protocols issue. What will we do with additional groups that people might have created outside of DC ? Will they just get mapped to different DC LB's ? > 3. For this one I'd like to request a change/addition to the DC API: > a. the operation to register an instance has an optional 'instance port' > parameter. If supported by the provider and specified, it overrides the > value of the load balancer's 'instance port' field. If not specified, > the value of already configured instances is used (and if there aren't > any, the same value as the load balancer port). Makes sense to me - this should be advertised as a feature. > b. the current listener_instance_port field becomes optional for > providers that don't support it. It sounds more to me that what you want is that the listener_instance_port is not supported for providers that don't support it. This is so that we do not have to store data when the LB is set up, and use that when an instance is registered to the LB, right ? Is there some way to avoid that, since it constitutes API breakage ? > In additional to the above, I'd have an rfe for the UI: > The register instance page in the UI lists all instances. I'd like to > change that page to: > 1. only list the instances in the same realm(s) as the load balancer. > 2. add a way for the user to enter the instance port number. Both sensible, (2) of course would only show up if the appropriate feature is supported by the backend. David
