RoleID and RoleName

[Joe Savak]

RoleID & RoleName should be available for role (similar to what was done for tenant and user)

[Yogeshwar (yogesh-srikrishnan)]

Iam quoting from Joe's previous email

Roles are preserved as there is syntax to prevent conflicts (namespace reserved for a service)

Was there a reason to change?

[Joe Savak (jsavak)]

Same structure as tenants and users and allow roles to be more flexible in the future... Especially when we start to think about service specific roles.

Sent from my Verizon Wireless 4GLTE smartphone

----- Reply message -----
From: "Yogeshwar" <email address hidden>
To: "Joe Savak" <email address hidden>
Subject: [Bug 834683] Re: RoleID and RoleName
Date: Tue, Sep 13, 2011 17:21

Iam quoting from Joe's previous email

Roles are preserved as there is syntax to prevent conflicts (namespace
reserved for a service)

Was there a reason to change?

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/834683

Title:
  RoleID and RoleName

Status in Identity for OpenStack (Keystone):
  In Progress

Bug description:
  RoleID & RoleName should be available for role (similar to what was
  done for tenant and user)

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/834683/+subscriptions
This email may include confidential information. If you received it in error, please delete it.

[Yogeshwar (yogesh-srikrishnan)]

Should same be done for services as well
Service are made of just id and description
Should they also be made of
id name and description unlike id and description thats there right now? Also all these changes should propagate into contract as well.There would be changes to xsds ,wadls,docs etc.

[Joe Savak (jsavak)]

Yes - should be done for service (id, name, description)

[Dolph Mathews (dolph)]

I'm starting to think that both the ID *and* Name should be returned along with *any* object that contains both (user, tenant, role, service), as they can both be used to identify resources (clients will generally look at the name, while the keystone server will generally look at the ID). This implies we need to add a lot of missing "name" attributes to the XSD's (and JSON responses).

Conversely, when making requests, it should only be possible to request by ID, e.g.:

GET /tenants/{tenant_id}

We also have a shortcoming when it comes to looking up ID's directly by name... I believe we're missing methods such as:

GET /tenants?name=foobar
GET /roles?name=admin
GET /services?name=nova

[Joe Savak (jsavak)]

Dolph - +1 - but probably needs more design before code. Not sure what we'll break if we only request by ID.

[Openstack Gerrit (openstack-gerrit)]

Reviewed: https://review.openstack.org/431
Committed: http://github.com/openstack/keystone/commit/35e4b2579164e763654e507ec215e51c72e5ab22
Submitter: Jenkins
Branch: master

 status fixcommitted
 done

commit 35e4b2579164e763654e507ec215e51c72e5ab22
Author: Dolph Mathews <email address hidden>
Date: Tue Sep 13 09:20:30 2011 -0500

    Backend-managed role & service ID's (bug #834683)

    - Revised SqlAlchemy Role & Service models
    - Revised LDAP-backend 'id'/'name' attribute mgmt
      - Only persisting ID's
      - Returning id as both 'name' and 'id'
    - Updated keystone.manage to CRUD by role/service name
    - Revised backends.*ADMIN_ROLE* variables
    - Updated json/xml encoding/decoding for roles & services
    - Performing KEYSTONE_[SERVICE_]_ADMIN_ID lookups on first auth
      - This could be improved!
    - Revised role & service samples & XSD's

    Change-Id: I1aee372fb28d429f5e5410d43b7e2c6aa297d998