Description of problem: keystoneclient unable to handle usernames containing utf-8 characters. # keystone user-create --name ñew --tenant admin # keystone user-get ñew 'ascii' codec can't decode byte 0xc3 in position 6: ordinal not in range(128) Version-Release number of selected component (if applicable): python-keystoneclient-0.9.0-5.el6ost.noarch openstack-keystone-2014.1.4-1.el6ost.noarch python-keystone-2014.1.4-1.el6ost.noarch How reproducible: Always. Steps to Reproduce: 1. Create a user with a username containing UTF-8 encoded characters. 2. Attempt to `keystone get-user` for this user. Actual results: Decoding exception thrown. Expected results: No decoding exception thrown, user details displayed. Additional info: Hackaround forcing the find_resource utility method to decode as utf-8 : # cp /usr/lib/python2.6/site-packages/keystoneclient/utils.py.patch /usr/lib/python2.6/site-packages/keystoneclient/utils.py # diff -u /usr/lib/python2.6/site-packages/keystoneclient/utils.py.org /usr/lib/python2.6/site-packages/keystoneclient/utils.py --- /usr/lib/python2.6/site-packages/keystoneclient/utils.py.org 2015-05-28 09:30:14.461000007 -0400 +++ /usr/lib/python2.6/site-packages/keystoneclient/utils.py 2015-05-28 09:30:27.001000010 -0400 @@ -103,11 +103,6 @@ except exceptions.NotFound: pass - # now try the entity as a string - try: - return manager.get(name_or_id) - except (exceptions.NotFound): - pass # finally try to find entity by name try: # keystone user-get ñew +----------+----------------------------------+ | Property | Value | +----------+----------------------------------+ | email | | | enabled | True | | id | 3a219125fe0b40e0875893b91d805d8d | | name | ñew | | tenantId | 1970e3873c2247ff902ff66798a02da5 | | username | ñew | +----------+----------------------------------+ # keystone user-get 3a219125fe0b40e0875893b91d805d8d +----------+----------------------------------+ | Property | Value | +----------+----------------------------------+ | email | | | enabled | True | | id | 3a219125fe0b40e0875893b91d805d8d | | name | ñew | | tenantId | 1970e3873c2247ff902ff66798a02da5 | | username | ñew | +----------+----------------------------------+ This also reproduces with the now deprecated Kilo keystoneclient : # rpm -qa | grep keystoneclient python-keystoneclient-1.3.0-1.el7ost.noarch # keystone user-create --name ñew --tenant admin /usr/lib/python2.7/site-packages/keystoneclient/shell.py:65: DeprecationWarning: The keystone CLI is deprecated in favor of python-openstackclient. For a Python library, continue using python-keystoneclient. 'python-keystoneclient.', DeprecationWarning) +----------+----------------------------------+ | Property | Value | +----------+----------------------------------+ | email | | | enabled | True | | id | d5ab3a58615f4ba8a71e3b30ade95a26 | | name | ñew | | tenantId | 9df2fdbc4e834ce383ab1a88a2a65433 | | username | ñew | +----------+----------------------------------+ # keystone user-get ñew /usr/lib/python2.7/site-packages/keystoneclient/shell.py:65: DeprecationWarning: The keystone CLI is deprecated in favor of python-openstackclient. For a Python library, continue using python-keystoneclient. 'python-keystoneclient.', DeprecationWarning) 'ascii' codec can't decode byte 0xc3 in position 6: ordinal not in range(128) The unified openstack client also fails here but I'll submit a seperate bug for this : # openstack user show ñew /usr/lib/python2.7/site-packages/keystoneclient/base.py:266: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal for (attr, value) in searches): ERROR: openstack No user with a name or ID of 'ñew' exists.
I can confirm this is still an issue on upstream master. I've proposed a patch and we'll see how it goes upstream. Similar patches in the past have been rejected because we have deprecated and are trying to remove the keystone CLI tool.
I have the fix ready to push, awaiting pm_ack.
Any progress on this? There haven't been any updates for ages (since July 2015, to be exact).
I reviewed the code. The fix for utf-8 looks good to me. However I did spot what appears to be a separate issue. It looks as if the name_or_id parameter is an integer or a string of digits and the actual key is an integer the test would fail, but there is no such test. Not sure if there is a presumption keys are always strings or not, but as I say that is a separate issue. The specific fix for utf-8 looks fine.
*** Bug 1264474 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1214