deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ronelle Landy (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DTACLOUD-488) Openstack driver - re-map regions to providers rather than realms
Date Wed, 20 Feb 2013 20:53:14 GMT

    [ https://issues.apache.org/jira/browse/DTACLOUD-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582511#comment-13582511
] 

Ronelle Landy commented on DTACLOUD-488:
----------------------------------------

Please see: https://issues.apache.org/jira/browse/DTACLOUD-477?focusedCommentId=13582508&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13582508

This worked partially as expected - but did not solve DTACLOUD-477. 
 - I could pass  the region string as the provider:

 ./bin/deltacloudd -i openstack -P "https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/;az-2.region-a.geo-1"

 - When doing  GET on /api, the correct supported collection were returned - ie; only storage
for region-a.geo-1.

 - All regions were returned:

 curl -X GET --user "un:pw" "http://localhost:3001/api/drivers/openstack?format=xml"

<driver href='http://localhost:3001/api/drivers/openstack' id='openstack'>
  <name>Openstack</name>
  <provider id='region-a.geo-1'>
    <entrypoint kind='region-a.geo-1'>https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/;region-a.geo-1</entrypoint>
  </provider>
  <provider id='az-2.region-a.geo-1'>
    <entrypoint kind='az-2.region-a.geo-1'>https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/;az-2.region-a.geo-1</entrypoint>
  </provider>
  <provider id='az-1.region-a.geo-1'>
    <entrypoint kind='az-1.region-a.geo-1'>https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/;az-1.region-a.geo-1</entrypoint>
  </provider>
</driver>

And realms are now returned as:

 curl -X GET --user "un:pw" "http://localhost:3001/api/realms?format=xml"
<?xml version='1.0' encoding='utf-8' ?>
<realms>
  <realm href='http://localhost:3001/api/realms/default' id='default'>
    <name>default</name>
    <state>AVAILABLE</state>
    <limit><![CDATA[ABSOLUTE >> Max. Instances: 20 Max. RAM: 102400   ||]]></limit>
  </realm>
</realms>


- 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 not.

 - But as far as the comments in DTACLOUD-477 show, I don't think we have teased out realms
vs. providers just yet, at least  as far as instances are concerned.
                
> 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