deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toby Crawley <>
Subject Re: [PATCH core] Allow setting the provider on the server side, and implement region overriding in the ec2 driver based off of the provider (rev 2).
Date Wed, 15 Dec 2010 04:06:34 GMT
On 12/14/2010 08:00 PM, David Lutterkort wrote:
> On Fri, 2010-12-10 at 08:06 -0500, wrote:
>> From: Tobias Crawley<>
>> 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 issue with passing in a url instead of just region name (in the ec2 case) is that each
client (user) application would have to have code 
to construct the url, and would have to pass a different url to use different services - one
with ec2 calls, a different one with elb calls, 
and yet another one for s3 calls (the code below doesn't include the logic to construct s3
urls - that's needed for the new bucket support 
in the new ec2 driver. See [1] for all the different service/region urls for ec2). This would
require the user code to know which endpoint 
to request for each call, which would not always be obvious. For the case where the the dc
core is configured to work against one 
driver/endpoint and driver/endpoint overriding is not used, it would still need to be configured
with three different endpoint urls somehow. 
Figuring out the correct url really belongs in the gem that connects to aws. The 'aws' gem
itself may have the logic to figure them out - 
I'll have to check and see.

In the Eucalyptus case, it may be a better idea to actually have a euca_driver that extends
ec2_driver, with the euca driver overriding any 
bits it needs to. It could then have its own logic for constructing urls, with any data needed
to construct the endpoint defined in 
API_ENDPOINT and friends.

Another option is to allow the endpoint to be a region, which we use it to create/discover
a url, or a url that we use outright. That would 
allow the ec2 driver to be simple enough to use when talking to ec2, and be able to talk to
euca without too much modification (we would 
still need some way to specify to the 'static' driver/endpoint dc core the endpoint for each
service, if euca expects that).

>> +  def endpoint_for_service(service)
>> +    url = ""
>> +    url<<  case service
>> +           when :ec2
>> +             'ec2.'
>> +           when :elb
>> +             'elasticloadbalancing.'
>> +           end
>> +    url<<  (Thread.current[:provider] || ENV['API_PROVIDER'] || DEFAULT_REGION)
>> +    url<<  ''
>> +    url
>> +  end
> This is the code I object to; and as I said, the URL surgery restricts
> unnecessarily how the EC2 driver can be used.

This code gets even more complicated when s3 is added to the mix:

   def endpoint_for_service(service)
     region = (Thread.current[:provider] || ENV['API_PROVIDER'] || DEFAULT_REGION)
     append = true
     url = ""
     url << case service
            when :ec2
            when :elb
            when :s3
              case region
              when 'us-east-1', 'eu-west-1'
                append = false
     url << region if append
     url << ''

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 => {
     'us-east-1' => '',
   :s3 => {
     'us-east-1' => '',
     'eu-west-1' => '',
     'ap-southeast-1' => '',


> David

View raw message