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:d...@redhat.com] 
Sent: Wednesday, January 14, 2015 2:21 PM
To: Donny Davis
Cc: Will K; users@ovirt.org
Subject: Re: [ovirt-users] Hosted-engine ISO domain

----- Original Message -----
> From: "Donny Davis" <do...@cloudspin.me>
> To: "Yedidyah Bar David" <d...@redhat.com>
> Cc: "Will K" <yetanotherw...@yahoo.com>, users@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

_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Reply via email to