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] [Commented] (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:comment-tabpanel&focusedCommentId=13584450#comment-13584450
] 

Marios Andreou commented on DTACLOUD-488:
-----------------------------------------

pushed with commit # be1842b8cc67abd0d50f5815200ebe165db7e7ac d020637148e4f85b4a01dd17779d99680eb7ee83
                
> 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