+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1666913 +++ ====================================================================== Description of problem: When creating a logical network, the input field allows for a space in the network name. This causes issues as the ifcfg file does not get saved to the host. Version-Release number of selected component (if applicable): 4.2 How reproducible: Steps to Reproduce: 1. Create a logical network with a ' ' at the end, e.g. 'Log_network ' 2. Assign this to a host 3. Check the host for ifcfg file, it does not exist Actual results: The network is created although it contains an invalid character Expected results: The network should not be allowed to create, input field should be checked for illegal characters. Additional info: Host will see some errors like: ~~~Raw Jan 15 12:05:57 hostname NetworkManager[1650]: <warn> [1547571957.4150] ifcfg-rh: invalid DEVICE name 'Storage_SVIP ': interface name contains an invalid character Jan 15 12:05:57 hostname NetworkManager[1650]: <info> [1547571957.4157] ifcfg-rh: new connection /etc/sysconfig/network-scripts/ifcfg-Storage_SVIP (000ad653-6856-2a23-3ef1-7baed84066ec,"System Storage_SVIP ") Jan 15 12:05:57 hostname NetworkManager[1650]: <info> [1547571957.4158] ifcfg-rh: Ignoring connection /etc/sysconfig/network-scripts/ifcfg-Storage_SVIP (000ad653-6856-2a23-3ef1-7baed84066ec,"System Storage_SVIP ") due to NM_CONTROLLED=no. Unmanaged: interface-name:Storage_SVIP . Jan 15 12:05:57 hostname libvirtd: 2019-01-15 17:05:57.430+0000: 10969: error : qemuOpenFileAs:3183 : Failed to open file '/rhev/data-center/5b05d437-036c-03c4-003a-000000000212/3f67d548-0d7b-463d-91da-5d4bb358877a/images/eb833610-7153-4071-8fe2-900f0102b1c2/74387b3e-44b5-4a14-ada0-c1225c49b008': No such file or directory Jan 15 12:05:57 hostname libvirtd: 2019-01-15 17:05:57.431+0000: 10969: error : qemuDomainStorageOpenStat:11492 : cannot stat file '/rhev/data-center/5b05d437-036c-03c4-003a-000000000212/3f67d548-0d7b-463d-91da-5d4bb358877a/images/eb833610-7153-4071-8fe2-900f0102b1c2/74387b3e-44b5-4a14-ada0-c1225c49b008': Bad file descriptor Jan 15 12:05:57 hostname libvirtd: 2019-01-15 17:05:57.435+0000: 10969: error : qemuOpenFileAs:3183 : Failed to open file '/rhev/data-center/5b05d437-036c-03c4-003a-000000000212/3f67d548-0d7b-463d-91da-5d4bb358877a/images/39a25f0f-b3c2-47ef-bd03-c519a1f4637d/ff80b008-f387-47dd-8131-8f265f14c792': No such file or directory Jan 15 12:05:57 hostname libvirtd: 2019-01-15 17:05:57.435+0000: 10969: error : qemuDomainStorageOpenStat:11492 : cannot stat file '/rhev/data-center/5b05d437-036c-03c4-003a-000000000212/3f67d548-0d7b-463d-91da-5d4bb358877a/images/39a25f0f-b3c2-47ef-bd03-c519a1f4637d/ff80b008-f387-47dd-8131-8f265f14c792': Bad file descriptor Jan 15 12:05:57 hostname NetworkManager[1650]: <warn> [1547571957.4383] ifcfg-rh: loading "/etc/sysconfig/network-scripts/ifcfg-Storage_SVIP" fails: Could not read file '/etc/sysconfig/network-scripts/ifcfg-Storage_SVIP': No such file or directory ~~~ (Originally by Amar Shah)
Amar, can you please help me to understand how the network was created, and if the related ifcfg file is still available? (Originally by Dominik Holler)
When a network is created via RHV, the networks names containing spaces should not be reach the host. Instead a vdsm network name like on$UUID is sent to the host by RHV-M. This is why I am in doubt, if the network is created by RHV. (Originally by Dominik Holler)
Hi Liz, do you have any recommendation how we could improve the RHV-M Admin Portal to prevent such misunderstandings in future? Thanks (Originally by Dominik Holler)
> Perhaps a middle ground would be a UI warning that using special characters will result in a UUID named network on the host? I'm no UX expert, but I think that we could show the "Vdsm Name" of the network with a little warning triangle in case onXXXXX is going to be used. (Originally by danken)
In a case like this we could include warning text below the 'Vdsm Name' field and list out the characters that the user can and cannot include in the name. It could be something along the lines of "Vdsm name can include uppercase, lowercase, number, and -,_,. characters Spaces cannot be included in the Vdsm name.' (Originally by Laura Wright)
Maybe we can add a warning to the text box of the name field to appear as the user type or after the user leaves the field saying that network name with spaces and exotic characters would result in different network name on the host, see vdsm name. (Originally by Marina Kalinin)
I agree this is a usability issue. (In reply to Laura Wright from comment #11) > In a case like this we could include warning text below the 'Vdsm Name' > field and list out the characters that the user can and cannot include in > the name. It could be something along the lines of "Vdsm name can include > uppercase, lowercase, number, and -,_,. characters Spaces cannot be included > in the Vdsm name.' Spaces are ok here, but they should certainly be trimmed from the end of the string, so that's a bug. (In reply to Marina from comment #12) > Maybe we can add a warning to the text box of the name field to appear as > the user type or after the user leaves the field saying that network name > with spaces and exotic characters would result in different network name on > the host, see vdsm name. Exactly, similar to what Dan said in Comment 9. This is a good solution. So we'll need to show "name" and "vdsm name" next to each other so user can clearly see the uuid one. @Dominik / Dan, I'm sure Laura would be happy to wireframe this if you need assistance. (Originally by Greg Sheremeta)
I would be happy to mock something up. Let me know if you would want to set up a call so we can talk about use case requirements. (Originally by Laura Wright)
Dominik, can you please assign this bug on the correct person. Thanks, (Originally by Michael Burman)
@Dominik Here is a link to some wireframes that feature the behavior of the name text field and an error message in the scenario of the user adding a space to the end of the network name. https://docs.google.com/document/d/1sAKBKhsq8Y1W4zM95yXwVMMAlmvO1JonHjoI5vpi7NE/edit?usp=sharing Let me know what you think! (Originally by Laura Wright)
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops (Originally by rhv-bugzilla-bot)
Verified on - rhvm-4.3.4-0.1.el7.noarch "Network names that contain spaces or are longer than 15 characters will be replaced with a UUID on the host." The next warning will appear under the Name field and in the blue information tooltip('i') with the same text. For networks with spaces, fancy char and long names. (Originally by Michael Burman)
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops (Originally by rhv-bugzilla-bot)
Verified according to comment #19
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:1566