Bug 1054226
Summary: | [rhevm-dwh-setup] rhevm-dwh-setup confusingly informs about doing upgrade when doing clean remote install | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Jiri Belka <jbelka> | |
Component: | ovirt-engine-dwh | Assignee: | Yedidyah Bar David <didi> | |
Status: | CLOSED ERRATA | QA Contact: | Jiri Belka <jbelka> | |
Severity: | medium | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 3.3.0 | CC: | aberezin, acathrow, adahms, bazulay, didi, gklein, iheim, pstehlik, Rhev-m-bugs, yeylon, ylavi | |
Target Milestone: | --- | Keywords: | ZStream | |
Target Release: | 3.4.0 | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | integration | |||
Fixed In Version: | Doc Type: | Bug Fix | ||
Doc Text: |
The ovirt-engine-dwh-setup command no longer erroneously informs the user that a clean remote database install is an upgrade.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1059270 (view as bug list) | Environment: | ||
Last Closed: | 2014-06-09 15:16:50 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: | 1059286, 1064962, 1066459 | |||
Bug Blocks: | 1059270, 1078909, 1142926 |
Description
Jiri Belka
2014-01-16 13:37:36 UTC
I understand the issue, but I don't think this is urgent enough to get to z stream. Barak, what do you think? Yaniv Didi, didn't we add a if that causes backup of db only when there is data? Yaniv (In reply to Yaniv Dary from comment #2) > Didi, didn't we add a if that causes backup of db only when there is data? No, the check is 'if dbExists'. With a remote database, dbExists is always True at that point. It's an easy fix - just change to 'if hasData'. I am pretty certain that I suggested to do that and you objected back then. I am also not sure it's such a bad thing to back it up anyway. If we really want to do it right, we should check if it's empty and refuse using it if it's not (for a remote db, new setup). Another potential fix is to ask only if the size is more than some threshold, e.g. 100MB or so, with the assumption that a small db can be backed up anyway without much hesitation. This will make it simpler for smaller installations that did not collect much data. What do you think? Barak, do we want fix this in z stream? Yaniv (In reply to Yaniv Dary from comment #4) > Barak, do we want fix this in z stream? I think Yaniv meant 3.3.z, not 3.2.z. And if you agree I think you should clone. Moving to ON_QA as the new setup code, based on otopi, should not have this issue, and merged to master two weeks ago. fail as this is downstream - because of upstream|downstream naming issue: [root@jb-rhevm34 ~]# engine-setup [ INFO ] Stage: Initializing [ INFO ] Stage: Environment setup Configuration files: ['/etc/ovirt-engine-setup.conf.d/10-packaging.conf', '/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf'] Log file: /var/log/ovirt-engine/setup/ovirt-engine-setup-20140306135435.log Version: otopi-1.2.0_master (otopi-1.2.0-0.0.master.el6_5) [ INFO ] Stage: Environment packages setup [ INFO ] Stage: Programs detection [ INFO ] Stage: Environment setup [ INFO ] Stage: Environment customization --== PRODUCT OPTIONS ==-- Install Data Warehouse on this host (Yes, No) [Yes]: --== PACKAGES ==-- [ INFO ] Checking for product updates... [ ERROR ] Yum: Cannot queue package ovirt-engine-dwh: No package(s) available to install ^^^^^^^^^^^^ -> s/ovirt-engine/rhevm/ ... [ INFO ] Yum: Performing yum transaction rollback [ ERROR ] Failed to execute stage 'Environment customization': No package(s) available to install [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20140306135435.log [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Execution of setup failed [root@jb-rhevm34 ~]# rpm -qa | grep dwh rhevm-dwh-3.4.0-0.4.master.20140224152332.el6ev.noarch rhevm-dwh-setup-3.4.0-0.4.master.20140224152332.el6ev.noarch it works on upstream (beta3), ovirt-engine-dwh-setup-3.4.0-0.3.el6.noarch ... [ INFO ] Cleaning async tasks and compensations [ INFO ] Checking the Engine database consistency [ INFO ] Stage: Transaction setup [ INFO ] Stopping engine service [ INFO ] Stopping dwh service [ INFO ] Stopping websocket-proxy service [ INFO ] Stage: Misc configuration [ INFO ] Stage: Package installation [ INFO ] Stage: Misc configuration [ INFO ] Backing up database localhost:engine to '/var/lib/ovirt-engine/backups/engine-20140306124834.jRBTGf.sql'. [ INFO ] Updating Engine database schema [ INFO ] Creating DWH database schema ... With this one it passes yum check... and dwh setup finishes OK. --- /usr/share/ovirt-engine/setup/ovirt_engine_setup/dwhconstants.py 2014-03-06 14:12:31.760590986 +0100 +++ /tmp/dwhconstants.py 2014-03-06 14:12:07.782591005 +0100 @@ -43,8 +43,8 @@ class Const(object): RPM_RELEASE = dwhconfig.RPM_RELEASE SERVICE_NAME = 'ovirt-engine-dwhd' OVIRT_ENGINE_DWH_DB_BACKUP_PREFIX = 'dwh' - OVIRT_ENGINE_DWH_PACKAGE_NAME = 'ovirt-engine-dwh' - OVIRT_ENGINE_DWH_SETUP_PACKAGE_NAME = 'ovirt-engine-dwh-setup' + OVIRT_ENGINE_DWH_PACKAGE_NAME = 'rhevm-dwh' + OVIRT_ENGINE_DWH_SETUP_PACKAGE_NAME = 'rhevm-dwh-setup' @classproperty def DWH_DB_ENV_KEYS(self): How is it possible I haven't seen same Yum failure while configuring rhevm-reports? Although this time I defined reports DB to be local. # grep 'OVIRT.*PACKAGE_NAME' /usr/share/ovirt-engine/setup/ovirt_engine_setup/reportsconstants.py OVIRT_ENGINE_REPORTS_PACKAGE_NAME = 'ovirt-engine-reports' OVIRT_ENGINE_REPORTS_SETUP_PACKAGE_NAME = 'ovirt-engine-reports-setup' This is fixed in the following release. See bug 1065730. Workaround is to run with --offline flag. Please verify the bug at hand that issue is handled. Yaniv Ok, based on latest comments. 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. http://rhn.redhat.com/errata/RHEA-2014-0601.html |