Open Stack

On 01/23/2013 02:58 PM, Henry Nash wrote:
> 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.
Technically, it is not denormalization. It still is in 3rd Normal form.

The grants table that you speak of would not be able to have referential 
integrity constraints unless all of the elements referred to by each 
column are in a single table.  If we were doing user to group, for 
example,  the table would be

user_id (fk)  , group_id(fk)

but if group_id is going to point to more than one table, it can't be 
done as a foreign key.

This is more an acceptance of an inheritance relationship known as the 
party pattern:

I'll try to come up with some decent links:  sorry that they are mostly PDFs

martinfowler.com/apsupp/accountability.pdf

Better UML of it
martinfowler.com/apsupp/apchap2.pdf


My UML from years ago:
http://admiyo.fedorapeople.org/patterns/PartyPattern.png

martinfowler.com/apsupp/roles.pdf

My proposal would not allow a group to be a member of a user. 
Technically, the parent field could be extended to allow nested groups 
and projects, but I am not proposing doing that now.



>
> 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
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130123/3c2ed063/attachment.html>