Bug 1059283

Summary: [DWH-OTOPI-SETUP] DWH doesn't check the minimalETLVersion like the previous installer
Product: Red Hat Enterprise Virtualization Manager Reporter: Yaniv Lavi <ylavi>
Component: ovirt-engine-dwhAssignee: Yedidyah Bar David <didi>
Status: CLOSED ERRATA QA Contact: movciari
Severity: high Docs Contact:
Priority: high    
Version: 3.4.0CC: alonbl, bazulay, gklein, iheim, pstehlik, rbalakri, Rhev-m-bugs, sherold, sradco, yeylon, ylavi
Target Milestone: ---   
Target Release: 3.5.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: integration
Fixed In Version: oVirt Beta2 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-11 18:14:30 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: 1080997, 1100200, 1142923, 1156165    

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