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>
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>
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>
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>
- 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>
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>
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>
