Bug 1107772 - PRD35 - [RFE] At the end of the HE install wizard the default to install in "No", and if you choose it, it will forget all wizard settings.
Summary: PRD35 - [RFE] At the end of the HE install wizard the default to install in "...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-hosted-engine-setup
Version: 3.4.0
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
: 3.5.0
Assignee: Sandro Bonazzola
QA Contact: Nikolai Sednev
URL:
Whiteboard: integration
Depends On:
Blocks: rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2014-06-10 14:59 UTC by Nikolai Sednev
Modified: 2015-02-11 20:40 UTC (History)
13 users (show)

Fixed In Version: ovirt-3.5.0-beta1
Doc Type: Bug Fix
Doc Text:
Previously, the confirmation of installation settings in the hosted engine deployment wizard defaulted to 'No', which would require the whole deployment to be restarted if selected by accident. Now, the confirmation of installation settings defaults to 'Yes' and an answer file is created so that if the user does select 'No' the answer file can be used for skipping some of the setup.
Clone Of:
Environment:
Last Closed: 2015-02-11 20:40:13 UTC
oVirt Team: ---


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0161 normal SHIPPED_LIVE ovirt-hosted-engine-setup bug fix and enhancement update 2015-12-07 21:35:11 UTC
oVirt gerrit 28853 master MERGED packaging: setup: accept configuration by default Never
oVirt gerrit 28856 master MERGED packaging: setup: write answer file also on error Never

Description Nikolai Sednev 2014-06-10 14:59:09 UTC
Description of problem:
At the end of the HE install wizard the default to install in "No", and if you choose it, it will forget all wizard settings.
Please consider on changing the default to yes, as customer usually follows the "next, next, next" scenario and in case of pressing in such order will be thrown off the installation, it's bad OOB experience and we could also think on ask additional question regarding changing the specific parameters, instead of throwing off the customer from the deployment setup.

Version-Release number of selected component (if applicable):
libvirt-0.10.2-29.el6_5.8.x86_64
sanlock-2.8-1.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.415.el6_5.10.x86_64
vdsm-4.14.7-3.el6ev.x86_64
ovirt-hosted-engine-setup-1.1.2-5.el6ev.noarch
qemu-kvm-rhev-tools-0.12.1.2-2.415.el6_5.10.x86_64
qemu-img-rhev-0.12.1.2-2.415.el6_5.10.x86_64
ovirt-host-deploy-1.2.1-1.el6ev.noarch


How reproducible:
100%

Steps to Reproduce:
1.Start HE deployment and when getting to yes/no regarding all parameters, just press enter, when default set to "no".


Actual results:
Defaults set to "NO".

Expected results:
Defaults should be "YES" or at least customer shouldn't be thrown off the deployment procedure.

Additional info:

Comment 1 Sandro Bonazzola 2014-06-17 09:01:54 UTC
(In reply to Nikolai Sednev from comment #0)

> Please consider on changing the default to yes, as customer usually follows
> the "next, next, next" scenario and in case of pressing in such order will
> be thrown off the installation, it's bad OOB experience and we could also
> think on ask additional question regarding changing the specific parameters,
> instead of throwing off the customer from the deployment setup.

Well, the default to No was decided in order to avoid that a user follows the "next, next, next" scenario approving the setup without actually checking that everything is ok.

[cut]


> Defaults should be "YES" or at least customer shouldn't be thrown off the
> deployment procedure.

This can be done only adding a question like "Are you really sure you want to abort the setup?" after the first "No". But are we really sure we want to go that way?

Comment 2 Nikolai Sednev 2014-06-17 12:03:47 UTC
1.
Then why flows of HE and RHEVM setups aren't the same during their deployments? RHEVM steps are really common in their ending questions, only that in RHEVM it's OK instead of cancel by default, so it should be the same for HE as well, really don't see any difference here, customer should decide if to cancel the setup, next, next, next experience it terrible, just being thrown away from the whole bunch of previously set parameters, at least there have to be additional question, for if to exit the setup yes/no or at least a warning saying something like, "Warning! In case you're choosing "No", the setup will be terminated!"

2.
We don't have to throw away the customer at all, he/she can do that by himself/herself, ctrl+alt+c or any other sequence should be added and introduced to the customer right from the beginning of the whole deployment procedure, hence customer could exit whenever he decides to.

Comment 3 Sandro Bonazzola 2014-06-17 12:26:34 UTC
(In reply to Nikolai Sednev from comment #2)
> 1.
> Then why flows of HE and RHEVM setups aren't the same during their
> deployments? RHEVM steps are really common in their ending questions, only
> that in RHEVM it's OK instead of cancel by default, so it should be the same
> for HE as well, really don't see any difference here, customer should decide
> if to cancel the setup, next, next, next experience it terrible, just being
> thrown away from the whole bunch of previously set parameters, at least
> there have to be additional question, for if to exit the setup yes/no or at
> least a warning saying something like, "Warning! In case you're choosing
> "No", the setup will be terminated!"

I'm fine with defaulting to yes if pm acks.


> 2.
> We don't have to throw away the customer at all, he/she can do that by
> himself/herself, ctrl+alt+c or any other sequence should be added and
> introduced to the customer right from the beginning of the whole deployment
> procedure, hence customer could exit whenever he decides to.

For how otopi framework is designed, reached the end of customization phase we can't rollback the "wizard" at this point, so only option here is either accept values and go on or exit.

Comment 4 Nikolai Sednev 2014-06-17 17:25:13 UTC
(In reply to Sandro Bonazzola from comment #3)
> (In reply to Nikolai Sednev from comment #2)
> > 2.
> > We don't have to throw away the customer at all, he/she can do that by
> > himself/herself, ctrl+alt+c or any other sequence should be added and
> > introduced to the customer right from the beginning of the whole deployment
> > procedure, hence customer could exit whenever he decides to.
> 
> For how otopi framework is designed, reached the end of customization phase
> we can't rollback the "wizard" at this point, so only option here is either
> accept values and go on or exit.

Anyway customer have to be warned that cancelling will exit the deployment wizard and all parameters will be lost.

We possibly can consider on exiting and then auto entering to the deployment wizard using some loop mechanism, customer always knows how to exit using exit sequence.

Comment 5 Nikolai Sednev 2014-07-24 16:50:02 UTC
Verified on these components:
qemu-kvm-rhev-0.12.1.2-2.415.el6_5.12.x86_64
ovirt-hosted-engine-setup-1.2.0-0.1.master.el6.noarch
sanlock-2.8-1.el6.x86_64
ovirt-hosted-engine-ha-1.2.1-0.2.master.20140724142825.el6.noarch
ovirt-engine-sdk-python-3.5.0.3-1.el6.noarch
libvirt-0.10.2-29.el6_5.9.x86_64
ovirt-host-deploy-1.3.0-0.0.master.20140629072144.gitdc1f589.el6.noarch
Linux version 2.6.32-431.20.3.el6.x86_64

Must admit that deployment not finished successfully, yet this is not connected to this PRD initial request.

Comment 7 errata-xmlrpc 2015-02-11 20:40:13 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0161.html


Note You need to log in before you can comment on or make changes to this bug.