incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohammed Morsi <mmo...@redhat.com>
Subject Re: Dynamic selection of driver
Date Fri, 12 Nov 2010 13:48:53 GMT
  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



Mime
View raw message