Mailing-List: contact dev-help@deltacloud.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@deltacloud.apache.org
Received-SPF: pass (nike.apache.org: domain of mandreou@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <5114DA7F.5000305@redhat.com>
Date: Fri, 08 Feb 2013 12:59:11 +0200
From: "marios@redhat.com" <mandreou@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: dev@deltacloud.apache.org
CC: David Lutterkort <lutter@redhat.com>
Subject: Re: [jira] [Closed] (DTACLOUD-443) Openstack Provider 'Availability
 Zones'
References: <JIRA.12629650.1359443913240@arcas>
  <JIRA.12629650.1359443913240.260811.1360252874401@arcas>
 <1360260071.3104.32.camel@melon.watzmann.net>
In-Reply-To: <1360260071.3104.32.camel@melon.watzmann.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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",
:versionId=>"1.1"}],

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

marios


[1]
http://docs.openstack.org/api/openstack-identity-service/2.0/content/POST_authenticate_v2.0_tokens_Admin_API_Service_Developer_Operations-d1e1356.html

[2]
https://github.com/ruby-openstack/ruby-openstack/commit/05d04aeec63b881efffaab467c7b9ecaa2e4ca6b


> David
> 
>