deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marios Andreou (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (DTACLOUD-488) Openstack driver - re-map regions to providers rather than realms
Date Fri, 22 Feb 2013 17:16:13 GMT

     [ https://issues.apache.org/jira/browse/DTACLOUD-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Marios Andreou resolved DTACLOUD-488.
-------------------------------------

    Resolution: Fixed
    
> Openstack driver - re-map regions to providers rather than realms
> -----------------------------------------------------------------
>
>                 Key: DTACLOUD-488
>                 URL: https://issues.apache.org/jira/browse/DTACLOUD-488
>             Project: DeltaCloud
>          Issue Type: Bug
>            Reporter: Marios Andreou
>            Assignee: Marios Andreou
>         Attachments: 0001-Deltacloud-OpenStack-driver-remap-regions-to-provide.patch,
0002-Deltacloud-remove-unused-resource_types-attribute-fr.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
@ "https://keystone.service.org:35357/v2.0/" and assuming you wish to manage resources in
region 'region-1a' you would use:
> deltacloudd -i openstack -P "https://keystone.service.org:35357/v2.0/;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] https://issues.apache.org/jira/browse/DTACLOUD-443
> [2] http://deltacloud.apache.org/drivers.html

--
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: http://www.atlassian.com/software/jira

Mime
View raw message