python-keystoneclient

user-role-list command fails when using --token and --endpoint authentication mechanism

Bug #1058750 reported by Joseph Heck on 2012-09-29

This bug affects 10 people

Affects		Status	Importance	Assigned to	Milestone
	python-keystoneclient	Won't Fix	Medium	Marcos Lobo

Bug Description

On Sep 29, 2012, at 5:35 AM, Asher Newcomer <email address hidden> wrote:
It looks like user-role-list is a recently added command in keystone (launchpad).

When I run it on a new keystone install in Ubuntu 12.04 I get:

keystone --token <mytoken> --endpoint http://192.168.1.11:35357/v2.0 user-role-list

'Client' object has no attribute 'auth_tenant_id'

It looks client side, and no corresponding entry in keystone.log. Bug?

Thanks,

Asher

...

That's a bug in keystoneclient - the method for doing the role listing is making a bad assumption that you're authenticating with a username and password, not handing in a token, and is getting wrapped around the axle trying to figure out what tenant you are. If you create an admin account with the --token and --endpoint options, and then use those options for this same command, you should be OK.

Joseph Heck (heckj) on 2012-09-29

Changed in python-keystoneclient:
importance:	High → Medium

Revision history for this message

Joseph Heck (heckj) wrote on 2012-09-29:

From dolph:

By default, I believe it shows you your own roles. With a token/endpoint specified (bypassing auth), it should work if you specify a user & tenant:

$ keystone help user-role-list
usage: keystone user-role-list [--user-id <user-id>] [--tenant-id <tenant-id>]

List roles granted to a user

Optional arguments:
  --user-id <user-id> List roles granted to a user
  --tenant-id <tenant-id>
                        List roles granted on a tenant

Revision history for this message

Christian Berendt (berendt) wrote on 2012-11-07:

Using only the user-id is not working.

admin:~ # keystone user-role-list --user-id 5d795ef6a803425e902922bb8f817828
'Client' object has no attribute 'auth_tenant_id'

Using user-id and tenant-id is working fine and lists all roles of a specified user for one tenant.

I think only using the user-id should work, too. Listing all roles for the specified user for all assigned tenants.

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2012-11-07: Fix proposed to python-keystoneclient (master)

Fix proposed to branch: master
Review: https://review.openstack.org/15570

Changed in python-keystoneclient:
assignee:	nobody → Christian Berendt (berendt)
status:	Confirmed → In Progress

Revision history for this message

Attila Fazekas (afazekas) wrote on 2012-11-12:

I have similar issue with the ec2-credentials-list.
IMHO it should work without --user-id parameter .

[root@localhost keystoneclient]# env |grep OS_
OS_PASSWORD=verybadpass
OS_AUTH_URL=http://127.0.0.1:5000/v2.0/
OS_USERNAME=admin
OS_TENANT_NAME=admin
[root@localhost keystoneclient]# keystone token-get
+-----------+----------------------------------+
| Property | Value |
+-----------+----------------------------------+
| expires | 2012-11-13T09:41:21Z |
| id | 190dea70b7cb490c9126d0fa878287cb |
| tenant_id | b005ba557c1747cca500e1f67db2620f |
| user_id | 32f19f054bca4526bbfb45b002bd75c9 |
+-----------+----------------------------------+
[root@localhost keystoneclient]# OS_SERVICE_TOKEN=190dea70b7cb490c9126d0fa878287cb OS_SERVICE_ENDPOINT=http://localhost:35357/v2.0 keystone ec2-credentials-list
'Client' object has no attribute 'auth_user_id'
[root@localhost keystoneclient]# OS_SERVICE_TOKEN=190dea70b7cb490c9126d0fa878287cb OS_SERVICE_ENDPOINT=http://localhost:35357/v2.0 keystone ec2-credentials-list --user-id 32f19f054bca4526bbfb45b002bd75c9
+--------+----------------------------------+----------------------------------+
| tenant | access | secret |
+--------+----------------------------------+----------------------------------+
| admin | 5884cf80adf74ff6910fe841c896fcb0 | bbaccbe6c8d04613996b46f2390a4424 |
+--------+----------------------------------+----------------------------------+

Should I create different BUG for this ?

Revision history for this message

Dolph Mathews (dolph) wrote on 2013-09-05:

Unassigning due to inactivity.

Changed in python-keystoneclient:
assignee:	Christian Berendt (berendt) → nobody
status:	In Progress → Triaged

Revision history for this message

Robert Collins (lifeless) wrote on 2013-09-11:

FWIW I was trying to use this to debug a keystone issue where cred signing is failing .. is tricky when this is broken.

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2014-08-19:

Fix proposed to branch: master
Review: https://review.openstack.org/115228

Changed in python-keystoneclient:
assignee:	nobody → Marcos Lobo (marcos-fermin-lobo)
status:	Triaged → In Progress

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2015-08-26: Change abandoned on python-keystoneclient (master)

Change abandoned by Dolph Mathews (<email address hidden>) on branch: master
Review: https://review.openstack.org/115228
Reason: Abandoning due to inactivity a -2.

Revision history for this message

Dolph Mathews (dolph) wrote on 2015-08-26:

Marking as incomplete because the referenced change has been abandoned. If this is still an issue, please reset the status.

Changed in python-keystoneclient:
status:	In Progress → Incomplete

Revision history for this message

Steve Martinelli (stevemar) wrote on 2015-11-27:

#10

given that we're not working on the CLI for keystoneclient, and that this seems to work with openstackclient i am marking this as won't fix.

openstackclient output:

Changed in python-keystoneclient:
status:	Incomplete → Won't Fix

Report a bug

This report contains Public information

Everyone can see this information.

Duplicates of this bug

Bug #1436430

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.