yahoo-eng-team team mailing list archive

[Cristian Sava <chsava@xxxxxxxxx>]

Public bug reported:

For a given command ("role assignment list" for instance), the JSON
output produced by the server includes only "id" attributes for role,
domain, user, group, project entities:

{"scope": {"domain": {"id": "ebf86cfa900f4fdab7f3b2a75bb28e6d"}},
"role": {"id": "2eaad22a1c6d4a4d8e5d9cce4c45bd29"}, "user": {"id":
"eeaf0e9a2a8da1200f7d0c5428029bffbb2cbc44543acd46653f7dadc08d5aa2"},
"links": {"assignment":
"https://100.73.163.76:5000/v3/domains/ebf86cfa900f4fdab7f3b2a75bb28e6d/users/eeaf0e9a2a8da1200f7d0c5428029bffbb2cbc44543acd46653f7dadc08d5aa2/roles/2eaad22a1c6d4a4d8e5d9cce4c45bd29"}}

While the "id" attribute is sufficient for the automatic client tools,
it is not at all friendly for the human user. Client tools also cannot
get very easily around this limitation by running secondary queries, as
a certain listing can comprise hundreds and even thousands of entries;
running secondary queries for that many records is clearly impractical.

The solution consists in my view for the keystone server to return more
complete information in the first place, by including at least a user-
friendly "name" attribute besides the strictly necessary "id". Client
tools will then be able to exploit this extra info to produce more
readable output.

** Affects: keystone
     Importance: Undecided
         Status: New


** Tags: attribute name

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1523695

Title:
  Keystone server should produce additional "name" attributes besides
  "id" for various entities: user, group, domain, project, role

Status in OpenStack Identity (keystone):
  New

Bug description:
  For a given command ("role assignment list" for instance), the JSON
  output produced by the server includes only "id" attributes for role,
  domain, user, group, project entities:

  {"scope": {"domain": {"id": "ebf86cfa900f4fdab7f3b2a75bb28e6d"}},
  "role": {"id": "2eaad22a1c6d4a4d8e5d9cce4c45bd29"}, "user": {"id":
  "eeaf0e9a2a8da1200f7d0c5428029bffbb2cbc44543acd46653f7dadc08d5aa2"},
  "links": {"assignment":
  "https://100.73.163.76:5000/v3/domains/ebf86cfa900f4fdab7f3b2a75bb28e6d/users/eeaf0e9a2a8da1200f7d0c5428029bffbb2cbc44543acd46653f7dadc08d5aa2/roles/2eaad22a1c6d4a4d8e5d9cce4c45bd29"}}

  While the "id" attribute is sufficient for the automatic client tools,
  it is not at all friendly for the human user. Client tools also cannot
  get very easily around this limitation by running secondary queries,
  as a certain listing can comprise hundreds and even thousands of
  entries; running secondary queries for that many records is clearly
  impractical.

  The solution consists in my view for the keystone server to return
  more complete information in the first place, by including at least a
  user-friendly "name" attribute besides the strictly necessary "id".
  Client tools will then be able to exploit this extra info to produce
  more readable output.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1523695/+subscriptions