Red Hat Bugzilla – Bug 1023062
Architectures etc: resources created/modified should not use multibyte names in URLs
Last modified: 2017-02-23 16:19:03 EST
Description of problem: when a user creates or renames a compute resource which has multibyte characters, the resulting namespace used by URL consists of nothing but resource id and a dash. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Use hammer cli to quickly create a couple compute resources for comparison (though the same thing happens when you create/edit in UI) hammer -u admin -p admin compute_resource create --name my_resource --url qemu+tcp://localhost:16509/system --provider Libvirt hammer -u admin -p admin compute_resource create --name Jalapeño --url qemu+tcp://localhost:16509/system --provider Libvirt hammer -u admin -p admin compute_resource create --name 大傻瓜 --url qemu+tcp://localhost:16509/system --provider Libvirt 2. Navigate to compute resource view to see all the CRs you just created. 3. Observe URLs for each Actual results: For the regular and extended latin-1 entries ('my_resource', 'Jalapeño'), URL namespace is basically 'normal' compute resource name, prepended with the id. The 'ñ' in Jalapeño gets converted to 'n' in the URL, but that's probably OK. However, you'll note the entry which contains multibyte characters has only '<id>-' -- no strings after. It doesn't /seem/ to cause real problems with usability here immediately, but it seems to me it could cause issues elsewhere. Also, it'll possibly make eventually automating this code more difficult in QE since the URLs won't be created in a uniform manner. Expected results: Actually, I'm not sure whether we should be using the resource name in the URL at all -- ID alone might suffice, or perhaps some other sort of UUID along with it -- but whatever the case, we should be handling compute resource names in a sane, congruent manner. Additional info:
It should be noted that this is handled differently in other areas of foreman, e.g., Architectures. Here, each string, regular ascii, extended latin-1 or multibyte -- appears 'correctly' in URL.
Ok, I'm going to flip this BZ around and say that compute resources are operating correctly, but the bug is in architectures etc. The way it's intended to work is: 1. resources that have very restrictive name validation may use the name as a parameter 2. resources with more free-form text should use "id-name" and find the resource just based on the ID, then the name is run through .parameterize to ensure it contains plain ASCII chars (the stripping behaviour you see). So we're not consistently calling .parameterize on all of our resource names, causing multibyte chars to appear in URLs, which they generally shouldn't. The idea is that the URLs are then copy/paste safe etc, but give a hint to the user as to the resource name if possible. As for automation, you can just use the ID and leave off the name portion.
*** Bug 1023137 has been marked as a duplicate of this bug. ***
Merged as 39558b7200a7e1d4d5976ee62e25491d9016e56f in develop. As per comment #3, we've tried to make this "id-name" behaviour more consistent across the application but are retaining the behaviour to strip non-ASCII characters for URL safety.
Created attachment 928623 [details] Compute resource not found # hammer -u admin -p *** compute-resource create --name 大傻瓜 -urrl qemu+tcp://localhost:16509/system --provider Libvirt Compute resource created In UI it shows Compute Resource not found
The problem got fixed with introduction of friendly_id: commit 8b737c9c7648b3726dadb3b2e4708fcb43af02a8 Author: Joseph Magen <jmagen@redhat.com> Date: Tue Sep 23 12:02:52 2014 +0300 fixes #4386 - gem friendly_id to simplify find by id, name, label, etc
VERIFIED: *** This bug is verified in upstream. This fix should eventually land in future downstream builds *** # rpm -qa | grep foreman foreman-release-1.7.0-0.develop.201410150839gitb948163.el6.noarch foreman-gce-1.7.0-0.develop.201410150839gitb948163.el6.noarch foreman-selinux-1.7.0-0.develop.201409301113git2f345de.el6.noarch rubygem-hammer_cli_foreman_tasks-0.0.3-2.201409091410gitc96619d.git.0.37f3704.el6.noarch qe-foreman-rhel65.usersys.redhat.com-foreman-proxy-1.0-1.noarch foreman-postgresql-1.7.0-0.develop.201410150839gitb948163.el6.noarch qe-foreman-rhel65.usersys.redhat.com-qpid-broker-1.0-1.noarch qe-foreman-rhel65.usersys.redhat.com-qpid-client-cert-1.0-1.noarch foreman-1.7.0-0.develop.201410150839gitb948163.el6.noarch foreman-ovirt-1.7.0-0.develop.201410150839gitb948163.el6.noarch foreman-vmware-1.7.0-0.develop.201410150839gitb948163.el6.noarch ruby193-rubygem-foreman_hooks-0.3.7-2.el6.noarch ruby193-rubygem-foreman_discovery-1.4.0-0.1.rc4.el6.noarch rubygem-hammer_cli_foreman-0.1.3-1.201410151235gitbc8c449.el6.noarch ruby193-rubygem-foreman_bootdisk-4.0.0-1.el6.noarch foreman-proxy-1.7.0-0.develop.201410101404git7961640.el6.noarch qe-foreman-rhel65.usersys.redhat.com-puppet-client-1.0-1.noarch qe-foreman-rhel65.usersys.redhat.com-foreman-client-1.0-1.noarch qe-foreman-rhel65.usersys.redhat.com-apache-1.0-1.noarch qe-foreman-rhel65.usersys.redhat.com-parent-cert-1.0-1.noarch foreman-compute-1.7.0-0.develop.201410150839gitb948163.el6.noarch ruby193-rubygem-foreman-tasks-0.6.10-1.el6.noarch foreman-libvirt-1.7.0-0.develop.201410150839gitb948163.el6.noarch Compute resource names are retained congruent manner
Created attachment 947902 [details] compute resource
Upstream bug assigned to ddolguik@redhat.com
This bug is slated to be released with Satellite 6.1.
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/RHSA-2015:1592