I dug on this a bit further, and I don't think it's actually an issue with ovo, I think it's an issue with our environment (which I still have an issue replicating locally).
The unicode for the utf8 name turns into: Íñstáñcé
However... in a devstack run we're setting LC_ALL=C because we grep the output of commands, and things get weird if people do those commands in other languages. This effectively squashes a lot of working utf8 support.
The following on a Linux desktop demonstrates what this issue would be:
os4:~> python -c "a = u'\u00CD\u00F1st\u00E1\u00F1c\u00E9'; print a"
Íñstáñcé
os4:~> LC_ALL=C python -c "a = u'\u00CD\u00F1st\u00E1\u00F1c\u00E9'; print a"
Traceback (most recent call last):
File "<string>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)
I dug on this a bit further, and I don't think it's actually an issue with ovo, I think it's an issue with our environment (which I still have an issue replicating locally).
The unicode for the utf8 name turns into: Íñstáñcé
However... in a devstack run we're setting LC_ALL=C because we grep the output of commands, and things get weird if people do those commands in other languages. This effectively squashes a lot of working utf8 support.
The following on a Linux desktop demonstrates what this issue would be:
os4:~> python -c "a = u'\u00CD\ u00F1st\ u00E1\u00F1c\ u00E9'; print a" u00F1st\ u00E1\u00F1c\ u00E9'; print a"
Íñstáñcé
os4:~> LC_ALL=C python -c "a = u'\u00CD\
Traceback (most recent call last):
File "<string>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)