Bug 905543 - Keystone user-role-add returns no output on success.
Keystone user-role-add returns no output on success.
Status: CLOSED UPSTREAM
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-keystoneclient (Show other bugs)
2.1
Unspecified Unspecified
low Severity low
: async
: 4.0
Assigned To: Alan Pevec
Jeremy Agee
: MoveUpstream, Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-29 11:00 EST by Stephen Gordon
Modified: 2016-04-26 11:22 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-14 12:38:49 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1229948 None None None Never

  None (edit)
Description Stephen Gordon 2013-01-29 11:00:58 EST
Description of problem:

Most keystone commands for adding records (user-create, tenant-create, role-create) return a table displaying the added record on success.

Keystone user-role-add however returns no output on success, resulting in the user being confused as to whether it worked or not.

$ keystone user-role-add --user-id 02425a0a159047c684765479e24361f4 --role-id 6e21529587304dd3837169beb6d0cab5 --tenant-id c0aa38874506466383335f3ad01bc699
$ keystone user-role-add --user-id 02425a0a159047c684765479e24361f4 --role-id 6e21529587304dd3837169beb6d0cab5 --tenant-id c0aa38874506466383335f3ad01bc699
Conflict occurred attempting to store role grant. User 02425a0a159047c684765479e24361f4 already has role 6e21529587304dd3837169beb6d0cab5 in tenant c0aa38874506466383335f3ad01bc699 (HTTP 409)

Version-Release number of selected component (if applicable):

openstack-keystone-2012.2.1-1.el6ost.noarch
Comment 1 Stephen Gordon 2013-01-29 11:05:35 EST
NB: It's possible the lack of output here is related to the lack of output I reported from user-role-list in Bug # 905541 but it wasn't clear to me that was the case, hence two bugs for now.
Comment 2 Lon Hohberger 2013-04-18 15:55:48 EDT
I think this is expected behavior.  The exit code is correct:

[root@localhost ~(keystone_admin)]# keystone user-role-add --user-id=admin --role-id=2ef2d259593a4341a8ee83ac61375bc3 --tenant-id=13f3c4a17690494da921e7cbfc069330
[root@localhost ~(keystone_admin)]# echo $?
0

[root@localhost ~(keystone_admin)]# keystone user-role-add --user-id=admin --role-id=2ef2d259593a4341a8ee83ac61375bc3 --tenant-id=13f3c4a17690494da921e7cbfc069330
Unable to communicate with identity service: {"error": {"message": "Conflict occurred attempting to store role grant. User 99a1879d4bf14f73a842bd55ca1d0496 already has role 2ef2d259593a4341a8ee83ac61375bc3 in tenant 13f3c4a17690494da921e7cbfc069330", "code": 409, "title": "Conflict"}}. (HTTP 409)
[root@localhost ~(keystone_admin)]# echo $?
1

And on remove:

[root@localhost ~(keystone_admin)]# keystone user-role-remove --user-id=admin --role-id=2ef2d259593a4341a8ee83ac61375bc3 --tenant-id=13f3c4a17690494da921e7cbfc069330
[root@localhost ~(keystone_admin)]# echo $?
0
[root@localhost ~(keystone_admin)]# keystone user-role-remove --user-id=admin --role-id=2ef2d259593a4341a8ee83ac61375bc3 --tenant-id=13f3c4a17690494da921e7cbfc069330
Unable to communicate with identity service: {"error": {"message": "Cannot remove role that has not been granted, 2ef2d259593a4341a8ee83ac61375bc3", "code": 404, "title": "Not Found"}}. (HTTP 404)
[root@localhost ~(keystone_admin)]# echo $?
1

Now... the errors are well past awful from a usability perspective, but...
Comment 5 Dmitri Pal 2013-09-24 16:46:39 EDT
This is expected. Check command error codes.
Comment 6 Stephen Gordon 2013-09-24 17:12:19 EDT
(In reply to Dmitri Pal from comment #5)
> This is expected. Check command error codes.

I disagree, it's inconsistent with, among others:

- keystone user-create
- keystone role-create
- keystone tenant-create

All of which display the resultant record on success. For example:

# keystone role-create --name admin     
+----------+----------------------------------+
| Property |              Value               |
+----------+----------------------------------+
| id       | 78035c5d3cd94e62812d6d37551ecd6a |
| name     |              admin               |
+----------+----------------------------------+

If displaying the output isn't required and users should check the exit code then why is that not the case for all of the other keystone actions?
Comment 7 Jakub Ruzicka 2013-11-14 12:38:49 EST
This was closed as Won't Fix upstream with a good explanation. Fixing this downstream makes no sense so I'm closing.

Note You need to log in before you can comment on or make changes to this bug.