Also includes some improvements to the Select Pools page of the RPU wizard
- do not show the checkbox if the item is disabled
- show the icon for the pool items, not only for hosts (making this consistent with the similar page in the Update Wizard)
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
The commit fixes bug and unify sorting rules in ManageUpdatesPage,
PatchingWizard_SelectServers and RollingUpgradeWizardSelectPool data
grid views.
The rules are:
1) Name column sorted purely by name.
2) Other columns sorted by string value, if the same, sorted by default,
which is still in order even in reverse direction.
Signed-off-by: Ji Jiang <ji.jiang@citrix.com>
prevent them from being serialised alongside the API properties. This will also
be useful for moving the API bindings out of XenModel.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
- On the Updates tab: for new versions, check that the version of XenCenter is at least the latest. If not, give an additional option to download a newer XenCenter (for both updates and upgrades), and not offer "Download and Install" (for updates).
- In the Patching wizard: if the update is a new version, we force the user to first update their XenCenter to the new version
- In the RPU wizard: if the server version is not the latest and their XenCenter version is not the latest from updates.xml, we assume that they want to upgrade to the latest XenServer version and we force the user to first update their XenCenter to the latest version.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- Added a new method in XenTabPage which the derived classes can implement to select a default control after the page is loaded.
- Added a new wizard test that runs through the wizard by pressing the Enter key and checks if it has landed on the right page.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
We now enumerate pre-Creedence and pre-Clearwater servers once, and check hosts only in those lists for the checks that only apply to those servers.
Signed-off-by: Callum McIntyre <callumiandavid.mcintyre@citrix.com>
This avoids unnecessary checks where we are upgrading multiple pools from different versions. Also made the same change for the unrelated pre-Clearwater only checks which had the same issue.
Signed-off-by: Callum McIntyre <callumiandavid.mcintyre@citrix.com>
We now only include the StorageLink check if we have any hosts earlier than Creedence in the RPU.
Signed-off-by: Callum McIntyre <callumiandavid.mcintyre@citrix.com>
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>
