[ovirt-users] Hosted-engine ISO domain

[Donny Davis]

Makes sense to me, thanks for helping to clarify. 
Will, I hope we have been of some help

Donny D 

-----Original Message-----
From: Yedidyah Bar David [mailto:didi at redhat.com] 
Sent: Wednesday, January 14, 2015 2:21 PM
To: Donny Davis
Cc: Will K; users at ovirt.org
Subject: Re: [ovirt-users] Hosted-engine ISO domain

----- Original Message -----
> From: "Donny Davis" <donny at cloudspin.me>
> To: "Yedidyah Bar David" <didi at redhat.com>
> Cc: "Will K" <yetanotherwill at yahoo.com>, users at ovirt.org
> Sent: Wednesday, January 14, 2015 10:52:20 PM
> Subject: RE: [ovirt-users] Hosted-engine ISO domain
> 
> I think it is in the answer file
> /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf
> OVESETUP_CONFIG/isoDomainExists=bool:True

/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf is not "the answer file". The answer file is the file written to /var/lib and mentioned in the end of engine-setup, e.g.:

[ INFO  ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20141124180159-setup.conf'

As I wrote, this file (called in the sources "postinstall") should be treated as internal data. It's used to keep some state of engine-setup between runs.

Just the same way you are not expected normally to manually edit tables inside the db, you should not change this file, or copy parts of it to the answer file. Of course, sometimes it can be useful, and sometimes people here will suggest that, but generally speaking, if you had to do that, that's a bug.

BTW, editing generated answer files is also not recommended and not "officially" supported.

The expected way to use an answer file is:
1. Have a system A in some state S0
2. Run engine-setup interactively, answer its questions as needed, let it create an answer file Ans1.
3. System A is now in state S1.
4. Have some other system B in state S0, that you want to bring to state S1.
5. Run there engine-setup with --config-append=Ans1

Of course, editing answer files usually works, and in some cases you can achieve useful things this way that can't be done by mere interactive run. But whenever you do that, it's your own responsibility.
Test first on a test system, make sure it does exactly what you wanted/ expected, then use in production.

Just as an example for a simple and useful violation, if during testing you often run engine-setup on systems with little RAM, and want to get rid of the question if you want to continue with not enough RAM, you can create a file e.g. /etc/ovirt-engine-setup.conf.d/99-my-stuff.conf
with content:
[environment:default]
OVESETUP_SYSTEM/memCheckEnabled=bool:False

As I said, this is not recommended - use at your own risk, test and know what you are doing!

(the above should probably be in the wiki somewhere. Hopefully the mailing list archives are almost as good)

> 
> You are correct about the iso domain not being available until the 
> data center is up, and this requires a data domain. He had said in an 
> earlier thread he does not see it in the UI at all.
> 
> I'm no expert, just speaking from my experiences with ovirt.

Hey, didn't intend to be offensive - thanks for trying to help!
That's much appreciated. Hope now things are clearer.

Best,
--
Didi