Bug 880069 - [rhevm-upgrade] pre-upgrade checks should collect all needed actions from user and not exit when one of them is no fulfilled [NEEDINFO]
[rhevm-upgrade] pre-upgrade checks should collect all needed actions from use...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-setup (Show other bugs)
3.2.0
x86_64 Linux
unspecified Severity high
: ---
: 3.3.0
Assigned To: Yedidyah Bar David
sefi litmanovich
integration
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-26 02:23 EST by Haim
Modified: 2015-09-22 09 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
oschreib: needinfo? (hateya)


Attachments (Terms of Use)

  None (edit)
Description Haim 2012-11-26 02:23:05 EST
Description of problem:

this is a pure UX case where I had to run rhevm-upgrade 3 times before it actually did something.

1) execute rhevm-upgrade

result: script starts, after 5 minutes I get message that i need to upgrade my rhevm-setup package

mitigation: upgraded rhevm-setup and try again

2) execute rhevm-upgrade

result: script starts, after 5 minutes I get message that I have an IPA installation which I need to remove (no KB for that)

mitigation: yum remove ipa-server and try again

3) execute rhevm-upgrade 

result: script starts, after 5 minutes I get a message that I have other ISO\EXPORT domain over iSCSI\FC which I need to remove.

mitigation: log-in to system, remove block based EXPORT domain and try again.

obviously, you can understand its a bad user experience.
Comment 1 Itamar Heim 2012-11-26 06:21:06 EST
the first one detects there is a new version.
the new version added a new check
the 3rd one could be combined with the 2nd one maybe, but not sure worth it for that specific corner case.
Comment 2 Simon Grinberg 2012-12-24 13:14:02 EST
(In reply to comment #1)
> the first one detects there is a new version.

Should be the first check, and not wait to get a full list of required RPM for the upgrade.

> the new version added a new check

No problem, but again why wait? There are few checks that are not dependent on the set of RPMs to be installed. They should run prior to the accumulation of the full RPM list thus saving the user an idle wait 


> the 3rd one could be combined with the 2nd one maybe, but not sure worth it
> for that specific corner case.

Same as in the previous comment.
Comment 6 sefi litmanovich 2013-10-03 06:50:06 EDT
Current upgrade flow, RHEVM 3.3 upgrading form IS16 to IS17 on RHEL 6.5 machine.

after updating the repos:
1. run engine-setup:
 - after 30 seconds setup is srearching for updates
 - answer yes to update the packages
 - get error message: 

[ ERROR ] An update for the Setup package "rhevm-setup" was found. Please update that package, e.g. by running "yum update rhevm-setup", and then execute Setup again.
[ ERROR ] Failed to execute stage 'Environment customization': Please update the Setup package

setup stops.

2. 
 - run yum update rhevm-setup.
 - run engine-setup.
 - setup flow works fine with no problems including yum updating the 
   relevant rhevm packages.
Comment 7 Yedidyah Bar David 2013-10-06 07:45:55 EDT
As explained before, yum downloads metadata once, then reads from the cache.

I now did the following tests, all on a fedora 19 machine with ovirt 3.3 beta installed and the nightly repo enabled.

1. Ran a few times:
/usr/bin/time engine-setup --otopi-environment='OSETUP_RPMDISTRO/enableUpgrade=bool:True'

Min time was around 12 seconds, average, not including the first, around 13 seconds.

2. Ran a few times:
yum clean all; /usr/bin/time engine-setup --otopi-environment='OSETUP_RPMDISTRO/enableUpgrade=bool:True'

Min time was around 38 seconds, average around 42 seconds.

3. Then changed the sources to check for an update for setup before checking an update for the engine, here:
http://gerrit.ovirt.org/19892

4. Again, ran a few times:
/usr/bin/time engine-setup --otopi-environment='OSETUP_RPMDISTRO/enableUpgrade=bool:True'

Min time was around 11 seconds, average around 12 seconds. One second less than without the change.

5. Ran a few times:
yum clean all; /usr/bin/time engine-setup --otopi-environment='OSETUP_RPMDISTRO/enableUpgrade=bool:True'

Min time was again around 38 seconds, average around 40 seconds.

Conclusion: Updating the metadata cache takes around 30 seconds, the rest is relatively insignificant. IMHO, of course :-)

Do we want such a change?

Note that it works, but probably not ready for merge - in particular, the current master code relies on a single environment value (OSETUP_RPMDISTRO/enableUpgrade) to decide if the user wants to upgrade both the product and setup, while the code with the change checks updates for setup unconditionally - and we might want to add another value for that or use the existing one. Not sure which is best.

Comments are welcome.
Comment 8 Yedidyah Bar David 2013-10-09 09:00:47 EDT
Now talked with Sefi about his tests.

We both agreed there is currently no issue.

I am moving to ON_QA, letting Sefi move to VERIFIED.
Comment 9 sefi litmanovich 2013-10-09 09:10:11 EDT
Verified on RHEL 6.5 RHEVM 3.3 IS17.
Comment 11 Itamar Heim 2014-01-21 17:28:24 EST
Closing - RHEV 3.3 Released
Comment 12 Itamar Heim 2014-01-21 17:28:30 EST
Closing - RHEV 3.3 Released
Comment 13 Itamar Heim 2014-01-21 17:31:22 EST
Closing - RHEV 3.3 Released

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