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