Bug 1332927

Didi, can't this be fixed by using https://gerrit.ovirt.org/#/c/55479/ and just providing the answers which differ from the defaults?

(In reply to Fabian Deutsch from comment #1)
> Didi, can't this be fixed by using https://gerrit.ovirt.org/#/c/55479/ and
> just providing the answers which differ from the defaults?

Yes, that was the exact intention of this patch.

(In reply to Yedidyah Bar David from comment #2)
> (In reply to Fabian Deutsch from comment #1)
> > Didi, can't this be fixed by using https://gerrit.ovirt.org/#/c/55479/ and
> > just providing the answers which differ from the defaults?
> 
> Yes, that was the exact intention of this patch.

We need to ask questions on dwh, therefore I think it's good we hit this issue.

(In reply to Yaniv Dary from comment #3)
> (In reply to Yedidyah Bar David from comment #2)
> > (In reply to Fabian Deutsch from comment #1)
> > > Didi, can't this be fixed by using https://gerrit.ovirt.org/#/c/55479/ and
> > > just providing the answers which differ from the defaults?
> > 
> > Yes, that was the exact intention of this patch.
> 
> We need to ask questions on dwh, therefore I think it's good we hit this
> issue.

Do you mean that you object to using this "accept defaults" option, so that in the future, if we ask questions, it will fail again?

I do not think I agree.

IMO most users do not thoroughly read our questions, especially not after the first time they run setup. So if we think a question is important enough to require a conscious decision, we should not provide a default. If we do provide a default, it should be good enough for both uses that do not read our questions _and_ for an automated appliance setup inside hosted-engine-setup of ovirt-node.

s/ask questions/add questions/

We do not add questions in the setup to ignore them in the HE setup without good cause. The questions should be much the same for both.

The goal of the appliance is to have everything preconfigured and only ask the absolutely necessary questions.
That is the reason why we maintain a file with answers to common questions.

If DWH can be set up after the HE deployment, then just use the default (thus this new otopi key).

(In reply to Fabian Deutsch from comment #7)
> The goal of the appliance is to have everything preconfigured and only ask
> the absolutely necessary questions.
> That is the reason why we maintain a file with answers to common questions.
> 
> If DWH can be set up after the HE deployment, then just use the default
> (thus this new otopi key).

It can not be setuped after, it is need for dashboards after installation. Don't we ask the engine db location, application mode and so on in appliance deployment?

This looks like the vaslu is missing in the answer file generated by hosted engine setup.
I dont think it will be wise to force local warehouse generation in case of appliance.

Moving to hosted engine

(In reply to Yaniv Dary from comment #8)
> (In reply to Fabian Deutsch from comment #7)
> > The goal of the appliance is to have everything preconfigured and only ask
> > the absolutely necessary questions.
> > That is the reason why we maintain a file with answers to common questions.
> > 
> > If DWH can be set up after the HE deployment, then just use the default
> > (thus this new otopi key).
> 
> It can not be setuped after, it is need for dashboards after installation.
> Don't we ask the engine db location, application mode and so on in appliance
> deployment?

Of course not. If user runs hosted-engine --deploy with the appliance, and asks to automatically run engine-setup, we ask nothing in engine-setup itself. hosted-engine --deploy asks a few questions (such as admin password) and generates an answer file, which together with the answer file supplied inside the appliance, should run engine-setup unattended.

(In reply to Anatoly Litovsky from comment #9)
> This looks like the vaslu is missing in the answer file generated by hosted
> engine setup.
> I dont think it will be wise to force local warehouse generation in case of
> appliance.

Why not? It's mandatory now.

If you care about this due to extra load, note bug 1328805. I hope to finish with it today or tomorrow, and default to "Minimal" (decided to call it "Basic" for now, in case someone later on wants to add real "Minimal") if running on same machine as engine.

Verified on ovirt-engine-appliance-4.0-20160521.1.el7.centos.noarch

I can see problem returned under package ovirt-engine-appliance-4.0-20160529.1.el7.centos.noarch

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Artyom, do you have the hosted-engine-setup logs?

Created attachment 1163085 [details]
new hosted engine setup log

Unable to reprodice with oVirt Engine Appliance image (OVA) - 4.0-20160529.1.el7.centos

Artyom,
I saw that you have:

2016-05-30 19:16:31 DEBUG otopi.context context.dumpEnvironment:770 ENV OVEHOSTED_VM/cloudInitISO=str:'existing'

2016-05-30 19:16:31 DEBUG otopi.context context.dumpEnvironment:770 ENV OVEHOSTED_VM/vmCDRom=str:'/tmp/cloud-init/hosted-engine-automation.iso'

So you are not using the cloud-init ISO image generated by hosted-engine-setup but a custom one.
Are you sure that you have all the required answers there?

More precisely, you need to pass something like
 [environment:init]
 DIALOG/autoAcceptDefault=bool:True
are you?

Yes you are correct it was something that I missed in my code.

oVirt 4.0.0 has been released, closing current release.