[ovirt-system-tests] What is the correct value of the engine's answer file entry OVESETUP_CONFIG/fqdn ?
[ykaul@ykaul answer-files]$ pwd /home/ykaul/ovirt-system-tests/common/answer-files [ykaul@ykaul answer-files]$ grep -R "OVESETUP_CONFIG/fqdn" * |sort el6_3.5.conf:OVESETUP_CONFIG/fqdn=str:engine el6_3.6.conf:OVESETUP_CONFIG/fqdn=str:*localhost.localdomain* el6_master.conf:OVESETUP_CONFIG/fqdn=str:engine el7_3.5.conf:OVESETUP_CONFIG/fqdn=str:engine el7_master.conf:OVESETUP_CONFIG/fqdn=str:engine Is the value localhost.localdomain correct for el6-3.6 (only?). TIA, Y.
On Sun, Feb 21, 2016 at 5:57 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
[ykaul@ykaul answer-files]$ pwd /home/ykaul/ovirt-system-tests/common/answer-files [ykaul@ykaul answer-files]$ grep -R "OVESETUP_CONFIG/fqdn" * |sort el6_3.5.conf:OVESETUP_CONFIG/fqdn=str:engine el6_3.6.conf:OVESETUP_CONFIG/fqdn=str:localhost.localdomain el6_master.conf:OVESETUP_CONFIG/fqdn=str:engine el7_3.5.conf:OVESETUP_CONFIG/fqdn=str:engine el7_master.conf:OVESETUP_CONFIG/fqdn=str:engine
Is the value localhost.localdomain correct for el6-3.6 (only?).
The correct value is the name you want to use in your browser to connect to the web interface. "localhost.localdomain" can work, for this usage, if you connect locally - with the browser running on the engine machine. Otherwise it will obviously not work (with normal settings - of course you can edit your local /etc/hosts to point this name at the engine machine, and potentially break other local services that expect this name to point to local machine). If you intend to ask if it's "valid", then it's a bit more complex. AFAICS, in engine-setup we never had 'localhost' hard-coded. There was code that prevents something more general if a certain env key was set (e.g. in an answer file), e.g. OVESETUP_CONFIG/fqdnNonLoopback=bool:True By default, it was set only if the all-in-one plugin was installed and configured (i.e. if you replied 'yes' to 'configure vdsm on this host?'). ( This was done for these bugs: https://bugzilla.redhat.com/show_bug.cgi?id=928667 https://bugzilla.redhat.com/show_bug.cgi?id=948311 You won't find references to them in current code's commit messages because it was rewritten for 3.3: https://gerrit.ovirt.org/14889 https://gerrit.ovirt.org/14699 ) In master (4.0), all-in-one is dropped. You can still set the key. In <=3.6 we still have all-in-one (announced deprecated). In ovirt-hosted-engine-setup we had a bug [1] asking to prevent that for the _engine_ fqdn. The code doing this was originally written inside that git repo, hardcoding 'localhost' [2]. Later it was moved to ovirt-setup-lib, and the code there was largely copied from engine-setup code (which was a bit more general), also going through a series of fixes - see [3][4][5] or just the current code. Currently, both engine-setup and ovirt-hosted-engine-setup call ovirt-setup-lib. So ovirt-hosted-engine-setup should prevent that for the engine fqdn in all (recent) versions. We also have other related issues, e.g. [6]. [1] https://bugzilla.redhat.com/1234870 [2] https://gerrit.ovirt.org/42751 [3] https://gerrit.ovirt.org/43856 [4] https://gerrit.ovirt.org/49228 [5] https://gerrit.ovirt.org/49326 [6] https://bugzilla.redhat.com/show_bug.cgi?id=1226910 Bottom line - don't do that: https://tools.ietf.org/html/rfc1178 -- Didi
On Mon, Feb 22, 2016 at 9:36 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Sun, Feb 21, 2016 at 5:57 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
[ykaul@ykaul answer-files]$ pwd /home/ykaul/ovirt-system-tests/common/answer-files [ykaul@ykaul answer-files]$ grep -R "OVESETUP_CONFIG/fqdn" * |sort el6_3.5.conf:OVESETUP_CONFIG/fqdn=str:engine el6_3.6.conf:OVESETUP_CONFIG/fqdn=str:localhost.localdomain el6_master.conf:OVESETUP_CONFIG/fqdn=str:engine el7_3.5.conf:OVESETUP_CONFIG/fqdn=str:engine el7_master.conf:OVESETUP_CONFIG/fqdn=str:engine
Is the value localhost.localdomain correct for el6-3.6 (only?).
The correct value is the name you want to use in your browser to connect to the web interface.
"localhost.localdomain" can work, for this usage, if you connect locally - with the browser running on the engine machine. Otherwise it will obviously not work (with normal settings - of course you can edit your local /etc/hosts to point this name at the engine machine, and potentially break other local services that expect this name to point to local machine).
If you intend to ask if it's "valid", then it's a bit more complex.
AFAICS, in engine-setup we never had 'localhost' hard-coded.
There was code that prevents something more general if a certain env key was set (e.g. in an answer file), e.g. OVESETUP_CONFIG/fqdnNonLoopback=bool:True
By default, it was set only if the all-in-one plugin was installed and configured (i.e. if you replied 'yes' to 'configure vdsm on this host?').
( This was done for these bugs: https://bugzilla.redhat.com/show_bug.cgi?id=928667 https://bugzilla.redhat.com/show_bug.cgi?id=948311
You won't find references to them in current code's commit messages because it was rewritten for 3.3: https://gerrit.ovirt.org/14889 https://gerrit.ovirt.org/14699 )
In master (4.0), all-in-one is dropped. You can still set the key. In <=3.6 we still have all-in-one (announced deprecated).
In ovirt-hosted-engine-setup we had a bug [1] asking to prevent that for the _engine_ fqdn.
The code doing this was originally written inside that git repo, hardcoding 'localhost' [2].
Later it was moved to ovirt-setup-lib, and the code there was largely copied from engine-setup code (which was a bit more general), also going through a series of fixes - see [3][4][5] or just the current code. Currently, both engine-setup and ovirt-hosted-engine-setup call ovirt-setup-lib. So ovirt-hosted-engine-setup should prevent that for the engine fqdn in all (recent) versions.
We also have other related issues, e.g. [6].
[1] https://bugzilla.redhat.com/1234870 [2] https://gerrit.ovirt.org/42751 [3] https://gerrit.ovirt.org/43856 [4] https://gerrit.ovirt.org/49228 [5] https://gerrit.ovirt.org/49326 [6] https://bugzilla.redhat.com/show_bug.cgi?id=1226910
Bottom line - don't do that: https://tools.ietf.org/html/rfc1178 -- Didi
BTW, since we are discussing this in the context of lago, I can see few reasonable approaches. Considering I do not know how lago works: 1. Have a fixed hostname for the engine machine, hard-code it in /etc/hosts (and/or some simple dns server - is that in the scope of lago?) and in the answer file. 2. Create the answer file (from a template, replacing only what's needed) during run-time, with correct value as relevant 3. Since engine-setup defaults to the current hostname, make sure this one is reasolvable, do not supply an fqdn in the answerfile at all, and instead fix [1]. Will only work for fixed versions, though, after we fix it. 4. Similar to (3.), more complex, but more general: Have lago support otopi machine dialog interaction instead of (or in addition to) answer files. We have a pending patch [2] to add python code for this, in addition to the existing java code used in the engine. IIUC QE already uses this code internally for testing. This is probably semi-mandatory in the long-run, because in principle we want to test also real-world flows that use interaction, and the code behaves a bit differently compared to using answer files. So we do need both. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1270719 [2] https://gerrit.ovirt.org/28180 -- Didi
participants (2)
-
Yaniv Kaul -
Yedidyah Bar David