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:
(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?
(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.
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.
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 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.
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.
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.
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