* CA-293813: Patch pools in parallel when installing a single update/patch or supplemental package.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
* Corrections as per code review.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
minimum required role. Do not deselect a pool on the RPU wizard if it fails
the RBAC check; let the user decide either to reconnect with more privileges
or deselect it.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
(to ensure that XC has the latest c-f-u data, as it's possible that the user hasn't configured XenCenter to automatically check for updates)
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
... because pre-Dundee hosts dont't have this license flag, but they might have it after the upgrade.
Also added a bit more logging in the function that generates the update plan actions
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
* CP-28431: Block updates and upgrades from Kolkata onwards if clustering enabled
* CP-28431: Rename files and change from Pool Check to [Host] Check
* CP-28431: Change description message
Signed-off-by: Seren Corbett <seren.corbett@citrix.com>
the liveness warning is not issued if the pool is disconnected. HAOffCheck tidy up.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
a new check on the existing one instead. Moved the background worker to the designer
of the class.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
reverted to the new class UpdateUpgradeWizard which serves as base for the
Patching and the RPU wizards. Pass the list of resolved problems to the
automated updates page and not the actions, so as to prevent premature (i.e.
on creation as opposed to on start) addition to the global list shown on
the Events page.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
is now in one place, namely the PatchingWizard_PrecheckPage.UnwindChangesActions.
The pages following this page use now this list instead of the problems
encountered, so we ensure that the update/upgrade plans do not include the
unwind action if no resolution of problems took place on the prechecks page.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
* Deprecate set but unused Status property in favour of ProgressDescription.
* Deprecate set but unused TitlePlan property.
* Deprecated property Title in favour of ProgressDescription.
* Removed unused plan RebootHostPlanAction.
* Updated event declaration.
* Removed property Visible. The plan is to have the actions log their history as soon as some is available.
* Reworked the logging for the plan actions. The main change is the replacement of
the ProgressDescription with a stack where all the steps of an action are stored,
i.e. the action is responsible for its history, not the worker running it.
* Lock the progress history before accessing it.
* Better handling of error logging and user cancellation.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
- In the RPU case, re-enable the host after the upgrade is done, as the host will be put back into maintenance mode when needed during the update process.
- The VMs should not be repatriated during the RPU
- When a host is rebooted, it needs to be disabled first (even if an evacuation is not needed), otherwise the reboot won't happen
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
Renamed HostPlanActions class to HostPlan to avoid confusion with the HostPlanAction class.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
- Also corrected the function that creates the update plan action in RPU: when running a retry, these actions shouldn't be regenerated.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- Some methods have been moved/added to the base class to facilitate the calculation of the plan actions in the RPU case.
- Also fixed the calculation of the progress bar value.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
PageLoaded override in derived classes, enforce it by wrapping the page specific
code in a new virtual method, which the derived classes can override and PageLoaded
can call after its own logic.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
override in derived classes, enforce it by wrapping the page specific code in
a new virtual method, which the derived classes can override and PageLeave can
call before its own logic.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
WizardContentUpdater is invoked and information flows from the SelectInstallMethod
page to the following pages.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
For this purpose, the evacuate-reboot-bringbabiesback triplet was replaced by a
new RestartHostPlanAction, which allows fallback to toolstack restart if live
patching has succeeded. Also, created new abstract class HostPlanAction to
reduce code duplication.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
List in order to enforce the order of checks (the Dictionary is not guaranteed to
keep the order the items are added). Also, extra null check.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
in the Host extensions. Moved method TryResolveWithTimeout to the Connection class
where it is more relevant. Removed wrapper methods WaitForReboot and WaitForAgent
as they were not particularly useful.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
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>
