+++ This bug is an upstream to downstream clone. The original bug is: +++
+++ bug 1619199 +++
======================================================================
Description of problem:
Default timeout for whole upgrade is 1200s which should be enough for installing packages but in upgrade process there are also migrating VMs from upgraded host and from version 4.2 also rebooting the host at the end of upgrade. Rebooting process of physical host could take up to 10 minutes.
From this point of view 1200s is too short time for upgrading a machine.
This bug was found on clean hosted engine without running VMs except hosted_engine VM
All parts of upgrading (moving to maintenance - migrating, upgrading, rebooting) should be considered in default timeout
note: Time to moving into maintenance could be calculated from number of running VM on upgraded host.
Version-Release number of selected component (if applicable):
rhv-4.2.6-3
(Originally by Petr Kubica)
It should rather watch progress and bail out in case the VMs cannot migrate away, or reboot takes longer than 15mins, or pkgs download takes more than x, etc.
(Originally by michal.skrivanek)
It should rather watch progress and bail out in case the VMs cannot migrate away, or reboot takes longer than 15mins, or pkgs download takes more than x, etc.
(Originally by michal.skrivanek)
Let's change the default to 60 minutes, because there is no reliable way how to compute correct timeout. If 60 minutes is not enough, users needs to set their own timeout.
(Originally by Martin Perina)