deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marios Andreou (JIRA)" <>
Subject [jira] [Commented] (DTACLOUD-443) Openstack Provider 'Availability Zones'
Date Thu, 31 Jan 2013 17:11:13 GMT


Marios Andreou commented on DTACLOUD-443:

Hi Christian:

fyi - I've started looking at this. I've been playing with the rubygem against the hp cloud
regions... For now I'm looking to add a couple of calls to the rubygem itself - to get a list
of regions. My aim is to replace 'limits' <==> 'Deltacloud Realms' with the 'regions'
<==> 'Deltacloud Realms' as it makes more sense in my mind.  

I'm linking this issue with DTACLOUD-446... as I said I'd rather avoid having a separate driver
just for hp cloud. If we add the ability to choose/specify realms, e.g. when creating a server
resource, in a similar manner to how realms are used in other drivers (like ec2 for example)
then in my mind this would counter the argument for a separate driver even more. What we *could*
do is define a new flag for setting up the endpoints - like 'deltacloudd -i openstack:hp for
example and have the auth endpoints defined in some yaml file); but let's take them one at
a time. I'll keep looking at this tomorrow.

thanks! marios
> Openstack Provider 'Availability Zones'
> ---------------------------------------
>                 Key: DTACLOUD-443
>                 URL:
>             Project: DeltaCloud
>          Issue Type: Improvement
>            Reporter: Marios Andreou
>            Assignee: Marios Andreou
> (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:

View raw message