When an exception is reported during the RPU, XenCenter tries to re-enable the host. But when this fails, we should just ignore it and report the original exception.
Signed-off-by: Mihaela Stoica <Mihaela.Stoica@citrix.com>
In the RPU wizard, after we notice that the host has been rebooted we try to resolve the host from cache, but sometimes the cache is not populated at that point.
Then, because we cannot resolve the host, we cannot check the host version and we assume is a newer version (which might not be true).
This commit adds a call to retry to resolve the host (with timeout).
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
testSafe2Upgrade pugin function in prepare_host_upgrade.py is called as part of the RPU pre-checks
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
- while upgrading a host, throw a HOST_OFFLINE ("Server could not be contacted") exception if the host can no longer be resolved (instead of HANDLE_INVALID)
- also corrected the parameters of the HANDLE_INVALID exception, as an extra parameter is needed for the friendly error name.
- in the UpdateManualHostPlanAction class I replaced Host with the private property _host in several places, so we are no longer trying to resolve the host each time we want to write something into logs
- added some null checks, to avoid reporting null reference exception
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
We observed that some threads can reach deadlock-ish state after they have Invoked into a control's UI thread. When it happens they are all in a waiting for join or in sleep state for very long time, although there should not be any deadlock situations.
It seems this has something to do with multiple parent controls and with which control we invoked on. This should not make a difference, because we have got one UI thread (for MainWindow) they should wait for, but we have seen it does.
The solution that fixed this issue was to invoke on the MainWindow instead of various controls (see a4fe507adf ).
This changeset is changing all our Invokes to invoke into MainWindow
instead of a control itself. (MainWindow's UI thread is the only UI thread
all Control is using in XenCenter)
This changeset should be in place until we have found the root cause or the exact reason for the above.
In some cases calling Control.Invoke() from a background thread causes that thread to go in a "sleep, wait, or join" mode, while waiting for Invoke to happen, although the UI thread is running normally.
If the Control is the MainWindow, it works as expected, but we've seen it happening while connecting or disconnecting from a large pool, on calling Invoke on controls like NavigationView, AlertSummaryPage, HistoryPage, etc.
To fix this, we call the Invoke on the MainWindow in all the places where we've seen the issue.
With this changes, the previous fix for CA-148245 (call RequestRefreshTreeView on CacheClearing event) is not needed anymore, so I removed that call.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- Suppress reporting of success and failure for sub-actions:
The suppress history flag is set when the action is created and if is false (by default) the action is added to the history (the Events list).
In order to suppress history for the subactions, we need change all actions used in Edit pages so their constructor can set the SuppressHistory flag and then use these constructors with suppressHistory = true on all the implementations of IEditPage.SaveSettings() where an action is created
(then we need to remember to do the same everytime we introduce a new page and / or "save" action).
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- Renamed “Checking can evacuate host status” precheck group to “Checking VM migration status”
- Prechecks page – check that all VMs have valid vCPU settings (i.e. number of vCPUs is a multiple of number of cores per socket).
- This check is included in the ‘Checking VM migration status” group
- If a VM has invalid vCPU settings, the precheck will display the problem with a solution to “Fix vCPU configuration” which opens the VM Properties dialog on the CPU page.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
Made the radio button invisible for Creedence or higher XS hosts.
Removed previous StorageLink-related upgrade pre-checks and added (strict) check to prevent upgrade when StorageLink is used.
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
common code to the base class BackgroundThreadBase; removed classes inheriting from
EventArgs; use Action/Action<T> delegates instead of EventHandler<T>.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
NewAction to use the Action<ActionBase> delegate instead of EventHandler. Thus
there is no need to fire them with Empty or null EventArgs and on several occasions
we avoid casting objects in the event handlers.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
1. Added additional check to DownloadAndInstall method in ManageUpdatesDialog.cs: will proceed to the prechecks page in the Install Update Wizard only when there are selected servers on the previous page.
2. Modified code to allow hotfix installation when the host is in maintenance mode; however the host cannot be upgraded when in maintenance mode.
3. Modified test to reflect changes described above.
Signed-off-by: Adrian Jachacy <Adrian.Jachacy@citrix.com>
New info dialog displayed when the user cancels the last page (Apply Upgrade page) of the Rolling Pool Upgrade wizard.
Signed-off-by: Adrian Jachacy <Adrian.Jachacy@citrix.com>
been previously upgraded.
Introduced Host.LongProductVersion property which returns host's
product version and build number (e.g. 5.6.100.72258), or null if
product version can't be found. We use this property to check
if the master has been updraded and to decide which slaves need
to be upgraded or to skip hosts already upgraded.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
