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:
(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?
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.
(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.
(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.
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.
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