Bug 1666913
| Summary: | [UI] warn users about different "Vdsm Name" when creating network with a fancy char or long name | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | amashah | |
| Component: | ovirt-engine | Assignee: | Ales Musil <amusil> | |
| Status: | CLOSED ERRATA | QA Contact: | Michael Burman <mburman> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 4.2.7 | CC: | amashah, amusil, danken, dholler, gshereme, lsurette, lwright, mkalinin, mtessun, rdlugyhe | |
| Target Milestone: | ovirt-4.4.0 | Keywords: | ZStream | |
| Target Release: | 4.3.1 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | ovirt-engine-4.3.4 | Doc Type: | Enhancement | |
| Doc Text: |
With this enhancement, if a network name contains spaces or is longer than 15 characters, the Administration Portal notifies you that the RHV Manager will rename the network using the host network's UUID as a basis for the new name.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1717765 (view as bug list) | Environment: | ||
| Last Closed: | 2020-08-04 13:16:51 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | Network | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1717765 | |||
|
Description
amashah
2019-01-16 22:37:48 UTC
Amar, can you please help me to understand how the network was created, and if the related ifcfg file is still available? 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. Hi Liz, do you have any recommendation how we could improve the RHV-M Admin Portal to prevent such misunderstandings in future? Thanks > 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.
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.' 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. 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. 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. Dominik, can you please assign this bug on the correct person. Thanks, @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! 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
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.
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
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
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
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
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
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
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 (Important: RHV Manager (ovirt-engine) 4.4 security, bug fix, and enhancement update), 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-2020:3247 |