Bug 1149575
| Summary: | engine-setup accepts an answer file with an invalid value for applicationMode | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Ulhas Surse <usurse> | |
| Component: | ovirt-engine | Assignee: | Simone Tiraboschi <stirabos> | |
| Status: | CLOSED ERRATA | QA Contact: | Gonza <grafuls> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | high | |||
| Version: | 3.4.0 | CC: | amureini, bazulay, didi, iheim, juwu, kmayilsa, lpeer, lsurette, lveyde, oourfali, pstehlik, rbalakri, Rhev-m-bugs, sabose, sbonazzo, stirabos, tnisan, usurse, yeylon, ykaul, ylavi | |
| Target Milestone: | ovirt-3.6.0-rc | Keywords: | ZStream | |
| Target Release: | 3.6.0 | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: |
Previously, when running engine-setup with an already generated answer file that included invalid values, the setup process did not return errors but some options were missing from the GUI after the setup. This bug fix adds in error validation so appropriate options are available in the GUI after setup.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1208440 (view as bug list) | Environment: | ||
| Last Closed: | 2016-03-09 20:40:51 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | Integration | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1208440 | |||
|
Description
Ulhas Surse
2014-10-06 06:56:32 UTC
'AllowClusterWithVirtGlusterEnabled' is used to decide whether the user is allowed to create a hybrid(virt+gluster) cluster or not. There is backend validation which checks for this. In this UI, if this option is true 'checkbox' will be shown else 'radiobutton' will be shown. But this doesn't hide the options itself. - ApplicationMode is virt then, both the options will be hidden but assumed virt=true and gluster=false while creating a cluster. - Application mode is gluster then, both the options will be hidden but assumed virt=false and gluster=true while creating a new cluster. - Application mode is Both then, both the options are visible, user can select whatever required while creating a new cluster. 'ApplicationMode' value in the configuration database needs to be changed to 255. This will enable both Virt and Gluster features. Is there anything to do on gluster side? This seems to be an issue with the value stored for 'ApplicationMode' in vdc_options on upgrade. Any update on the info requested? Tal? Sandro? Can you please address comment #9? Allon, not sure about what happens there. we'll try to reproduce. Can you please investigate this? This one is integration. Simone, please check if setting OVESETUP_CONFIG/applicationMode=str:(virt/Gluster/Both) <<===== reproduce the issue. Looks like an error in the configuration file. Maybe we're missing a validation on this. It was treating any invalid string like '(virt/Gluster/Both)' as 'virt' without reporting any explicit error or exception.
Calling
select fn_db_update_config_value('ApplicationMode', '255', 'general')
directly on the DB and restarting the engine should be enough to recover a broken deployment.
hi Ulhas, can you provide solution from comment #16 to the customer? On the engine host: . /etc/ovirt-engine/engine.conf.d/10-setup-database.conf PGPASSWORD="${ENGINE_DB_PASSWORD}" psql \ -U ${ENGINE_DB_USER} \ -h "${ENGINE_DB_HOST}" \ -p "${ENGINE_DB_PORT}" \ -d "${ENGINE_DB_DATABASE}" -c "select fn_db_update_config_value('ApplicationMode', '255', 'general')" should solve the issue. On the code side the fix will be available in 3.5.3 Verified with: ovirt-engine-3.6.0-0.0.master.20150412172306.git55ba764.el6.noarch Both options "Enable Virt Service" & "Enable Gluster Service" are available after re-running engine-setup with the already generated answer_file. 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/RHEA-2016-0376.html |