<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 01/23/2013 02:58 PM, Henry Nash
      wrote:<br>
    </div>
    <blockquote
      cite="mid:946281DB-2639-4A88-81D8-33D0338D47AD@linux.vnet.ibm.com"
      type="cite">
      <pre wrap="">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.</pre>
    </blockquote>
    Technically, it is not denormalization. It still is in 3rd Normal
    form.<br>
    <br>
    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 <br>
    <br>
    user_id (fk)  , group_id(fk)<br>
    <br>
    but if group_id is going to point to more than one table, it can't
    be done as a foreign key.<br>
    <br>
    This is more an acceptance of an inheritance relationship known as
    the party pattern:<br>
    <br>
    I'll try to come up with some decent links:  sorry that they are
    mostly PDFs<br>
    <br>
    <cite>martinfowler.com/apsupp/accountability.pdf</cite><br>
    <br>
    Better UML of it<br>
    <cite>martinfowler.com/apsupp/apchap2.pdf<br>
    </cite><cite><cite><br>
        <br>
      </cite></cite>My UML from years ago:  <br>
    <a class="moz-txt-link-freetext" href="http://admiyo.fedorapeople.org/patterns/PartyPattern.png">http://admiyo.fedorapeople.org/patterns/PartyPattern.png</a><br>
    <br>
    <cite>martinfowler.com/apsupp/roles.pdf</cite><br>
    <br>
    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.<br>
    <br>
    <br>
    <br>
    <blockquote
      cite="mid:946281DB-2639-4A88-81D8-33D0338D47AD@linux.vnet.ibm.com"
      type="cite">
      <pre wrap="">

Just my 2cents

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

</pre>
      <blockquote type="cite">
        <pre wrap="">As I try and rework "roles mean membership<a class="moz-txt-link-rfc2396E" href="https://review.openstack.org/#/c/20278/Iamstructbythefactthatthegrantscallsallarecommonregardlessofwhethertheyaregrouptouser,grouptodomain,orwhatnot.Itseemstomethatwecouldtakethisabstractionfurther,andmakegroups,domains,andprojectsallasingleSQLentitycalledacollection,andputitintoasingletable.Then,roleassignmentsareassociationsbetweencollections.Eachuserwouldgetanentryinthecollectionstableaswell.Thetablewouldbasicallybetheprojectstableoutline:__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)#useENUMtypeifallRDBMSsupportitpower_typewouldbe0=user,1=project,2=domain,3=groupTheusertablewillstillremain.Thinkofthegroupsoftype=0!
 asgroupsas
donein/etc/groups.Iwouldactuallyprefertocallthisthe'group'tableinsteadofthecollectiontable,ifwecansomehowdeconflictthetermwiththewaythatkeystoneispresentlyusinggroup.Ithink">" 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  "</a>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
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>

</pre>
      </blockquote>
      <pre wrap="">

_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>