Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1059283 - [DWH-OTOPI-SETUP] DWH doesn't check the minimalETLVersion like the previous installer
Summary: [DWH-OTOPI-SETUP] DWH doesn't check the minimalETLVersion like the previous i...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-dwh
Version: 3.4.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
: 3.5.0
Assignee: Yedidyah Bar David
QA Contact: movciari
URL:
Whiteboard: integration
Depends On:
Blocks: 1080997 1100200 rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2014-01-29 15:04 UTC by Yaniv Lavi
Modified: 2015-02-11 18:14 UTC (History)
11 users (show)

Fixed In Version: oVirt Beta2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-11 18:14:30 UTC
oVirt Team: ---
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2015:0177 normal SHIPPED_LIVE rhevm-dwh 3.5 bug fix and enhancement update 2015-02-11 23:11:50 UTC
oVirt gerrit 27524 master MERGED packaging: setup: Force a minimal ETL version Never

Description Yaniv Lavi 2014-01-29 15:04:40 UTC
Description of problem:
DWH doesn't check the minimalETLVersion like the previous installer. This can cause customer to update dwh via yum and make it incompatible with engine.

Version-Release number of selected component (if applicable):
3.4.0

How reproducible:
Always

Steps to Reproduce:
1. Install engine+dwh 3.3
2. Yum update dwh to 3.4
3. Run DWH otopi setup

Actual results:
Will install dwh without issue, but service will fail to start due to version incompatibility checking.

Expected results:
Should fail asking to downgrade dwh or update engine.

Additional info:

Comment 1 Yedidyah Bar David 2014-02-17 15:58:49 UTC
(In reply to Yaniv Dary from comment #0)
> Description of problem:
> DWH doesn't check the minimalETLVersion like the previous installer. This
> can cause customer to update dwh via yum and make it incompatible with
> engine.
> 
> Version-Release number of selected component (if applicable):
> 3.4.0
> 
> How reproducible:
> Always
> 
> Steps to Reproduce:
> 1. Install engine+dwh 3.3
> 2. Yum update dwh to 3.4
> 3. Run DWH otopi setup
> 
> Actual results:
> Will install dwh without issue, but service will fail to start due to
> version incompatibility checking.

As far as I can tell, yum update dwh to 3.4 will also pull in updates to 3.4 for the engine and setup etc., so this is not really reproducible currently. I guess the reason to open this bug (iirc also mentioned in private) is for future support of separating engine/dwh/reports hosts. Is this planned for 3.4.0? Can we postpone this bug at least to a version where it's actually reproducible?

Comment 2 Yaniv Lavi 2014-02-18 13:18:48 UTC
(In reply to Yedidyah Bar David from comment #1)
> (In reply to Yaniv Dary from comment #0)
> > Description of problem:
> > DWH doesn't check the minimalETLVersion like the previous installer. This
> > can cause customer to update dwh via yum and make it incompatible with
> > engine.
> > 
> > Version-Release number of selected component (if applicable):
> > 3.4.0
> > 
> > How reproducible:
> > Always
> > 
> > Steps to Reproduce:
> > 1. Install engine+dwh 3.3
> > 2. Yum update dwh to 3.4
> > 3. Run DWH otopi setup
> > 
> > Actual results:
> > Will install dwh without issue, but service will fail to start due to
> > version incompatibility checking.
> 
> As far as I can tell, yum update dwh to 3.4 will also pull in updates to 3.4
> for the engine and setup etc.,

Not it will not. check the spec.

> so this is not really reproducible currently.
> I guess the reason to open this bug (iirc also mentioned in private) is for
> future support of separating engine/dwh/reports hosts. Is this planned for
> 3.4.0? Can we postpone this bug at least to a version where it's actually
> reproducible?

This is reproducible in a state that we currently don't have that views on the engine side change and dwh can not work with the engine anymore or engine was upgraded to new major.minor version.

Comment 3 Alon Bar-Lev 2014-03-02 15:34:10 UTC
The correct question is if we want dwh and reports to be in versionlock, which will solve the issue as long as engine is in versionlock.

Comment 4 Barak 2014-03-20 10:02:44 UTC
Alon ,

We need the check anyway going to 3.5 to be able to separate to different machines,

I would prefer this to go in either way.
We can add spec dependency as well (I would prefer solving it without it ... we'll need to revert it for next version anyway).
I don't like versionlock at all.

Comment 5 Alon Bar-Lev 2014-03-20 14:18:23 UTC
(In reply to Barak from comment #4)
> Alon ,
> 
> We need the check anyway going to 3.5 to be able to separate to different
> machines,
> 
> I would prefer this to go in either way.
> We can add spec dependency as well (I would prefer solving it without it ...
> we'll need to revert it for next version anyway).
> I don't like versionlock at all.

In 3.5 the owner of the separation task will require to provide complete solution including this and other issues.

If you want this for 3.4, I am sure that yaniv can implement that.

Comment 6 Yaniv Lavi 2014-03-23 04:28:41 UTC
I've come to the conclusion that we may not need this bug with otopi setup. This check was meant to make sure user doesn't update engine and install incompatible dwh. But with otopi as dwh and reports is a plugin we check the version is updated every time. When we move to a separate server we will need to readd this test, but for 3.4 adding spec version dependency and the update mechanism we should be good for 3.4.

Added patch for now:
http://gerrit.ovirt.org/#/c/25991


Moving to 3.5.

Comment 10 Yedidyah Bar David 2014-11-04 13:07:04 UTC
I do not think this requires doc text. This did not work in 3.4, but was not really relevant there, because a single call to engine-setup upgraded everything. In 3.5 it's still the same, but there it's possible to set up engine and dwh on different machines, thus this check was added.

Comment 12 errata-xmlrpc 2015-02-11 18:14:30 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/RHEA-2015-0177.html


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