deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Koper, Dies" <>
Subject RE: load balancers with FGCP
Date Sat, 18 Aug 2012 08:04:23 GMT
> > 1. As load balancers are a type of server instances in the FGCP,
> > are returned in the list of instances and can be started, stopped
> > removed from there.
> Is it desirable to expose the load balancer in this way ? Could we
> suppress load balancer instances in the instances list ?

That is a good question, which does not apply only to load balancers.
I should have brought this up with the initial fgcp driver
implementation but there were so many bigger issues at the time :)

Technically we can definitely supress them. But load balancers need to
be started before they can be configured, so if we supress them in the
instance list we need start and stop operations elsewhere.

The FGCP api to list instances returns two types of instances. "normal"
instances and "built-in" instances. Currently two types of "built-in"
instances are supported, firewalls and load balancers. I decided at the
time to include all in the instances list.
Most operations and attributes on the built-in instances are the same as
normal instances: they can be started, stopped and destroyed, they have
an id, name and private IP address. 
The creation operation is different in the fgcp api: the load balancer
creation option only takes a name and realm, it is not created from an
image. The fgcp api has no operation to create a firewall, rather
creates one automatically when creating a system. It takes a name and
system template descriptor id (which defines whether the system gets a
1, 2 or 3 tier network).

So what I've done is to map DC's firewall creation operation to FGCP's
system creation method. The user would then go to the instances list to
find the firewall instance and start it. Operations such as allocating
and mapping public IP addresses depend on the FW to be running. In fact,
you can't even start a "normal" instance in a system realm unless the FW
is running, so having them in the same list is convenient.

I'd like to do the same for the load balancer: the load balancer is
created using DC's equivalent operation, the user would then go to the
instances list to find it and start it.

> >  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
> 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
> client repeats its request, we pick up the LB creation if it still
> to be done)

I will look into that. What HTTP error code would fit that situation?
269 Call Back Later?

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

Yes, I should be able to map all groups to DC LBs.

> > 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
> > parameter. If supported by the provider and specified, it overrides
> > value of the load balancer's 'instance port' field. If not
> > the value of already configured instances is used (and if there
> > 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

Yes, ideally I'd see both the existing listener_instance_port and the
one I'm requesting to be advertised features as fgcp only supports the
one and ec2 only the other.

> it. This is so that we do not have to store data when the LB is set
> and use that when an instance is registered to the LB, right ? Is

Right. I don't want to store that data on DC's side and on FGCP's LB (or
LB group) there are no attributes I can use of abuse (not even a
'description' field) to store a port number.

> some way to avoid that, since it constitutes API breakage ?

The API breakage being to make the current listener_instance_port
attribute a feature?
I'm not sure how that could cause any impact, systems that have used it
so far would continue to work, wouldn't they?

> > 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
> > change that page to:
> > 1. only list the instances in the same realm(s) as the load
> > 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.


So to summarise the current status of the change request:

1. DC LB API will include a new feature to add a port number to the
operation to add an instance to a LB listener.
2. DC LB UI will offer the user a field to enter that port number when
adding an instance to a LB.
3. FGCP will implement and advertise the above feature and all other
functionality described in this e-mail.


View raw message