If you go for four different types of backend as you propose, and each
has an associated config file, then it would be possible to use a single
SQL database to hold all the information, or a single writeable LDAP to
hold it all, with pointers to the same database in each config file.
Alternativ
OK, I think it makes sense. If we keep roles and role assignments in
the same place, we don't have the ability to do more complex
assignments. So the four backends would then be:
Domains
Identity (Users, groups)
Assignments (could also be called mapping)
Projects (Includes roles)
Assuming t
Hi Adam
I would propose splitting the backend into two conceptually distinct
types of attributes, and then each of these high level types can be
arbitrary split into different databases depending upon their sources of
authority and who administers them. Your proposal would be just one
special
Adam Young wrote:
> Currently, the Identity backend has Domains, Users , Groups, Roles,
> Role Assignments and Projects. I've proposed splitting it into 3
> distinct pieces. Domain, Identity, and Projects.
> [...]
I think it makes sense.
> The main blueprint for this is:
> https://blueprints.l
Sent: Monday, May 20, 2013 9:47 AM
To: openstack
Subject: [Openstack] [Keystone] Splitting the Identity Backend
Currently, the Identity backend has Domains, Users , Groups, Roles, Role
Assignments and Projects. I've proposed splitting it into 3 distinct pieces.
Domain, Identity, and Pro
Currently, the Identity backend has Domains, Users , Groups, Roles,
Role Assignments and Projects. I've proposed splitting it into 3
distinct pieces. Domain, Identity, and Projects.
Here is the rationale:
Somewhere between a third and a half of the OpenStack deployments are
using LDAP. Ho
6 matches
Mail list logo