[ovirt-users] list of answer file parameters?

[Yedidyah Bar David]

----- Original Message -----
> From: "Jorick Astrego" <j.astrego at netbulae.eu>
> Cc: users at ovirt.org
> Sent: Friday, August 15, 2014 3:32:09 PM
> Subject: Re: [ovirt-users] list of answer file parameters?
> 
> 
> On 08/15/2014 02:21 PM, Yedidyah Bar David wrote:
> > ----- Original Message -----
> >> From: "Alon Bar-Lev" <alonbl at redhat.com>
> >> To: "Jorick Astrego" <j.astrego at netbulae.eu>
> >> Cc: users at ovirt.org
> >> Sent: Friday, August 15, 2014 1:59:41 PM
> >> Subject: Re: [ovirt-users] list of answer file parameters?
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Jorick Astrego" <j.astrego at netbulae.eu>
> >>> To: users at ovirt.org
> >>> Sent: Friday, August 15, 2014 1:27:23 PM
> >>> Subject: [ovirt-users] list of answer file parameters?
> >>>
> >>> Hi,
> >>>
> >>> I'm looking everywhere for a full list of "OVESETUP" parameters that can
> >>> be used in the installer answerfile.
> >>>
> >>> Searched the red hat manual and found some in:
> >>>
> >>> "3.6. Passwords in Red Hat Enterprise Virtualization Manager"
> >>>
> >>> But there are more. I can get it from a finished install but some
> >>> parameters only apply to some types of installation.
> >>>
> >>> I found this one form lzap:
> >>>
> >>> https://gist.github.com/lzap/7a8cbb7f44d41e4ad171
> >>>
> >>> But I don't know if it's complete or just for his personal use.
> >>>
> >>> No hurry, I know you are all busy ;-)
> >>>
> >> Hi,
> >>
> >> The simplest way is to perform setup and record the answer file.
> >>
> >> You can even <Ctrl>C at the summary confirmation question and answer file
> >> will be generated for you without installing anything.
> >>
> >> Full list is available at
> >> /usr/share/ovirt-engine/setup/ovirt_engine_setup/,
> >> seek *.py and look for @osetupattrs with answerfile=True. Maybe in future
> >> we
> >> can have utility to extract all with description.
> > Also note:
> >
> > 1. The files there are separated between different packages, so you'll not
> > necessarily have all, if you did not install some optional ones.
> >
> > 2. Not all combinations are supported, and in principle it's possible to
> > manually
> > create answer files that will cause setup to fail, or even to succeed but
> > leave
> > an unsupported, unexpected system setup. I started writing about this some
> > time
> > ago in [1] but got stuck in the middle, and Alon said I should not call it
> > Otopi
> > because it does not document Otopi but engine-setup, and he is largely
> > right.
> > See also [2], which is not directly related (key is not answerfile=True),
> > but does
> > give a relevant example.
> >
> > [1] http://www.ovirt.org/Otopi
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1101001
> Yes that was my problem, I was trying to do AIO install but
> engine-cleanup didn't work because a version mismatch.

Perhaps because you upgraded ovirt-engine-setup without running engine-setup.
You should have been able to fix by downgrading it.

> 
> So I tried removing everything by hand but the installer never asked me
> the install local VDSM question... Then I thought I'd get smart and just

Perhaps you did not have the allinone plugin itself? Or removed its
/etc/ovirt-engine-setup.conf.d/10-packaging-aio.conf ?
Or something like that?

> edit the answer the installer generated and add the AIO lines to it.
> But nearly all the settings are undocumented so I had to resort to
> searching on what to set them to on pastebin etc. In the end, I
> reinstalled the host as it was quicker to do a fresh install.
> 
> Also I want to create puppet files and deploy engine through foreman.
> 
> I think as a workaround, I'll do a couple of different installs and rip
> the generated answer file from them. But when a new parameter get's
> introduced, I will never know about it until I run into an issue.

I think that using the kept files during the same minor (e.g. generate
on 3.4.2, use for 3.4.3) should usually be safe (but not always). When
upgrading to 3.5, I suggest to run again interactively to generate new
answer files.

> 
> Something like "ovirt-installer --list-answerfile" should be possible
> IMHO, as the installer uses and verifies the parameters on install. I'm
> not a programmer but it should be able to spit out a list them.

We had several discussions in the past re this.

We'd rather not do that. Main reason is what I explained above - some
combinations will not work well.

I think the main flows to using answer files are:

1. Most common - you have a specific env you want to be able to generate
(including specific packages/plugins installed, specific answers you want
to give etc). You just run engine-setup interactively and keep the
generated answer file, and do not edit it. It will in principle be good
only for an exact copy (same versions of packages etc.).

2. You do some testing of engine-setup and need to run it lots of times,
interactively, and just not want to have to answer all the questions, just
some of them. So you run engine-setup, edit the answer file and remove the
answers you want to give interactively and use that.

3. Similar to 2. above, but you just want to keep very few answers (such
as the one for the question warning you against running setup with not
enough memory :-) ). So you keep a very small answer file and either
press Enter to accept defaults or fill in answers you want to test interactively.

Of course, if you have a question regarding a specific key, you are welcome
to ask, and/or search for it in the python files and try to understand how
it's used (for many, it's easy to understand).
-- 
Didi