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.
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.
(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.
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.
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.
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.
Verified on RHEL 6.5 RHEVM 3.3 IS17.
Closing - RHEV 3.3 Released
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days