Description of problem: While using the Admin Portal to assign local networks to hosts, the user opens the *Edit Management Network* window, selects the *IPv6* tab, and enters the routing prefix in the *Routing Prefix* field. This fails. The field requires the routing prefix length, not the routing prefix. Version-Release number of selected component (if applicable): RHV 4.3 How reproducible: 100% Steps to Reproduce: 1. Open the *Edit Management Network* window 2. Selects the *IPv6* tab. 3. Enter the routing prefix in the *Routing Prefix* field. 4. Click OK. Actual results: Expected results: Additional info:
On *Edit Management Network* > *IPv4*, the parameter names (with example values) are as follows: IP: 10.10.176.1 Netmask / Routing Prefix: 255.255.248.0 Gateway: 10.10.183.254 *IP* could be improved to *IP Address*. Otherwise, these look correct. What do you think?
Netmask / Routing Prefix: 24 would be valid on IPv4, too. For the sake of consistency, I think we should use "Routing Prefix Lenght" in IPv4 and IPv6. Do you agree?
On *Edit Management Network* > *IPv6*, the parameter names (with example values) are as follows: Boot Protocol: [] None [] DHCP [] Stateless Address Autoconfiguration [] Static IP: Routing Prefix: Gateway: It seems like we could make the following improvements (Conform to Red Hat's IU guidelines and practices): * Remove or grey-out unsupported options such as None, DHCP, and Stateless Address Autoconfiguration. * Display Static as permanently pre-selected. * *IP* > *IP Address* * *Routing Prefix* > *Routing Prefix Lenth* What do you think?
(In reply to Dominik Holler from comment #4) > Netmask / Routing Prefix: 24 > would be valid on IPv4, too. > For the sake of consistency, I think we should use "Routing Prefix Lenght" > in IPv4 and IPv6. > Do you agree? That seems reasonable, but I'm not sure it's the best choice from a usability standpoint. Primarily, we should be consistent with users' habits and expectations, using the parameter name that requires the least thought or explanation. I'm not experienced enough in this field to recommend what that is, though.
Sharon, do you like to jump in and share the view from UX?
Laura, do you have any hints on this?
@Dominik can you attach of a screenshot of the scenario you are talking about so I can get a better sense of it?
Created attachment 1556132 [details] screenshots of current implementation 2019-04-18-ipv4-netmask.png shows the static IPv4 configuration using a netmask, 2019-04-18-ipv4-routingprefix.png shows the same IPv4 configuration using a routing prefix (length), 2019-04-18-ipv6-routingprefix.png shows the static IPv6 configuration, which requires a routing prefix (length).
Thanks, Laura. I am looking forward to hearing your point of view.
Is there a required number of characters a user must input in the routing prefix field for it to work?
(In reply to Laura Wright from comment #12) > Is there a required number of characters a user must input in the routing > prefix field for it to work? The input must not be empty. Does this answer your question?
Yes that answered my question:) I think in this case I would recommend adding a red asterisk that represents that the field is required and/or I would provide the user syntax hints to let them know what the field requirements are for routing prefix field. Are there any other specific requirements besides character length for the routing prefix input? Here are PatternFly examples of the patterns I'm talking about. https://imgur.com/a/14WHrAF PatternFly documentaiton: https://www.patternfly.org/pattern-library/forms-and-controls/field-labeling/#overview https://www.patternfly.org/pattern-library/forms-and-controls/help-on-forms/
Let's change just for IPv6 to "Routing Prefix Length"
Verified upstream on - 4.3.5-0.0.master.20190610085412.git42c7754.el7
Verified on 4.3.5-0.1.el7
This bugzilla is included in oVirt 4.3.5 release, published on July 30th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.5 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.