Created attachment 1389447 [details] localhost as fqdn Description of problem: Seen on node. The host fqdn has been correctly set installing the OS with anaconda. Last login: Thu Feb 1 11:00:49 2018 from t470s.localdomain node status: OK See `nodectl check` for more information Admin Console: https://192.168.1.248:9090/ [root@ngn42h1 ~]# hostnamectl Static hostname: ngn42h1.localdomain Icon name: computer-vm Chassis: vm Machine ID: c6caa35537a0428cb150a26320fcd27e Boot ID: f893197413324fba9c5d08900e8a2232 Virtualization: kvm Operating System: oVirt Node 4.2.1_rc4 CPE OS Name: cpe:/o:centos:centos:7 Kernel: Linux 3.10.0-693.17.1.el7.x86_64 Architecture: x86-64 cockpit wizard instead, see the attached screenshot, proposes 'localhost' as the default address for the host and it also accepts it. This will make the deployment fail for sure since the host will try to add itself to the engine as localhost with predictable bad results. Version-Release number of selected component (if applicable): 0.11.7 How reproducible: ? Steps to Reproduce: 1. try to deploy hosted-engine from cockpit 2. 3. Actual results: cockpit proposes localhost as the host address instead of the real host address Expected results: cockpit proposes a valid address and the address should be validated: it should not be localhost and it should resolve just on the selected interface. Additional info:
Currently, the wizard is using "hostname --fqdn" to retrieve the hostname. It seems that this is returning a different result than hostnamectl for some reason. I suppose I could use hostnamectl and parse the result. Do you know of a cleaner and reliable way of getting the hostname without having to parse it out?
It's available over dbus, which is by far the easiest way in cockpit
Simone - Do you actually have working DNS resolution on that system? For example: [root@nodeng hostedEngineAnsibleFiles]# hostnamectl Static hostname: localhost.localdomain Transient hostname: nodeng Icon name: computer-vm Chassis: vm Machine ID: 4f4b6603871547009d5a8a76c87a2ec9 Boot ID: d1296db3ddff4150a66be408c3fa6ec6 Virtualization: kvm Operating System: Red Hat Virtualization Host 4.2.1 (el7.4) CPE OS Name: cpe:/o:redhat:enterprise_linux:7.4:beta:hypervisor Kernel: Linux 3.10.0-693.17.1.el7.x86_64 Architecture: x86-64 [root@nodeng hostedEngineAnsibleFiles]# hostname --fqdn nodeng.nested [root@nodeng hostedEngineAnsibleFiles]# domainname (none) In this case, hostnamectl is 'wrong' and hostname --fqdn is 'right'. hostnamectl correctly interprets the transient hostname, at least, but we must decide what the failure cases are. And we'd need to stick a domainname on the end Is transient hostname (DNS lookup) enough? If it's empty, do we trust that static resolution and DNS resolution will match, and only fail if they do not? It's a surprisingly tricky area. What are the requirements from hosted engine itself, and what are we willing to set as support? Transient/"short" hostname works as long as resolv.conf has the right 'search' domain. FQDN is better. But it may be surprising to users that they need to set the FQDN themselves if they have a DHCP reservation with working RDNS.
I believe Simone is working on a playbook to handle this issue. Once that's complete, Cockpit can be updated to use it instead of the current mechanism.
Is this on track to 4.2.2? If not, please defer to 4.2.3.
Tested with these versions: rhvh-4.2.2.0-0.20180322.0+1 cockpit-ovirt-dashboard-0.11.19-1.el7ev.noarch ovirt-hosted-engine-setup-2.2.14-1.el7ev.noarch ovirt-hosted-engine-ha-2.2.7-1.el7ev.noarch rhvm-appliance-4.2-20180322.0.el7.noarch If use the localhost as the host fqdn, this will make the deployment fail for sure since the host will try to add itself to the engine as localhost with predictable bad results. On the HE-VM: [root@enginevm ~]# cat /etc/hosts 127.0.0.1 enginevm.localdomain localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.73.73.19 localhost
Now ansible playbook will validate the hostname eventually failing with a clear error message. The cockpit wizard could also explicitly call validate_hostnames.yml playbook to validate host address and the engine VM FQDN entered by the user before starting the deployment.
Simone, We still need a reliable way to retrieve the hostname, since the current method only pulls the correct hostname some of the time. See comment 3 above from Ryan. I mistakenly thought this was part of the playbook you were working on. Do you know a method to do this, and if so, how hard would it be to provide that functionality in a playbook?
Simone gave me a pointer to where this is handled in otopi, and I've been trying to fit a python oneliner into cockpit.spawn(), but this is very ugly due to formatting problems between ES6 and Python. Let's see if we can break out the otopi logic into a playbook
Cumulatively, the patches pushed above provide the following functionality: On wizard load: - The host FQDN should be validated automatically -- If validation fails, the "Advanced" section should open automatically, a warning message should be displayed at the top of the screen, and an error message should be displayed beneath the "Host FQDN" field On field update: - Validation does not occur until the field loses focus -- Once the field loses focus, validation should begin and a spinner and the text "Validating" should appear to the right of the input field --- The spinner and label should disappear once validation is complete (completion can be verified in the console) --- If validation fails, an error message should appear beneath the field - If a given input has failed validation, and the user enters the field and exits it again, it should be revalidated - If the field passed validation, entering and exiting the field should not cause revalidation to occur On move to the next step: - If both fields have already been validated successfully, they should not be revalidated - If either or both of the fields have not been validated or have failed validation, validation should be started for that field, a warning message instructing the user to wait for validation to complete should be displayed at the top of the screen, and the user should not be allowed to progress to the next step until validation has completed -- If the field(s) being validated fails validation, an error message should appear beneath the field - If the user attempts to move to the next step while validation is occurring, a warning message should display at the top of the screen instructing the user to wait for validation to complete and then try again
(In reply to Phillip Bailey from comment #8) > Simone, > > We still need a reliable way to retrieve the hostname, since the current > method only pulls the correct hostname some of the time. See comment 3 above > from Ryan. I mistakenly thought this was part of the playbook you were > working on. Do you know a method to do this, and if so, how hard would it be > to provide that functionality in a playbook? It has been decided that the current method of pulling the host FQDN on wizard load is sufficient. The intermittent problem of getting localhost instead of the expected FQDN appears to have been due to a problem unrelated to the wizard.
Created attachment 1478876 [details] cockpit_fqdn_validate
Tested with cockpit-ovirt-dashboard-0.11.33-1.el7ev.noarch, When loading wizad, cockpit will validate the Host FQDN. see attachment 1478876 [details]