You cannot treat every binary file as utf-8 stream and convert it to plain string using ascii encoding.
You can simply try,
>>> f = open('/bin/ping')
>>> data = f.read()
>>> data.encode('utf-8')
and it will give you below error message,
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xa9 in position 24: ordinal not in range(128)
In fact, this is what the current code is doing - https://github.com/openstack/python-novaclient/blob/master/novaclient/v1_1/servers.py#L509 . We cannot use other char set encoding like ISO-8859-1, because that's not what the server is expecting. The reason we need a text representation of a binary file is also due to the signature of the nova server api - POST /v2/{tenant_id}/servers. Again that's what the server expects. I believe there were justification when they do the design desicsion. But now we are just dealing with a problem on the client side. Let's make the change mininal and best fit into the existing infrastructure.
I am thinking that just changing that line to "cont = base64.b64encode(data).decode('utf-8')" will do the work - directly using base64 encoding which was also the original way of doing the encoding before commit 8b264fc61d21fe4d0c7405914fb084f898956888 and that worked for you as well. I will submit a patch for the change after having some tests.
You cannot treat every binary file as utf-8 stream and convert it to plain string using ascii encoding.
You can simply try, 'utf-8' )
>>> f = open('/bin/ping')
>>> data = f.read()
>>> data.encode(
and it will give you below error message,
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xa9 in position 24: ordinal not in range(128)
In fact, this is what the current code is doing - https:/ /github. com/openstack/ python- novaclient/ blob/master/ novaclient/ v1_1/servers. py#L509 . We cannot use other char set encoding like ISO-8859-1, because that's not what the server is expecting. The reason we need a text representation of a binary file is also due to the signature of the nova server api - POST /v2/{tenant_ id}/servers. Again that's what the server expects. I believe there were justification when they do the design desicsion. But now we are just dealing with a problem on the client side. Let's make the change mininal and best fit into the existing infrastructure.
I am thinking that just changing that line to "cont = base64. b64encode( data).decode( 'utf-8' )" will do the work - directly using base64 encoding which was also the original way of doing the encoding before commit 8b264fc61d21fe4 d0c7405914fb084 f898956888 and that worked for you as well. I will submit a patch for the change after having some tests.