Open Stack

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.


-Dolph


On Wed, Jan 23, 2013 at 1:31 PM, Adam Young <ayoung at redhat.com> wrote:

> As I try and rework "roles mean membership" https://review.openstack.org/#
> **/c/20278/ <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 <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<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/c0a19064/attachment.html>