<div dir="ltr">Yes, they're all similar concepts, but I don't think its necessary to denormalize their persistence. There are better opportunities for code reuse within the SQL driver.</div><div class="gmail_extra">
<br clear="all"><div><div><br></div>-Dolph</div>
<br><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 1:31 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As I try and rework "roles mean membership" <a href="https://review.openstack.org/#/c/20278/" target="_blank">https://review.openstack.org/#<u></u>/c/20278/</a>  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.<br>

<br>
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.<br>

<br>
The table would basically be the projects table outline:<br>
<br>
    __tablename__ = 'collection'<br>
    id = sql.Column(sql.String(64), primary_key=True)<br>
    parent_id = sql.Column(sql.String(64), sql.ForeignKey('<a href="http://collection.id" target="_blank">collection.id</a>'<u></u>), nullable=False )<br>
    name = sql.Column(sql.String(64), unique=True, nullable=False)<br>
    description = sql.Column(sql.Text())<br>
    enabled = sql.Column(sql.Boolean)<br>
    power_type = sql.Column(sql.Int)  #use ENUM type if all RDBMS support it<br>
<br>
power_type would be 0=user, 1=project,2=domain,3=group<br>
<br>
The user  table will still remain.  Think of the groups of type = 0 as groups as done in /etc/groups.<br>
<br>
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.<br>

<br>
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.<br>
<br>
Domains will have a null parent_id. Users,  (role)groups, and projects will have a domain as their parent.<br>
<br>
I don't think this will impact the LDAP backend, except to reinforce that the groupings should all be done as groupOfNames.<br>
<br>
<br>
I think this work can be done under the umbrella of 20278<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br></div>