Bug 1877838

*** Bug 1884989 has been marked as a duplicate of this bug. ***

Can you please describe what was fixed?

Cause in the example from here: https://github.com/mareklibra/facet-lib/pull/259, the UI show an error message, but contain incorrect suggestion ("..must be between 1 to 25"). 
If user try to save with CIDR: 172.30.0.0/1, it correctly gets an error from BE:
172.30.0.0/1 is not a valid network CIDR
So it is better to not suggest, or suggest a correct suggestion

In addition, there are cases where im not sure what need to be enforced by UI and what by BE (I have a test for validating this Networking settings, with as much as possible end cases and there are cases where UI should enforce but, it doesn't: https://polarion.engineering.redhat.com/polarion/redirect/project/OSE/wiki/Install-validation%20_%20BM-Inventory/Assisted%20Install%20validation%20BM%20Inventory%20-%20E2E?selection=OCP-34222)

(In reply to Lital Alon from comment #3)
> Can you please describe what was fixed?
> 
> Cause in the example from here:
> https://github.com/mareklibra/facet-lib/pull/259, the UI show an error
> message, but contain incorrect suggestion ("..must be between 1 to 25"). 
> If user try to save with CIDR: 172.30.0.0/1, it correctly gets an error from
> BE:
> 172.30.0.0/1 is not a valid network CIDR
> So it is better to not suggest, or suggest a correct suggestion

@lalon This bug has been filed because UI validations for advanced fields did not match the backend validations. That is what the linked PR fixes. If certain validation message does not match the expectation written in the test plan, please file a new bug specific to that. I don't think a validation message is valid to make this bug fail QA as the goal is to align the validations with backend.

> 
> In addition, there are cases where im not sure what need to be enforced by
> UI and what by BE (I have a test for validating this Networking settings,
> with as much as possible end cases and there are cases where UI should
> enforce but, it doesn't:
> https://polarion.engineering.redhat.com/polarion/redirect/project/OSE/wiki/
> Install-validation%20_%20BM-Inventory/
> Assisted%20Install%20validation%20BM%20Inventory%20-%20E2E?selection=OCP-
> 34222)

It would be really helpful if you could list these cases where UI does not enforce but doesn't.

Right so it wasn't clear to me what was fixed and what need to be tested as part of this bug, in order to be able to mark as verify.
Ill open a bug when ill find anything specific. As for this bug - the only thing left is the scenario where:
Service Network CIDR \ Cluster Network CIDR set to: 10.128.0.0/31, UI propmt a msg: "IPv4 netmask must be between 1-25 and include at least 128 addresses. IPv6 netmask must be between 8-128 and include at least 256 addresses"
The issue: 10.128.0.0/1 is an illegal suggestion, in fact 1, 2, 3, 4 and more are illegal, so the orig suggestion is wrong. What can we do about it?

The behavior described above actually seems to reflect a flaw in the design of the validation for the CIDR fields.

Right now the front-end validates the CIDR fields by testing, among other things, the prefix length is a number between 1 and 25.
However if the user enters a value like "10.128.0.0/1" and attempts to save and validate the form, the back-end responds with this error: "address must not be unspecified. Unspecified address is the address with all zeroes"

This message is problematic in many forms:
1. Is not clear how by specifying this value: "10.128.0.0/1" we ended up showing an error regarding the "Unspecified Address (0.0.0.0)".
2. Also, is not clear which CIDR field has an incorrect value.

The error message could be improved by mentioning that the "unspecified address" in the current message refers to the "resulting network address". The resulting network address is obtained by performing an AND operation between the IP part of the CIDR string and the netmask; which is obtained from the number after the slash '/' (see RFCs 4632, 4291).

Since this is a back-end validation issue, we'll track its progress here: https://bugzilla.redhat.com/show_bug.cgi?id=1928515

1. As agreed the error message needs will be changed to: "The specified CIDR is invalid because its resulting routing prefix matches the unspecified address." 
2. UI will add an additional validation that will check if the resulting routing prefix is "0.0.0.0" or "::"

I've added also an additional validation (stolen from the BE logic) which checks if the IP part of the CIDR value matches the first address (the one used to represent the network) in the range specified by the CIDR notation.

Created attachment 1760369 [details]
screen shot of false validation success on CID prefix

In the case where the resulting network address after applying the mask is the unspecified address (0.0.0.0) e.g 10.128.1.0/[1-4] the validation error displayed is "The specified CIDR is invalid because its resulting routing prefix matches the unspecified address." As expected.


However in the case of CIDR_prefix > 25 the validation on the Cluster Network CIDR passes and the user recives a validation error on the Cluster Network Host Prefix "The host prefix is a number between size of the cluster network CIDR range (26) and 25." e.g. "Cluster Network CIDR":10.128.1.0/26 "Cluster Network Host Prefix":25 (screen shot attached)

Therefore I am failing the validation on this bug

Fixed in [PR 495](https://github.com/openshift-assisted/assisted-ui-lib/pull/495)

Verified on Staging 
Assisted-ui-lib version:  1.5.11