deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Lutterkort (JIRA)" <>
Subject [jira] [Commented] (DTACLOUD-488) Openstack driver - re-map regions to providers rather than realms
Date Thu, 21 Feb 2013 23:16:13 GMT


David Lutterkort commented on DTACLOUD-488:

rlandy wrote:
> - I am unsure if a user should be able to lunch an instance in one region using an image
from a different region. Didn't test this yet .Is that a legitimate scenario. My guess is

You are correct - there should be no interactions between regions (providers) For all intents
and purposes, they are completely different clouds.
> Openstack driver - re-map regions to providers rather than realms
> -----------------------------------------------------------------
>                 Key: DTACLOUD-488
>                 URL:
>             Project: DeltaCloud
>          Issue Type: Bug
>            Reporter: Marios Andreou
>            Assignee: Marios Andreou
>         Attachments: 0001-Deltacloud-OpenStack-driver-remap-regions-to-provide.patch,
> In DTACLOUD-443 [1] we introduced support for Openstack 'regions' - for when Openstack
service providers support different endpoints for services in different 'regions' in the serviceCatalog
returned after authentication. The initial and current mapping in Deltacloud is from  Openstack
'regions' to Deltacloud 'realms'. However, this has caused problems with the Openstack driver.
For example, when you list Instances - which region's Instances should be retrieved? Similarly,
when you create an Instance, if the client hasn't specified a 'realm_id' - which region should
the Instance be created in? A slightly more complex problem is that not all services are supported
in all regions - e.g. in the HPCloud Openstack deployment, region 
> "region-a.geo-1" exposes only the 'object-store' service, whereas region "az-2.region-a.geo-1"
exposes 'compute' and 'volume' services.
> A better solution IMO is to map 'regions' to 'providers'. This is what the attach patch
does. You can specify the provider (i.e. 'region') you'd like to use in the API_PROVIDER URL
- either when starting the deltacloud server or with the X-Deltacloud-Provider header in HTTP
requests [2]. For example - when starting the deltacloud server and with the Keystone service
@ "" and assuming you wish to manage resources in
region 'region-1a' you would use:
> deltacloudd -i openstack -P ";region-1a"
> When you specify a region for the openstack driver, the collections exposed after a request
to the Deltacloud entry point (e.g. /api) will only include those that are supported by the
specified region (e.g. only object-store (buckets) or only compute (instances, images, realms,
keys etc etc)). If you don't specify a region at all, but only provide the url for the keystone
authentication service, then you will see no difference to current behaviour; the first region
is picked from the returned serviceCatalog.
> Testing and comments please!
> marios
> [1]
> [2]

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message