Bug 1816057 - Falling back to DNS,TCP doesn't help for liveliness check of the host
Summary: Falling back to DNS,TCP doesn't help for liveliness check of the host
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: cockpit-ovirt
Classification: oVirt
Component: gluster-ansible
Version: 0.14.2
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ovirt-4.4.1
: ---
Assignee: Parth Dhanjal
QA Contact: SATHEESARAN
URL:
Whiteboard:
Depends On:
Blocks: 1816051
TreeView+ depends on / blocked
 
Reported: 2020-03-23 09:15 UTC by SATHEESARAN
Modified: 2020-07-09 11:28 UTC (History)
4 users (show)

Fixed In Version: cockpit-ovirt-0.14.8
Clone Of: 1816051
Environment:
Last Closed: 2020-07-08 08:27:21 UTC
oVirt Team: Gluster
Embargoed:
sasundar: ovirt-4.4?
sasundar: planning_ack?
godas: devel_ack+
sasundar: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 108004 0 None MERGED Updates to Consolidation Hosts and FQDNs 2020-07-09 11:26:53 UTC
oVirt gerrit 108484 0 None MERGED Fixing Single Node host tab 2020-07-09 11:26:53 UTC
oVirt gerrit 109114 0 None MERGED Fixing blacklist device when lvcache checked 2020-07-09 11:26:53 UTC

Description SATHEESARAN 2020-03-23 09:15:46 UTC
Description of problem:
-------------------------
Current implementation of the hosts tab is done such a way it falls through the validation below:
1. Check for hosts in known_hosts
2. Ping test
3. DNS test
4. TCP test

When 'ping' or 'ping6' test fails, then the check falls back to DNS and TCP test, which is not right and will not help in liveliness check for the hosts in place.


Version-Release number of selected component (if applicable):
--------------------------------------------------------------
cockpit-ovirt-dashboard-0.14.2-1

How reproducible:
------------------
Always

Steps to Reproduce:
-------------------
1. Start with Hyperconverged deployment from UI
2. Provide the FQDN of the host which is not reachable

Actual results:
---------------
When the host is not reachable, proceeding to next tab of deployment is allowed

Expected results:
------------------
When the host is not reachable, proceeding to next tab of deployment should be abandoned

Comment 1 SATHEESARAN 2020-04-21 07:33:52 UTC
Tested it with cockpit-ovirt-dashboard-0.14.5

Problem is that before the validation is complete, there is a window, in which the user could proceed to the next tab.
We need to implement the mechanism for the validation to complete early or make user wait before the validation is complete.

Though part of the bug is addressed with removing the fall back to DNS or ping, but the really expectation of validation 
of host liveliness is not satisfied.

Comment 2 SATHEESARAN 2020-06-03 10:28:17 UTC
Tested with cockpit-ovirt-dashboard-0.14.6, observed one specific problem

When for the second host, (i.e) second row, Storage FQDN is not reachable,
then the public FQDN is reachable, user could still proceed to the next tab.

So on any occasion, if the hostname is not reachable then the logic should not
allow to proceed to the next tab

Comment 3 Sandro Bonazzola 2020-06-04 12:05:58 UTC
Moving to 4.4.1 since 4.4.0 has been already released

Comment 4 SATHEESARAN 2020-06-16 02:43:47 UTC
I see that this issue is fixed with cockpit-ovirt-dashboard-0.14.8

@Gobinda, can you check why this bug is not yet ON_QA ?

Comment 5 Gobinda Das 2020-06-16 04:49:46 UTC
Moved to ON_QA

Comment 6 SATHEESARAN 2020-06-16 04:53:45 UTC
Tested with cockpit-ovirt-dashboard-0.14.8

1. when feeding the hostnames and clicking on 'Next' button triggers the host reachability check
When the host is not reachable, it throws appropriate errors.

2. when the host name is not added to SSH known_hosts file, then also it throws proper error messages

3. When the public network name is skipped, without selecting, use same hostname for Public and storage FQDN,
then also error pops up

Comment 7 Sandro Bonazzola 2020-07-08 08:27:21 UTC
This bugzilla is included in oVirt 4.4.1 release, published on July 8th 2020.

Since the problem described in this bug report should be resolved in oVirt 4.4.1 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.


Note You need to log in before you can comment on or make changes to this bug.