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] [Updated] (DTACLOUD-443) Openstack Provider 'Availability Zones'
Date Fri, 01 Feb 2013 17:20:12 GMT

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

Marios Andreou updated DTACLOUD-443:
------------------------------------

    Attachment: 0001-Deltacloud-adds-maps-openstack-regions-to-deltacloud.patch

OK - thanks for your comments Christian - we are pretty much on the same page with how the
'regions' is implemented on the rubygem side - see https://github.com/ruby-openstack/ruby-openstack/pull/19
- in so much as I 'flag' each 'region' with the list of supported services.

On the deltacloud side, I re-wrote the 'realms' method to give a list of openstack regions.
I added the 'service_types' attribute to the Realm model - to include the info about supported
services. The two points we diverge on are:

1. "Due to this, when requesting for example all instances, you have to loop through all realms
and merge the subsets"

==> I think this should work in the same way as other drivers - i.e. you get a list of
resources in the current 'realm'. I feel this is also the same as talking directly to the
openstack service (e.g. using the rubygem) - you get a connection to a specific realm and
then you can work with your resources within that.

==> HOWEVER, this then leaves the problem of 'how do I specify which realm I want to manage?';
for this I've (tentatively) decided to extend the API_PROVIDER string. Currently we use API_PROVIDER
to hold the Keystone authentication URL... like:

deltacloudd -i openstack -P "https://region-b.geo-1.identity.hpcloudsvc.com:35357/v2.0/"

or even in a request you can specify the auth_url with the X-Deltacloud-Provider header. My
'solution' is to add a "::regionId" to the end of the auth_url... so to get a list of all
Instances in region "az-2.region-a.geo-1"

curl --user "user:password" -H "X-Deltacloud-Provider: https://region-b.geo-1.identity.hpcloudsvc.com:35357/v2.0/::az-2.region-a.geo-1"
http://localhost:3001/api/instances

To launch an instance in a particular realm, you can just use the (pre-existing) 'realm_id'
parameter...


2. "Another point is, that for HP Cloud different authentication servers have to be queried
to get a list of _all_ regions. "

===> Not sure what you meant here - I see that HPCloud does provide 2 URIs for the Identity
service but afaics they both return the same regions - unless i missed something...


so, what do you think? can it work?  You will need to build the gem from my fork at https://github.com/marios/ruby-openstack
to try this out,

thanks for your help, marios
                
> Openstack Provider 'Availability Zones'
> ---------------------------------------
>
>                 Key: DTACLOUD-443
>                 URL: https://issues.apache.org/jira/browse/DTACLOUD-443
>             Project: DeltaCloud
>          Issue Type: Improvement
>            Reporter: Marios Andreou
>            Assignee: Marios Andreou
>         Attachments: 0001-Deltacloud-adds-maps-openstack-regions-to-deltacloud.patch
>
>
> (from Christian Karnath, via e-mail):
> Hey Marios,
> HPCloud provides three different compute clouds (availability zones) at the moment. How
can I specify which compute cloud is used with the openstack driver, because the API credentials
and the URL endpoint of the identity service (keystone) are the same. Connecting and authenticating
directly to the nova-api of a specific compute cloud is not possible, because HPCloud is using
keystone as a centralized identity management solution.
> I guess when authentication against the identity service all three compute clouds are
returned, but only the first cloud is manageable with deltacloud? Would it make sense to re-implement
/api/realms for this case? The current /api/realms implementation could be retained for users
who are connection directly to a specific nova api endpoint (i. e. an openstack environments
without keystone).
> Best
> Christian

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