[lago-devel] [ovirt-system-tests] What is the correct value of the engine's answer file entry OVESETUP_CONFIG/fqdn ?

[Yedidyah Bar David]

On Mon, Feb 22, 2016 at 9:36 AM, Yedidyah Bar David <didi at redhat.com> wrote:
> On Sun, Feb 21, 2016 at 5:57 PM, Yaniv Kaul <ykaul at redhat.com> wrote:
>> [ykaul at ykaul answer-files]$ pwd
>> /home/ykaul/ovirt-system-tests/common/answer-files
>> [ykaul at 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