Bug 1107772
Summary: | 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. | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Nikolai Sednev <nsednev> |
Component: | ovirt-hosted-engine-setup | Assignee: | Sandro Bonazzola <sbonazzo> |
Status: | CLOSED ERRATA | QA Contact: | Nikolai Sednev <nsednev> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 3.4.0 | CC: | aburden, bazulay, didi, dougsland, gklein, iheim, lveyde, nsednev, pstehlik, rbalakri, Rhev-m-bugs, stirabos, yeylon |
Target Milestone: | --- | Keywords: | FutureFeature, Improvement, Triaged |
Target Release: | 3.5.0 | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | integration | ||
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.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2015-02-11 20:40:13 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1142923, 1156165 |
Description
Nikolai Sednev
2014-06-10 14:59:09 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? 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 |