Installed patches on master, now the patches aren't visible on second host.

Forza

Hi,

Just installed patches on the master host on my xcp-ng pool and rebooted it. But after the reboot the patches are now missing on the second host. Instead an empty line is showing on the second host. There should be several patches there?

EDIT: Going to reboot the second host and see what happens.
EDIT2: No change. Clicking "Install all patches" gave the following error:

pool.installPatches
{
  "hosts": [
    "e866307e-2852-4d31-8a28-6caaa158e4d7"
  ]
}
{
  "message": "Update install failed",
  "name": "Error",
  "stack": "Error: Update install failed
    at Xapi._xcpUpdate (/usr/local/lib/node_modules/xo-server/src/xapi/mixins/patching.js:363:15)
    at Object.installPatches (/usr/local/lib/node_modules/xo-server/src/api/pool.js:95:3)
    at Api.callApiMethod (/usr/local/lib/node_modules/xo-server/src/xo-mixins/api.js:301:20)"
}

Forza

Seems the proxy settings were lost on the member host. yum check-update works now.

Danp

Pretty sure that the recommendation is to install patches at the pool level.

Forza

@anp said in Installed patches on master, now the patches aren't visible on second host.:

Pretty sure that the recommendation is to install patches at the pool level.

Doesn't that imply automatic reboots? The last host has a vm that I wanted to manually reboot at a convenient time because it cannot be migrated to other hosts.

Danp

@S-Pam said in Installed patches on master, now the patches aren't visible on second host.:

Doesn't that imply automatic reboots?

No, it doesn't perform a reboot automatically.

olivierlambert

There's NEVER automated reboot while applying patches.

And if we go that route, it will be for a dedicated method (Rolling pool update).

Forza

I really thought it was the case - i.e. it would be a rolling upgrade. Thanks for clarifying.

olivierlambert

In fact, there's 2 different things:

Downloading and unpacking the updates (yum process). This won't change anything right now, because your current updated programs are likely running in memory (Xen, Linux, XAPI…) so only a reboot will make things changed: it's the current update button on the pool view.
Evacuating the host, rebooting it to get all the new versions, and migrate back VMs to it (starting by the master)

Right now, 1. need to be triggered manually (you must do it otherwise it won't happen: bad if you forgot) but everything else is managed at all hosts of the pool at the same time (good).
And 2 is entirely manual.

So that's why I wrote this, to get 1. and 2. entirely automated while being safe and giving you reports: https://github.com/vatesfr/xen-orchestra/issues/5286

I have hopes we can deliver a first version (at least from the CLI) for this month release

olivierlambert created this issue in vatesfr/xen-orchestra

Installed patches on master, now the patches aren't visible on second host.

open Scheduled Rolling pool updates (with reports) for XCP-ng #5286