[
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
