On Dec 15, 2010, at 7:44 PM, David Lutterkort wrote:
> On Tue, 2010-12-14 at 23:06 -0500, Toby Crawley wrote:
>> On 12/14/2010 08:00 PM, David Lutterkort wrote:
>>> On Fri, 2010-12-10 at 08:06 -0500, [email protected] wrote:
>>>> From: Tobias Crawley<[email protected]>
>>>>
>>>> The provider can now be set on the commandline to deltacloudd via
>>>> -P/--provider
>>>> (putting it in ENV['API_PROVIDER']), and also from the client via a header
>>>> (putting it in Thread.current[:provider]).
>>>>
>>>> The ec2 driver is currently the only driver that understands providers, and
>>>> looks in Thread.current[:provider], then ENV['API_PROVIDER'], then falls
>>>> back
>>>> to a default (currently 'us-east-1', the AWS default).
>>>
>>> Sorry for being late to the party; the word 'provider' seems very
>>> unclear to me. In addition, the driver does some scary URL surgery that
>>> seems less than robust to me.
>>>
>>> I'd prefer if we rename this mechanism into 'endpoint' (and
>>> ENV['API_ENDPOINT']) with the expectation that the entire URL that we
>>> should talk to is passed in. With that, it also becomes possible to use
>>> the EC2 driver against a private Eucalyptus instance.
>>
>> I'm not attached to 'provider', and would be fine calling it 'endpoint'.
>
> The main thing I wanted to convey with the name change is that the value
> of the parameter is the URL for the backend cloud - I don't think that
> using a keyword will work for other backends (like RAX and OpenStack)
>
> But you are right - AWS has made quite a mess of this, and for AWS we
> will need to use a keyword rather than an actual URL, and map that
> keyword to the actual endpoint URL for EC2, S3 and ELB.
>
> So, for naming: the name should remain API_PROVIDER; we'll have to
> document the right values for it for each driver separately.
I jumped the gun a bit, and submitted a patch yesterday that changed 'provider'
to 'endpoint', and added a lookup table for the default endpoints. I'll fix
that and submit a new patch.
>
>> If we do keep the endpoint as simply the region name (or allow it to be a
>> url or region name), then maybe this would be better implemented
>> as a simple lookup table:
>>
>> EC2_ENDPOINTS = {
>> :ec2 => {
>> 'us-east-1' => 'ec2.us-east-1.amazonaws.com',
>> ...
>> },
>> :s3 => {
>> 'us-east-1' => 's3.amazonaws.com',
>> 'eu-west-1' => 's3.amazonaws.com',
>> 'ap-southeast-1' => 's3-ap-southeast-1.amazonaws.com',
>> ...
>> },
>> ...
>> }
>
> That seems to me the best solution - with a proper error message when
> nonsense is passed in for API_PROVIDER (like API_PROVIDER=eu-east-1)
Yesterday's patch just attempts to use the provider as an endpoint if it is not
found in the lookup table. I'll add a TODO comment there for now about raising
an error, and think about the best way to do that.
>
> For S3, there's a few gotchas: (1) there's no us-east-1; we should just
> map the US Standard zone to us-east-1 (2) the request to S3 must set the
> location constraint corresponding to the endpoint.
The lookup table for s3 currently has:
's3' => {
'ap-southeast-1' => 's3-ap-southeast-1.amazonaws.com',
'eu-west-1' => 's3.amazonaws.com',
'us-east-1' => 's3.amazonaws.com',
'us-west-1' => 's3-us-west-1.amazonaws.com'
}
But I think the right thing to do is always use s3.amazonaws.com, no matter
what the requested provider - there is no requirement to use a region specific
endpoint like there is for the other AWS services. The bucket/blob code already
has a provision for setting the location constraint per request, so we don't
need to deal with that with the provider code.
I'll make this change as well, and submit a new patch set.
>
> David
>
>
---
Toby Crawley
[email protected]
