Open Stack

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