[Engine-devel] What type of DB inheritance to use?
Federico Simoncelli
fsimonce at redhat.com
Mon May 13 23:07:31 UTC 2013
----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, May 13, 2013 9:46:48 AM
> Subject: Re: [Engine-devel] What type of DB inheritance to use?
>
> On 05/13/2013 10:42 AM, Oved Ourfalli wrote:
> > IMO, the following fields will fit most providers, at least the ones we
> > plan to support in the near future:
> > * id
> > * name
> > * type
> > * URL
> > * requires_authentication (boolean) to support development/POC/testing...
> > mode
>
> redundant with empty username/password?
>
> > * username
> > * password
>
> do keystone based services allow to authenticate directly to them, or
> you need an additional authentication url (to get the ticket)?
You need the ticket, but we said that the keystone service (auth url, username
and password) are config values for the time being. Anyway in the future I expect
these providers to be linked to their keystone service. E.g.:
id name username password url auth_provider tenant ...
1 keystone1 myuser mypass http://keystone <null> <null>
2 glance1 <null> <null> http://glance 1 mytenant1
3 glance1 <null> <null> http://glance 1 mytenant2
4 quantum1 <null> <null> http://quantum 1 mytenant1
I expect quantum to be needing the tenant name too (as soon as it will be
integrated with keystone).
Given the username/password (created for the ovirt management), the user can
be added to the tenants (all the ones that the admin wants to consume) and
then ovirt will get the auth tokens with the relevant info, e.g. (pseudocode
with reference to the table above):
keystone = new Keystone("http://keystone");
glance1_token = keystone.authenticate("myuser", "mypass", "mytenant1");
glance2_token = keystone.authenticate("myuser", "mypass", "mytenant2");
quantum1_token = glance1_token;
glance = new Glance("http://glance", glance1_token);
glance.listImages();
....
--
Federico
More information about the Devel
mailing list