deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <lut...@redhat.com>
Subject RE: load balancers with FGCP
Date Wed, 22 Aug 2012 00:35:53 GMT
On Sat, 2012-08-18 at 18:04 +1000, Koper, Dies wrote:
> > > 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 ?
> 
> 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.

Can we handle the start/stop transparently ? IOW, API users do not need
to know that LB's need to be started explicitly, we start them for them
when they are needed, and stop them when they are not balancing anything
anymore.

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

My problem with this is that LB's can only be used then if the user
knows to start some special instance - with that, the FGPC driver will
behave differently from other drivers.

> > >  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)
> 
> I will look into that. What HTTP error code would fit that situation?
> 269 Call Back Later?

Heh .. for example; I would use 502 Bad Gateway or 504 Gateway Timeout,
unless the failure from FGCP gives us an indication that something else
went wrong that would explain things better to the user (e.g., if FGCP
gives us ome other 5xx code)

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

Is there _anything_ we could abuse for storage ?

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

Only if they don't rely on DC being cross-cloud and try to set a
listener_instance_port on FGCP.

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

I believe so ;)

David



Mime
View raw message