Open Stack

Adam,

So first off, I think we need to a little careful in the into to this (for instance there is no such thing as a grant of a group to a user, which you imply), rather today we have two concepts:

membership, of which examples are:
- projects, users and groups are members of domains
- user are members of groups
- (as a hangover from previous versions) users can be members of tenants, but there is no explicit api interface for this anymore

grants, of which examples are:
- grant role X to user Y on project Z
- grant role A to group B on domain C

Now I can imagine some immediate collapsing of some f these, e.g.:

a) You could have a single grant table that had role, actor, target as columns that could store all grants (since all IDs are unique)
b) You could, as discussed, map the legacy user<->tenant membership into this same table with the role as "legacy_tenant_membership" or something

Beyond that, I think we are in danger of trying de-normalise the relationship of various tables into one mega relationship which may cause more confusion than it gains.

Just my 2cents

Henry
On 23 Jan 2013, at 19:31, Adam Young wrote:

> As I try and rework "roles mean membership" https://review.openstack.org/#/c/20278/  I am struct by the fact that the grants calls all are common regardless of whether they are group to user, group to domain, or what not.
> 
> It seems to me that we could take this abstraction further, and make groups, domains, and projects all a single SQL entity called a collection, and put it into a single table.  Then, role assignments are associations between collections.  Each user would get an entry in the collections table as well.
> 
> The table would basically be the projects table outline:
> 
>    __tablename__ = 'collection'
>    id = sql.Column(sql.String(64), primary_key=True)
>    parent_id = sql.Column(sql.String(64), sql.ForeignKey('collection.id'), nullable=False )
>    name = sql.Column(sql.String(64), unique=True, nullable=False)
>    description = sql.Column(sql.Text())
>    enabled = sql.Column(sql.Boolean)
>    power_type = sql.Column(sql.Int)  #use ENUM type if all RDBMS support it
> 
> power_type would be 0=user, 1=project,2=domain,3=group
> 
> The user  table will still remain.  Think of the groups of type = 0 as groups as done in /etc/groups.
> 
> I would actually prefer to call this the 'group' table instead of the collection table, if we can somehow deconflict the term with the way that keystone is presently using group.  I think  "rolegroup" is a better term.
> 
> This will allow us to come up with other collection types in the future without having to write a whole new set of tables. It should reduce duplicated code.
> 
> Domains will have a null parent_id. Users,  (role)groups, and projects will have a domain as their parent.
> 
> I don't think this will impact the LDAP backend, except to reinforce that the groupings should all be done as groupOfNames.
> 
> 
> I think this work can be done under the umbrella of 20278
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>