Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1665467

Summary: Support host_name != host_address
Product: [oVirt] ovirt-hosted-engine-setup Reporter: Simone Tiraboschi <stirabos>
Component: GeneralAssignee: Simone Tiraboschi <stirabos>
Status: CLOSED CURRENTRELEASE QA Contact: Nikolai Sednev <nsednev>
Severity: unspecified Docs Contact:
Priority: urgent    
Version: 2.3.0CC: bugs
Target Milestone: ovirt-4.3.0Keywords: AutomationBlocker, Triaged
Target Release: ---Flags: rule-engine: ovirt-4.3+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovirt-hosted-engine-setup-2.3.1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-02-13 07:43:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Integration RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Simone Tiraboschi 2019-01-11 14:00:30 UTC
Description of problem:
As for https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/issues/30 , in ovirt-ansible-hosted-engine-setup we are currently not supporting a custom host name which is different from host_address.

This is not affecting interactive executions over CLI or cockpit since by default we have:
        if not self.environment[
            ohostedcons.EngineEnv.APP_HOST_NAME
        ]:
            self.environment[
                ohostedcons.EngineEnv.APP_HOST_NAME
            ] = socket.gethostname()
as for https://github.com/oVirt/ovirt-hosted-engine-setup/blob/master/src/plugins/gr-he-common/network/bridge.py#L211

While it's breaking executions from answer file with a custom value for OVEHOSTED_ENGINE/appHostName 


Version-Release number of selected component (if applicable):


How reproducible:
100% if deploying with answerfile with a custom value for OVEHOSTED_ENGINE/appHostName, not reproducible running the setup interactively. 

Steps to Reproduce:
1. Deploy with an answerfile containing a custom value (!= host_address) for OVEHOSTED_ENGINE/appHostName


Actual results:

A failure with:
2019-01-11 14:17:11,573+0200 INFO otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:100 TASK [oVirt.hosted-engine-setup : Get host address resolution]
2019-01-11 14:17:12,475+0200 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:94 {u'_ansible_parsed': True, u'stderr_lines': [], u'cmd': u'getent ahosts host_mixed_1 | grep host_mixed_1', u'end': u'2019-01-11 14:17:12.306605', u'_ansible_no_log': False, u'stdout': u'', u'changed': True, u'start': u'2019-01-11 14:17:11.911273', u'delta': u'0:00:00.395332', u'stderr': u'', u'rc': 1, u'invocation': {u'module_args': {u'warn': True, u'executable': None, u'_uses_shell': True, u'_raw_params': u'getent ahosts host_mixed_1 | grep host_mixed_1', u'removes': None, u'argv': None, u'creates': None, u'chdir': None, u'stdin': None}}, u'stdout_lines': [], u'msg': u'non-zero return code'}
2019-01-11 14:17:12,576+0200 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:94 ignored: [localhost]: FAILED! => {"changed": true, "cmd": "getent ahosts host_mixed_1 | grep host_mixed_1", "delta": "0:00:00.395332", "end": "2019-01-11 14:17:12.306605", "msg": "non-zero return code", "rc": 1, "start": "2019-01-11 14:17:11.911273", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}

Expected results:
It successfully completes the setup with a custom host-name

Comment 2 Nikolai Sednev 2019-02-11 12:37:32 UTC
Worked well on these components:
ovirt-hosted-engine-ha-2.3.1-1.el7ev.noarch
ovirt-hosted-engine-setup-2.3.3-1.el7ev.noarch
rhvm-appliance-4.3-20190201.0.el7.x86_64

I used "OVEHOSTED_ENGINE/appHostName=str:kingkong" line in answerfile during deployment and when it done, I checked for "kingkong" name was set on host in UI and it was set properly.
Moving to verified.

Comment 3 Sandro Bonazzola 2019-02-13 07:43:18 UTC
This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019.

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