Bug 1661913

See also: similar issue found on RHV -> https://bugzilla.redhat.com/show_bug.cgi?id=1596143

This is a bug in Openstack. The 'openstack' command fails when creating port with unicode in the name.
The error from 'openstack' command is:

> 'ascii' codec can't encode characters in position 11-16: ordinal not in range(128)

FYI some time back I've been told that international characters are supported and any issues should be reported to Openstack.

Thanks for confirming @Tomáš @Brett. 
I am unaware of where to assign this issue right now, can you suggest me/assign this to respective team? Thanks a lot.

Indeed from log, the openstack port creation fails on unicode characters.

Just retested on devstack master:
$ openstack port create name™ --network private
'ascii' codec can't encode character u'\u2122' in position 4: ordinal not in range(128)

Although legacy CLI works:
$ neutron port-create --name test™ private
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Created a new port:
+-----------------------+-------------------------------------------------------------------------------------------------------------+
| Field                 | Value                                                                                                       |
+-----------------------+-------------------------------------------------------------------------------------------------------------+
| admin_state_up        | True                                                                                                        |
| allowed_address_pairs |                                                                                                             |
| binding:vnic_type     | normal                                                                                                      |
| created_at            | 2019-01-09T19:05:03Z                                                                                        |
| description           |                                                                                                             |
| device_id             |                                                                                                             |
| device_owner          |                                                                                                             |
| extra_dhcp_opts       |                                                                                                             |
| fixed_ips             | {"subnet_id": "9cb8df7b-c63e-49c3-8b8a-714dfdcc4e6a", "ip_address": "192.168.0.46"}                         |
|                       | {"subnet_id": "65126bf4-95ba-43e4-94f5-ddc5e19084df", "ip_address": "fde2:5b58:fd5b:0:f816:3eff:fe52:c840"} |
| id                    | 7edaa36c-e7f3-49ae-8185-06c5a784a9d8                                                                        |
| mac_address           | fa:16:3e:52:c8:40                                                                                           |
| name                  | test™                                                                                                       |
[...]

So openstack CLI bug? I found similar storyboard (still open):
https://storyboard.openstack.org/#!/story/2004356

I updated the storyboard link with some additional information. Short version, using OSC CLI with python2 will trigger several issues with real Unicode chains (str() calls do not like them) in python-openstackclient and openstacksdk.

Short-term workarounds, depending on the OpenStack version you want to use and the host system where CLI commands are run:
* Use neutron CLI. This seems to work but this one is deprecated. Recommended for older OpenStack installs
* Run openstack CLI with python3. You only need python3 on the system running the commands, not the nodes themselves. I could manipulate ports and networks with unicode character ™ in their names without an issue

(In reply to Bernard Cafarelli from comment #15)

> * Run openstack CLI with python3. You only need python3 on the system
> running the commands, not the nodes themselves. I could manipulate ports and
> networks with unicode character ™ in their names without an issue

This may be a viable workaround for us. Assuming we can get some python3 version on OSP appliance...
Marek/Mike, would that be possible? If yes, which python3 packages/versions should we use to test this.

Both SDK and CLI patches merged upstream master

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/RHEA-2019:2811