Bug 1661913

Summary: [V2V][OSP] VM migrations fails if VM name contains international characters
Product: Red Hat OpenStack Reporter: Yadnyawalk Tale <ytale>
Component: python-openstackclientAssignee: Bernard Cafarelli <bcafarel>
Status: CLOSED ERRATA QA Contact: Candido Campos <ccamposr>
Severity: medium Docs Contact:
Priority: medium    
Version: 14.0 (Rocky)CC: amuller, apevec, bcafarel, beth.white, chrisw, ekuris, fdupont, jpichon, lhh, maufart, mbooth, mburns, sclewis, smallamp, tgolembi
Target Milestone: Upstream M3Keywords: Triaged
Target Release: 15.0 (Stein)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: v2v
Fixed In Version: python-openstackclient-3.18.0-0.20190312140834.6868499.el8ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-09-21 11:19:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: Bug
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: V2V Target Upstream Version:

Description Yadnyawalk Tale 2018-12-24 11:32:57 UTC
Description of problem:
For OSP, when migrating VMware VM with a name containing international chars, migration fails. 

Version-Release number of selected component (if applicable):
Conversion appliance used - https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=815918

How reproducible:

Steps to Reproduce:
1. Create vm with international chars in cfme (punycodes)
2. Try to migrate it
(Used mapping nfs-nfs mapping, I don't think storage types matters)

Actual results:
Migration fails with 'Convert Disk' status.

Expected results:
VM should be migrate with punycodes. 

Example vm name used: 

Additional info:
automation.log attached
virt-v2v.log attached

Comment 5 Yadnyawalk Tale 2018-12-24 11:53:40 UTC
See also: similar issue found on RHV -> https://bugzilla.redhat.com/show_bug.cgi?id=1596143

Comment 7 Tomáš Golembiovský 2019-01-07 10:56:49 UTC
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)

Comment 8 Tomáš Golembiovský 2019-01-07 10:59:27 UTC
FYI some time back I've been told that international characters are supported and any issues should be reported to Openstack.

Comment 9 Yadnyawalk Tale 2019-01-07 11:09:20 UTC
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.

Comment 12 Bernard Cafarelli 2019-01-09 19:07:45 UTC
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": ""}                         |
|                       | {"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):

Comment 15 Bernard Cafarelli 2019-01-24 16:20:02 UTC
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

Comment 17 Tomáš Golembiovský 2019-01-24 17:32:29 UTC
(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.

Comment 24 Bernard Cafarelli 2019-03-05 10:01:25 UTC
Both SDK and CLI patches merged upstream master

Comment 30 errata-xmlrpc 2019-09-21 11:19:41 UTC
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.