Mailing-List: contact deltacloud-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltacloud-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of lutter@redhat.com designates
 209.132.183.28 as permitted sender)
Subject: Re: Dynamic selection of driver
From: David Lutterkort <lutter@redhat.com>
To: deltacloud-dev@incubator.apache.org
In-Reply-To: <5BD04FB9-4D97-4F3E-88CA-99BFD0726791@jaguNET.com>
References: <1289524884.4164.1312.camel@avon.watzmann.net>
	 <5BD04FB9-4D97-4F3E-88CA-99BFD0726791@jaguNET.com>
Content-Type: text/plain; charset="ISO-8859-15"
Organization: Red Hat Inc
Date: Mon, 15 Nov 2010 16:49:34 +0100
Message-ID: <1289836174.12245.62.camel@melon.watzmann.net>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Fri, 2010-11-12 at 09:29 -0500, Jim Jagielski wrote:
> On Nov 11, 2010, at 8:21 PM, 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.
> > 
> 
> Sounds good, but shouldn't there be some sort of auth mechanism
> to "verify" that an authorized entity set those headers?

I don't think that's necessary - since the Deltacloud server doesn't
store any credentials, the user also needs to include their credentials
with the request (as a HTTP basic auth header)

ASAICT, worst case, they have invalid credentials, and the only attack
they could launch is DOS either on the Deltacloud server (which they
could in any case) or on the backend cloud (which they also can do w/o
Deltacloud)

David