On 11/12/2010 04:32 AM, Michal Fojtik wrote:
On 12/11/10 01:21 +0000, David Lutterkort wrote:
Hi,
Toby Crawley is really the one who brought this up - here's a summary of
a discussion we had a couple days ago.
Right now, the deltacloud server only ever uses one driver; that means
that if you want to talk to multiple clouds, you need to have one
deltacloud server running for each of them. Clearly, not very admin
friendly.
Toby actually experimented with this (wanna share your patch, Toby ?).
To me, the cleanest way to enable dynamic selection of the driver is to
select the driver through add'l HTTP headers. For example, by sending
X-Deltacloud-Driver: ec2
X-Deltacloud-Endpoint: https://eu-west-1.ec2.amazonaws.com/
you'd be using the eu-west region of EC2.
We would maintain the current behavior of the driver as the default when
these headers are absent; so if you start 'deltacloudd -i mock', clients
that don't set the Deltacloud headers will talk to the mock driver.
I like this idea!. +1 from /me.
-- Michal
Yes very good idea. +1 (never really liked the idea of having to launch
a bunch of core processes listening on different ports).
Also something else which I think would be appreciated by regular end
users is a combined client/server utility. Something which a user could
use to control a cloud provider without having to launch a core server.
They would checkout deltacloud core (or install it from the gem or rpm)
and just run deltacloud-embed (better name needed?) which launches a
server instance and communicates w/ it internally via the client
interface for a one-off operation. This would be the simplest / most
trivial deltacloud use case and I don't think implementing it would be
too bad either as we would just pull in the relevant bits from
deltacloudd and deltacloudc and write a very thin wrapper, though
performance might need to be optimized as the server currently takes a
few seconds to come up. Thoughts?
-Mo
