On Mon, Feb 22, 2016 at 9:36 AM, Yedidyah Bar David <didi(a)redhat.com> wrote:
On Sun, Feb 21, 2016 at 5:57 PM, Yaniv Kaul <ykaul(a)redhat.com>
> [ykaul@ykaul answer-files]$ pwd
> [ykaul@ykaul answer-files]$ grep -R "OVESETUP_CONFIG/fqdn" * |sort
> 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.
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
This was done for these bugs:
You won't find references to them in current code's commit messages
because it was rewritten for 3.3:
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  asking to prevent that
for the _engine_ fqdn.
The code doing this was originally written inside that git repo,
hardcoding 'localhost' .
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  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. .
Bottom line - don't do that:
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 . 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  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.