[openstack-dev] [Keystone] Domains, Projects, and Groups are all collections
dolph.mathews at gmail.com
Wed Jan 23 19:50:29 UTC 2013
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.
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
> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev