Description of problem: Currently, engine does not block nor give a warning message while using IP addresses outside the defined netmask/subnet range. This tries to configure the logical network on host with all the variables but will fail to add the information in the DB making the UI to show a broken network icon, the Out-of-Sync Version-Release number of selected component (if applicable): ovirt-engine-4.1.2.3-0.1.el7.noarch vdsm-4.20.43-1.el7ev.x86_64 How reproducible: 100% Steps to Reproduce: 1. Create a new Logical Network 2. Configure the network on hypervisor with a gateway IP address outside the range defined on netmask/subnet. Use a /27 prefix for example. Actual results: Engine doesn't alert on this event and place the network in an out of sync status because the hypervisor has the gateway address information while the DB doesn't Expected results: Engine should block or give a message regarding the wrong configuration / calculation of addresses outside the range defined by the netmask/subnet used Additional info:
Why is this RFE and not a bug?
Feel free to remove the RFE component and make it a bug
Michael This sounds like a bug to me. Can you please check?
Laura, do you think it is enough to warn or block on UI, or do you think the warning should be on changes by REST API, too?
If it's a behavior thing I would recommend making changes to the REST API as well as giving the user warning or guidance in the UI. I would recommend adding a form error such as the one featured here: https://www.patternfly.org/v3/pattern-library/forms-and-controls/errors-and-validation/ We could also include an info tip next to the input field that features the input criteria for IP addresses and an example of one that fits the specified criteria.
(In reply to Laura Wright from comment #8) > If it's a behavior thing I would recommend making changes to the REST API as What kind of change do you recommend to the REST API? Rejecting the change would be not backward compatible. We could create an entry in the audit log (which might annoy the user). (I have myself no good idea how to handle this case, this is why I am asking. If we have no good idea here, we could just block in UI as you suggested) > well as giving the user warning or guidance in the UI. I would recommend > adding a form error such as the one featured here: > https://www.patternfly.org/v3/pattern-library/forms-and-controls/errors-and- > validation/ We could also include an info tip next to the input field that > features the input criteria for IP addresses and an example of one that fits > the specified criteria.
(In reply to Dominik Holler from comment #9) > (In reply to Laura Wright from comment #8) > > If it's a behavior thing I would recommend making changes to the REST API as > > > What kind of change do you recommend to the REST API? > Rejecting the change would be not backward compatible. We could create an > entry in the audit log (which might annoy the user). > (I have myself no good idea how to handle this case, this is why I am > asking. If we have no good idea here, we could just block in UI as you > suggested) > > > well as giving the user warning or guidance in the UI. I would recommend > > adding a form error such as the one featured here: > > https://www.patternfly.org/v3/pattern-library/forms-and-controls/errors-and- > > validation/ We could also include an info tip next to the input field that > > features the input criteria for IP addresses and an example of one that fits > > the specified criteria. In that case I would just recommend adding an inline error if that's easier.
(In reply to Laura Wright from comment #10) > (In reply to Dominik Holler from comment #9) > > (In reply to Laura Wright from comment #8) > > > If it's a behavior thing I would recommend making changes to the REST API as > > > > > > What kind of change do you recommend to the REST API? > > Rejecting the change would be not backward compatible. We could create an > > entry in the audit log (which might annoy the user). > > (I have myself no good idea how to handle this case, this is why I am > > asking. If we have no good idea here, we could just block in UI as you > > suggested) > > > > > well as giving the user warning or guidance in the UI. I would recommend > > > adding a form error such as the one featured here: > > > https://www.patternfly.org/v3/pattern-library/forms-and-controls/errors-and- > > > validation/ We could also include an info tip next to the input field that > > > features the input criteria for IP addresses and an example of one that fits > > > the specified criteria. > > In that case I would just recommend adding an inline error if that's easier. I understand that inline means only web UI. If not, please let me know. Thanks, Laura.
Yup inline for just web UI works for me. No problem! Thank you for bringing it up!
Hi Javier, After considering the most practical solution to the above problem, we suggest to implement a warning\info entry in the events tab in the web-admin (and in engine.log) if the user-configured ipv4 gateway is outside the subnet range. This entry will be submitted when the user invokes set-up networks. Is this acceptable from your point of view? Thanks
Hi Eitan, IMO the warn/info entry make sense in both UI and engine.log Thanks!
Javier, Do I understand you correctly that an entry in the engine.log and an entry in the events tab in web-admin is an acceptable solution and nothing else is required from your point of view? Thanks
Eitan, Yes, I think it would be good. My understanding is that once the user hits the `ok/save` button, which calls the setup networks, if the subnet is not correct, they will get a warning message.
Verified on - rhvm-4.4.1.2-0.10.el8ev.noarch We added new audit log in the UI notifications: "IPv4 gateway 5.4.5.254 is out of the subnet range defined by the IP address and netmask specified on ens4f1 in host <host_fqdn> of cluster Cluster1" Plus the exist out-of-sync event.
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