* CP-14807: Delete OEM in ServerVersion
* CP-14807: Removing unused IgnorePatchAction and IgnoreServerAction classes (moving their constants to the Updates class).
Signed-off-by: Aaron Robson <aaron.robson@citrix.com>
* CA-292626: Consider the contains-livepatch flag of all the applicable updates when doing the prechecks in the automated updates mode.
Instead of looking at the minimal patches, we look at all applicable patches for that host (i.e. all the updates on the host's version that are not already installed) and we say that the host won't need a reboot only if all these are marked as contains-livepatch.
Signed-off-by: Mihaela Stoica <mihaela.stoica@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>
* CP-28286: Support resume from a partially upgraded pool via Update wizard
Signed-off-by: Ji Jiang <ji.jiang@citrix.com>
* CP-28286: Fix comments of the previous commit
Signed-off-by: Ji Jiang <ji.jiang@citrix.com>
* CA-286458: Fix latestcr XC requirement when apply CR update
Using minimum_xc_version attribute in xenserver version to
determine which xencenter version is required.
* CA-286458: change MinimumXcVersion type to Version
Signed-off-by: Ji Jiang <ji.jiang@citrix.com>
1) Show required updates in case of versions without minimal patches
2) Hide version text in installed updates when version is Ely or above
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>
- Added more items to the metadata; the content is now slightly different between the SSR produced in XenCenter and the one from the HealthCheck;
- Encode the metadata string before sending it to the Health Check;
- Always suppress history for the action that sends the proxy settings;
- Renamed some of the new classes;
- Also refactored the actions that send data to the HealthCheck service.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
* CA-249056: Add a unique ID to XenCenter Check For Update
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
* CA-249056: Add a unique ID to XenCenter Check For Update
Fixed the format of the User-Agent to comply with [1].
[1] https://tools.ietf.org/html/rfc7231#section-5.5.3
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
* CA-249056: Add a unique ID to XenCenter Check For Update
Changes following the code review
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
* CA-249056: Add a unique ID to XenCenter Check For Update
Changes following the code review
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
* CA-249056: Add a unique ID to XenCenter Check For Update
Changes following the code review
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
First step, this can return an upgrade sequence that will upgrade a pool to a version and will bring that version up-to-date right away. Untested skeleton yet.
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@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>
If a patch updates the server version, then save a reference to that version in the alert and display this alert as a "new version" alert
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- Add "latestcr" field to the XenCenterVersion class
- Change the Updates class to cope with multiple latest XenCenter versions
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
These lists were continuously growing on each refresh, because the Where
clauses returned all items as the predicate was always evaluated to
true. The reason is: A. Even IEquatable<XenServerPatch> is
implemented on XenServerPatch, it only compares uuids. B. XenServerVersion
(also XenCenterversion) does not implement Equals (always different as the
Action returns new objects).
The two bugs these caused are: A] forever growing list of versions causing
obsolete data to be kept while everything is added to the end of the list
additionally. B] Any previously added Patch will not be updated unless the uuid has been changed (this never changes).
Fix in this commit: On each refresh, taking the new lists as they are
(from the Action) and not trying to keep or modify existing items. GC will do the rest with the old list (and objects)
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
Partially upgraded pools are not supported. If the versions of servers mismatch in a pool, Automatic updating will be disabled with the appropriate info message.
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
even when automatic mode was supported for them. The problem was that the xenserver
versions were not retrieved from the DownloadUpdatesXmlAction once the latter had run.
Also, minor refactoring.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
If there is no <minimalpatches /> tag, the version is not supported. This check has priority over licensed state when displaying the reason why a server is not supported.
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
Despite the update sequences are correct by host, when they are flattened, the original order (order in minimal patches) was not considered properly, so a missing patch was scheduled for later in the sequence than it should have been, thus the upgrade failed with a precheck-error.
This bug occurs when we are given
* a pool of more than one host,
* with (at least) patchA not installed on 2 or more hosts
* patchA requires patchR that is not installed on at least one of the above hosts (but not not on all)
* the host that is missing patchR is ahead of other hosts in pool.Hosts.Cache
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
Showing recommended* hotfixes for servers when the data is available (Check For Updates xml has been downloaded and has minimalPatches node in it for the given server version). *:Not applied ones from the minimal set.
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
Added support for defining custom update.xml location in Registry. This
can be either a local file or an URL. This will be beneficial when testing XenCenter.
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
