Comment 5 for bug 1744075

So, apparently, it's more due to puppet than python.
More specifically, there's a "puppet-openstacklib" package that gives some provider for openstack.
It also provides a small lib that parses the CSVs from openstack CLI, and map the content to some simple object.

The issue is, nothing is done with string encoding in there. And this is where puppet crashes. Since its very débuts, puppet has had issues with non-ASCII strings - I even had some template with a simple "…" in it that made the whole catalogue crash. So long for i18n support…

Therefore, we need to either ensure user can't input any non-ASCII string (bad UX in the end, can't even think about the issues/troubles this will create), or filter out the non-ASCII things within puppet.

In order to do the latter, I see two solutions :

- either use the "transliterate" from i18n package, that will work for latin-based languages such as Czech, Roman, French, German and so on.

- or make a deeper change, and hash strings in order to be able to do proper comparison if needed, while still avoiding non-ASCII.

For both solutions, the file to hit is:
https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack.rb#L150-151

For the latter solution, while being longer and a bit more complicated, we might want to create a function that will iterate on the CSV object, with a provided list of "user fields" (such as "name", "description", and so on) that we need to hash (think: md5, sha1, whatever).
Doing so will allow to compare strings in case we need to base something on user input, as we can simply hash both side, compare, and act upon the comparison result.

Using the transliteration looks nice as it will allow to still read the string, but it will hit issues in those cases:
- non-latin base language such as Chinese, Japanese
- unable to do any proper string comparison