Created attachment 895915 [details] setup log + answer file Description of problem: Endind clean install of engine, dwh & reports the following message is provided: " [root@vm3 ~]# rhevm-setup ... Configure Reports on this host (Yes, No) [Yes]: Configure Data Warehouse on this host (Yes, No) [Yes]: ... [ INFO ] Creating Engine database schema [ INFO ] Creating CA [ INFO ] Creating/refreshing DWH database schema [ INFO ] Deploying Jasper ... [ INFO ] DWH and/or Reports were found on this system. To upgrade them, please run the following commands: # yum update rhevm-dwh rhevm-reports # engine-setup ... [ INFO ] Starting engine service [ INFO ] Restarting httpd [ INFO ] Starting dwh service [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20140515122315-pe3pel.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20140515123732-setup.conf' " Version-Release number of selected component (if applicable): av9.1 How reproducible: 100% Steps to Reproduce: 1. on clean rhel6.5 yum install -y rhevm-setup rhevm-dwh-setup rhevm-reports-setup 2. install using rhevm-setup 3. Actual results: Expected results: Additional info:
Note to QE: Please verify: clean install of 3.4, engine only same, with dwh/reports same as above but upgrade from prev version
No change should be needed in 3.5 code, just verify it's not affected.
Moving back to modified because I think that we need some more discussion about >=3.5. The current pending change was pushed for 3.4 only. In that sense Sandro is right. If we intend to prevent direct upgrades of 3.3 to 3.5+ (which I think we do, see bug #1111749), we can drop this code file altogether, because users will not be able to upgrade separately dwh/reports from 3.4+. But perhaps better to first decide about this. Yaniv told me that he does not currently expect problems upgrading dwh/reports from 3.3 to 3.5, but I am not sure this is a good idea. The only problem is that we do not have simple means to prevent that :-) Sandro?
(In reply to Yedidyah Bar David from comment #6) > Moving back to modified because I think that we need some more discussion > about >=3.5. > > The current pending change was pushed for 3.4 only. In that sense Sandro is > right. > > If we intend to prevent direct upgrades of 3.3 to 3.5+ (which I think we do, > see bug #1111749), we can drop this code file altogether, because users will > not be able to upgrade separately dwh/reports from 3.4+. But perhaps better > to first decide about this. Yaniv told me that he does not currently expect > problems upgrading dwh/reports from 3.3 to 3.5, but I am not sure this is a > good idea. The only problem is that we do not have simple means to prevent > that :-) > > Sandro? Can you verify what happens upgrading from 3.3 to 3.5 for DWH and reports? If it works, no need to add code.
(In reply to Sandro Bonazzola from comment #7) > Can you verify what happens upgrading from 3.3 to 3.5 for DWH and reports? > If it works, no need to add code. I didn't try that yet. Yaniv told me it should work. Arthur told me that we probably do not want to support that even if it works, because it's (at least) one more item to add to the support matrix of qe/gss. E.g. suppose that I now "verify" and do not find problems, and two years ahead in version 4.1 it turns out that there is a subtle bug in the upgrade to 4.2 which affects only systems that skipped the upgrade to 3.4... Setting needinfo on you, not sure who should decide. This might be quite a significant decision, because if we decide we'll never want to allow skipping versions, it practically means that versionlock is here to stay, and we'll more easily add stuff there (dwh/reports for now, other later perhaps).
I'd honestly like to avoid declaring official support to 3.3 -> 3.5 direct upgrade. There are multiple reasons for that: A) Documentation would need to adjust to capture this scenario B) So far we managed to tackle any kind of upgrade issue in either Z-stream or newest stream of updates. Sometimes combination of both was required. C) The QE resources consumed by testing these flows could be definitely used at better places D) QE of reports was always delayed due to last minute Jasper issues - extending the suites with the scenario would mean delaying releases due to these even more
Moved to assigned as the patch for 3.4 is currently pushed only there and might not be relevant at all, depending on the decision taken here. Wanted also to note that if we intend to "solve" this one by adding dwh/reports to versionlock, it should be done in 3.4 (too), so the sooner the better. If we wish to get more-or-less the same behavior (prevent manually updating packages except through engine-setup), we'll probably have to do it in the spec file, something like [1]. [1] https://gerrit.eng.lab.tlv.redhat.com/13475
(In reply to Yedidyah Bar David from comment #10) > Moved to assigned as the patch for 3.4 is currently pushed only there and > might not be relevant at all, depending on the decision taken here. > > Wanted also to note that if we intend to "solve" this one by adding > dwh/reports to versionlock, it should be done in 3.4 (too), so the sooner > the better. > > If we wish to get more-or-less the same behavior (prevent manually updating > packages except through engine-setup), we'll probably have to do it in the > spec file, something like [1]. > > [1] https://gerrit.eng.lab.tlv.redhat.com/13475 Ok, I guess version locking may be the best option we have for now.
Trying versionlock. Note that the linked changes are for 3.4, although the bug is on 3.5 - to use versionlock to prevent skipping 3.4 (e.g. direct upgrade 3.3->3.5) we'll have to apply it in 3.4. Yaniv - I know you do not like this, but I really think that's simplest, and won't add too much work if we one day decide to drop versionlock altogether (which currently seems to me not very likely). Setting needinfo on you just to make sure you see the discussion and Sandro's agreement - if you still decide to object, please state what other solution you prefer. Thanks!
(In reply to Yedidyah Bar David from comment #12) > Trying versionlock. Note that the linked changes are for 3.4 (Currently pushed to master (dwh/reports), intended to be backported to 3.4)
Removing doc text flag for now. If QE decide that some flows are not obvious, we can add some text. QE - please verify at least the following flows: engine/dwh/reports 3.2 installed/setup engine upgraded to 3.3 yum update dwh and/or reports to 3.3, do not setup upgrade engine to 3.4.0 (or 3.4.1) try to upgrade engine to 3.5 - should fail engine/dwh/reports 3.2 installed/setup engine upgraded to 3.3 yum update dwh and/or reports to 3.3, do not setup try to upgrade engine to 3.4.2 - should fail engine/dwh/reports 3.3 installed/setup (clean or from 3.2) engine upgraded to 3.4, dwh/reports are not try to upgrade engine to 3.5 - should fail
(In reply to Yedidyah Bar David from comment #14) > Removing doc text flag for now. If QE decide that some flows are not > obvious, we can add some text. > > QE - please verify at least the following flows: > > engine/dwh/reports 3.2 installed/setup > engine upgraded to 3.3 > yum update dwh and/or reports to 3.3, do not setup > upgrade engine to 3.4.0 (or 3.4.1) > try to upgrade engine to 3.5 - should fail failed after yum update (vt2.1), requires rhevm >= 3.4.2, rhevm-3.4.1 installed > engine/dwh/reports 3.2 installed/setup > engine upgraded to 3.3 > yum update dwh and/or reports to 3.3, do not setup > try to upgrade engine to 3.4.2 - should fail failed in setup > engine/dwh/reports 3.3 installed/setup (clean or from 3.2) > engine upgraded to 3.4, dwh/reports are not > try to upgrade engine to 3.5 - should fail update from 3.4.2 forces to update rhevm-dwh and rhevm-reports to 3.5, is this ok? should I put verify status?
(In reply to Petr Matyáš from comment #15) > (In reply to Yedidyah Bar David from comment #14) > > engine/dwh/reports 3.3 installed/setup (clean or from 3.2) > > engine upgraded to 3.4, dwh/reports are not > > try to upgrade engine to 3.5 - should fail > > update from 3.4.2 forces to update rhevm-dwh and rhevm-reports to 3.5, is > this ok? IMO yes, but I am not sure I completely understand what you ask. Who/What "forces" you? yum directly? engine-setup itself? engine-setup running yum? Since this is a delicate issue, please state exact flows you followed and state if you have any question at all. > should I put verify status? I really hope you can, but only if you think it's ok :-) To make things clear: 1. Re the actual summary line of this bug, we indeed try now to suggest that the user updates dwh/reports only if relevant. If you see any other behavior please detail. 2. In addition, we also try now to prevent the user from skipping upgrades. That is, to upgrade any component from X.Y to X.Y+d where d>1. In particular, this means that if user has engine 3.4 + dwh 3.3, we want to prevent upgrading the engine to 3.5, as this will later require direct upgrade of dwh from 3.3 to 3.5. Since this flow is not very expected, we did not try hard to provide very nice error messages (at least for now).
(In reply to Yedidyah Bar David from comment #16) > (In reply to Petr Matyáš from comment #15) > > (In reply to Yedidyah Bar David from comment #14) > > > engine/dwh/reports 3.3 installed/setup (clean or from 3.2) > > > engine upgraded to 3.4, dwh/reports are not > > > try to upgrade engine to 3.5 - should fail > > > > update from 3.4.2 forces to update rhevm-dwh and rhevm-reports to 3.5, is > > this ok? > > IMO yes, but I am not sure I completely understand what you ask. Who/What > "forces" you? yum directly? engine-setup itself? engine-setup running yum? Yes, yum directly. After I update engine with yum from 3.3 to 3.4, I set up the engine, then when running yum update from 3.4 to 3.5, there are some conflicts (see attachment) and yum wants to update rhevm-dwh and reports to 3.5. I think it's OK, but wanted to ask you first. > Since this is a delicate issue, please state exact flows you followed and > state if you have any question at all. > > > should I put verify status? > > I really hope you can, but only if you think it's ok :-) > > To make things clear: > > 1. Re the actual summary line of this bug, we indeed try now to suggest that > the user updates dwh/reports only if relevant. If you see any other behavior > please detail. > > 2. In addition, we also try now to prevent the user from skipping upgrades. > That is, to upgrade any component from X.Y to X.Y+d where d>1. In > particular, this means that if user has engine 3.4 + dwh 3.3, we want to > prevent upgrading the engine to 3.5, as this will later require direct > upgrade of dwh from 3.3 to 3.5. Since this flow is not very expected, we did > not try hard to provide very nice error messages (at least for now).
Created attachment 935273 [details] Yum update - resolving dependencies
(In reply to Petr Matyáš from comment #17) > (In reply to Yedidyah Bar David from comment #16) > > (In reply to Petr Matyáš from comment #15) > > > (In reply to Yedidyah Bar David from comment #14) > > > > engine/dwh/reports 3.3 installed/setup (clean or from 3.2) > > > > engine upgraded to 3.4, dwh/reports are not > > > > try to upgrade engine to 3.5 - should fail > > > > > > update from 3.4.2 forces to update rhevm-dwh and rhevm-reports to 3.5, is > > > this ok? > > > > IMO yes, but I am not sure I completely understand what you ask. Who/What > > "forces" you? yum directly? engine-setup itself? engine-setup running yum? > > Yes, yum directly. After I update engine with yum from 3.3 to 3.4, I set up > the engine, then when running yum update from 3.4 to 3.5, there are some > conflicts (see attachment) and yum wants to update rhevm-dwh and reports to > 3.5. > I think it's OK, but wanted to ask you first. It's not. Sorry. I think that if you do that, then run 'engine-setup', it will upgrade dwh/reports from 3.3 to 3.5, skipping 3.4. We wanted to prevent that. I have to think how...
Just a short note - we do something very similar in the engine. The difference is that dwh/reports are not version-locked until 3.4.2. Just 'Conflicts: rhevm-dwh < 3.4.0' is not enough, because without versionlock, yum simply updates to 3.5. Either (better) make yum fail this (e.g. conflict with a file that exists only on 3.3 after setup, have to check separately dwh and reports) or (worse) make the setup code prevent that, also pointing the user to a workaround which will include downgrading all setup packages to 3.4 and running engine-setup there.
Tried a few things in gerrit, don't like any of them... Had this idea: Release 3.4.4 with a change that will check if 3.3 dwh/reports are setup, and if so, touch e.g. /etc/ovirt-engine-{dwh,reports}-3.3-needs-upgrade, make the 3.4 setup plugins remove them if found, and make 3.5 require >= 3.4.4., and conflict with these files. This will not be as nice as a real error message, but hopefully clear enough for the user. What do you think? Not sure what the timeline for 3.4.4 vs 3.5.0 is.
(In reply to Yedidyah Bar David from comment #21) > Tried a few things in gerrit, don't like any of them... > > Had this idea: > > Release 3.4.4 with a change that will check if 3.3 dwh/reports are setup, > and if so, touch e.g. /etc/ovirt-engine-{dwh,reports}-3.3-needs-upgrade, > make the 3.4 setup plugins remove them if found, and make 3.5 require >= > 3.4.4., and conflict with these files. This will not be as nice as a real > error message, but hopefully clear enough for the user. What do you think? > Not sure what the timeline for 3.4.4 vs 3.5.0 is. What about having 3.4.4 checking if 3.3 dwh/reports has been setup and set an env in the post-install file. Having 3.5 checking for env variable: 1) If the env variable is not found: ask user to confirm the upgrade 2) if the env is set telling dwh and reports not updated: abort with an error saying to downgrade and perform engine-setup first on 3.4. 3) If the env is set telling everything is good just go ahead. This will require for case 2 to downgrade some packages for completing the task but will allow the solution to work also upgrading for rhev < 3.4.4.
*** Bug 1146637 has been marked as a duplicate of this bug. ***
Discussed this with Sandro. Our current suggestion: 1. Officially(?) decide that we support direct upgrades of dwh/reports from 3.3 to 3.5. Yaniv already said it should work. 2. Add in 3.4.4 and 3.5 code that tests if dwh/reports 3.3 seems to be setup, and if so, create files such as /etc/ovirt-engine/{dwh,reports}-3.3-needs-upgrade, and make 3.5+ conflict with them. In these files we can write a bit more, for users that get an error from yum. 3. Also add to 3.4+ code that removes them if we upgrade dwh/reports. This way: I. It will be possible to upgrade from engine 3.4.[0123] to 3.5 directly. II. It will not be possible to upgrade dwh/reports 3.3 to 3.6, so we'll not need to support that. Tomas - please ack, or say if you prefer my previous suggestion (require going through 3.4.4), or want something else. Thanks!
This looks reasonably to me so that's an ACK from me. Cheers.
I am deeply sorry, but this does not seem to work as expected. Specifically, 'Conflict: /some/file' does not work. I'll discuss this with Sandro and update.
After a discussion with Sandro, decided to fix by adding dwh/reports to versionlock inside rhevm-setup-plugins - meaning, even if they are not upgraded first to a version that does that by them (which does happen since 3.4.2).
How various flows should behave with the proposed patches. For all flows, start state is a system with engine/dwh/reports 3.3 installed and set up. This is of course in addition to comment 14. Suppose that the patches will be merged for 3.4.4. 1. * all upgraded to 3.4.2+ * all upgraded to 3.5.0 should work 2. * engine upgraded to 3.4.[0123] * engine upgraded to 3.5.0 * dwh/reports upgraded to 3.5.0 should work. We tried to avoid this but gave up. Last two can be done in one or two steps. 3. * engine upgraded to 3.4.4 * yum update rhevm-setup to 3.5 should fail, saying there is a conflict with dwh/reports < 3.4.0 QE - you are of course welcome to try other combinations. One other that I verified is: * engine upgraded to 3.4.4 * dwh upgraded to 3.4.3 (reports left as-is) * yum update rhevm-setup - should conflict with reports < 3.4.0
I'am not really able to update dwh and reports, when I have 3.3, there are no rhevm-dwh-setup and rhevm-reports-setup packages. And when I try to update rhevm-dwh and rhevm-reports, I get dependency error on jasperreports-server-pro.
For the second test, I can upgrade engine to 3.4, but then I can't upgrade to 3.5, because I have dwh and reports 3.3 only. And if I try complete update, I get the same dependency error as above.
(In reply to Petr Matyáš from comment #31) > I'am not really able to update dwh and reports, when I have 3.3, there are > no rhevm-dwh-setup and rhevm-reports-setup packages. In 3.3 there were separate utilities with these names, but not separate packages. > And when I try to > update rhevm-dwh and rhevm-reports, I get dependency error on > jasperreports-server-pro. Upgrade from what to what? Please give more details. (In reply to Petr Matyáš from comment #33) > For the second test, I can upgrade engine to 3.4, but then I can't upgrade > to 3.5, because I have dwh and reports 3.3 only. Good, that's the intention. "because I have dwh and reports 3.3 only." - you say so because you know that, or did you actually get such a message (which is what we want)? > And if I try complete > update, I get the same dependency error as above. Which?
OK, now it's upgraded to 3.4.3 (so I put VERIFIED on 3.4 clone), but I'am stuck on websocket proxy issue when upgrading to 3.5.
Verified for 3.4.4 as well, everything is behaving as described in comment 28.
downstream patch only, upgrade problems with dwh/reports from 3.3->3.5. bronce - can you please change back to 3.5.0 flag?
Started with clean 3.3 engine+dwh+reports. Tried to upgrade everything (engine+dwh+reports) through 3.4.2 to 3.5 and it worked, that's the preferred flow to upgrade if I'am correct. Also tried to upgrade engine only through 3.4.[2345] to 3.5 and couldn't upgrade it to 3.5 due to dependencies in yum (engine has to be >=3.4.3; dwh+reports has to be >=3.4.2, conflicts with rhevm-setup-plugin-ovirt-engine), that's also correct I suppose?
(In reply to Petr Matyáš from comment #48) > Started with clean 3.3 engine+dwh+reports. > Tried to upgrade everything (engine+dwh+reports) through 3.4.2 to 3.5 and it > worked, that's the preferred flow to upgrade if I'am correct. > Also tried to upgrade engine only through 3.4.[2345] to 3.5 and couldn't > upgrade it to 3.5 due to dependencies in yum (engine has to be >=3.4.3; > dwh+reports has to be >=3.4.2, conflicts with > rhevm-setup-plugin-ovirt-engine), that's also correct I suppose? Indeed.
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/RHBA-2015-0196.html