deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: [jira] [Closed] (DTACLOUD-443) Openstack Provider 'Availability Zones'
Date Fri, 08 Feb 2013 10:59:11 GMT
Hi David:

On 07/02/13 20:01, David Lutterkort wrote:
> Hi guys,
> I am very confused by what's been happening on this ticket. Can somebody
> explain what the differences between different Openstack providers and
> realms now is ?
> The way it should work is that different providers share nothing
> (different images, different instances, different everything) whereas
> realms are a further subdivision of one provider where a lot of things
> are shared (e.g., same list of images, GET /api/instances returns
> instances across all realms)
> What is the situation with Openstack now ? What's shared and what's
> separate for different providers (== different provider URL's) and
> different realms within the same provider ?

To connect/consume an Openstack service you need the URL for the
Keystone authentication service; this is the entry point from which
you'll get pointers to whichever services you are authorized for. For
the Deltacloud Openstack driver we call this URL the "Provider URL" -
assigned to API_PROVIDER.

Openstack has support for regions - when you get the service catalogue
after authentication, a number of endpoints can be returned for a given
service type [1]. This could be different versions of a service in the
same region or in different regions.

As part of DTACLOUD-443 - I decided to map 'regions' to Deltacloud
'Realms'. I first added the list of regions with their services to the
Openstack rubygem [2] connection object. Within deltacloud and after
authentication against Keystone this allows you to:

  os = new_client(credentials)
  regions = os.connection.regions
  ==>  {"region-a.geo-1" => [ {:service=>"object-store",
:versionId=>"1.0"}, {:service=>"identity", :versionId=>"2.0"}],

      "region-b.geo-1"=>[{:service=>"identity", :versionId=>"2.0"}],

      "az-2.region-a.geo-1"=>[{:service=>"image", :versionId=>"1.0"},
{:service=>"volume", :versionId=>"1.1"}, {:service=>"compute",

      "az-1.region-a.geo-1"=>[{:service=>"image", :versionId=>"1.0"},
{:service=>"volume", :versionId=>"1.1"}, {:service=>"compute",
:versionId=>"1.1"}] }

I filter out the regions that the deltacloud driver isn't interested in
- i.e. those that don't offer "compute", "object-store" or "volume"
services. This list then gets converted to Realm objects.

The confusion between 'realm' and 'provider' I think in this case is
because to specify which region you'd like to manage infrastructure in -
we are using the "Provider URL" - by adding a ";region_id" to that. In
other words you can do:

  deltacloudd -i openstack -P "http://keystone.service.url/v2.0/;region1"

to specify region 1 for example. There still some stuff to work out. One
of the issues is the one you mention - when working with a particular
Openstack region, you should only see resources in that region - which
is what is now happening (the issue reporter for DTACLOUD-443 suggested
that we should list all intances across regions for example). However,
what if a client doesn't specify a region? In this case the openstack
rubygem just grabs the first endpoint - whichever that is.

An alternative is to remove the "region" <==> "realm" mapping and make
it "region" <==> "provider" - however this would require that a client
knows which regions a openstack service provider has (i.e. you need to
pass the region_id together with the Keystone auth_url). Implementing it
in the way I have means a client can get the realms collection and
discover the ids of the regions.




> David

View raw message