Bug 888455
Summary: | Traceback when non-ASCII in snapshot name | ||
---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Russell Bryant <rbryant> |
Component: | python-glanceclient | Assignee: | Jakub Ruzicka <jruzicka> |
Status: | CLOSED ERRATA | QA Contact: | Attila Fazekas <afazekas> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2.1 | CC: | apevec, dallan, fpercoco, zbitter |
Target Milestone: | snapshot5 | Keywords: | i18n, Triaged |
Target Release: | 2.1 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | 0.8.0-1 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-04-04 17:58:30 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Russell Bryant
2012-12-18 18:16:55 UTC
Looks like there's upstream work required to cleanup i18n issues across all openstack clients (see also novaclient bug 888483) I did some digging and asked some questions on the upstream mailing list: http://lists.openstack.org/pipermail/openstack-dev/2013-January/005027.html Nice message. This crash here (as for novaclient) is more related to a python pitfall. What happens is that headers are correctly encoded to UTF-8 and then, when it tries to build the request with http, it tries to re-encode[0] because `self.endpoint`[1] and `self.auth_token`[2] are unicode strings. So, basically what happens is: conn.request(...) gets headers like: { "header1": "value", "header2": u"value2", "header3": "value3" } That will be converted in something like: ["header1: value", u"header2: value2", "header3: value3"] #note the unicode string which will then joined inside httplib in order to build the final request like: "\r\n".join(self._buffer) This line of code here blows everything because Python joins the first item as normal utf8, then finds the second one and notices it is unicode and encodes it as utf8 and then it tries to encode the next string which already encoded because the previous one wasn't. Live example: python2.7 -c "print '\r\n'.join(['a', u'b', '\xc3\xb1'])" # Fails python2.7 -c "print '\r\n'.join(['a', 'b', '\xc3\xb1'])" # Prints This all comes down to what you said in that thread, "encoding inconsistency within clients and / or servers" so, hopefully, that patch waiting for review (first oslo, then clients) will help to give this modules some standard way to encode / decode strings throughout OS. Btw, glanceclient also fails when it tries to log the request, same reason as described above and depending on the terminal input encoding it might also just like the traceback used for this bug. Hope this helps. Cheers. [0] https://github.com/openstack/python-glanceclient/blob/master/glanceclient/common/http.py#L158 [1]https://github.com/openstack/python-glanceclient/blob/master/glanceclient/common/http.py#L48 [2] https://github.com/openstack/python-glanceclient/blob/master/glanceclient/common/http.py#L59 [root@node-01 ~(keystone_admin)]$ nova image-create 6fdcafa3-b86b-479e-b1cf-5e6859912e65 "El Niño" [root@node-01 ~(keystone_admin)]$ glance image-list +--------------------------------------+----------+-------------+------------------+-----------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+----------+-------------+------------------+-----------+--------+ | a3b5eca5-f9a7-41cb-9814-cca7b0fe934c | El Niño | | | | queued | [root@node-01 ~(keystone_admin)]$ glance image-list +--------------------------------------+----------+-------------+------------------+-----------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+----------+-------------+------------------+-----------+--------+ | a3b5eca5-f9a7-41cb-9814-cca7b0fe934c | El Niño | qcow2 | bare | 661848064 | active | LGTM 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. http://rhn.redhat.com/errata/RHBA-2013-0706.html |