Minor updates of the Hugo documentation:

- The current Ubuntu snap package of Hugo is not supported by the docs.
  We should take a first minor step towards fixing this.

- `doc/README.md` is outdated and should be updated.
  It says that the Ubuntu snap of Hugo works, but it does not anymore.
  Fix this by updating the outdated information.

- An initial fix is to update the Relearn theme from 5.20.x to 5.23.0:
  - It does not introduce breaking changes.
  - It introduces more straightforward page links and deprecates older syntax.
  - Fix the warnings by updating relative links accordingly.

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>

Minor updates of the Hugo documentation:

- The current Ubuntu `snap` package of Hugo is not supported by the
docs.
  We should take a first minor step towards fixing this.

-
[`doc/README.md`](https://github.com/xapi-project/xen-api/blob/master/doc/README.md)
is outdated and should be updated ([new
version](https://github.com/xenserver-next/xen-api/blob/docs-update-README-and-hugo-relearn-to-5.23/doc/README.md)).
  It says that the Ubuntu snap of Hugo works, but it does not anymore.
  Fix this by updating the outdated information.

- An initial fix is to update the Relearn theme from 5.20.x to 5.23.0:
  - It does not introduce breaking changes.
- It introduces more straightforward page links and deprecates older
syntax.
  - Fix the warnings by updating relative links accordingly.

A preview is available on my site:
https://xenserver-next.github.io/xen-api/index.html

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>

…instead

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>

When the coordinator restarts. the no-other-masters check in the startup
sequence does two things for each pool member:

1. It checks that the host agrees that it is are not the coordinator.
2. It unblocks the host's master_connection thread, which is likely waiting
   for a reconnection delay to expire, which may be up to 256 seconds
   (exponential backoff is used). The delay is interrupted to
   immediately unblock DB calls.

Licensing initialisation comes earlier in the startup sequence, but
under certain circumstance make calls to other host, in particular after
an upgrade. A this time, hosts may still be blocked on the
master_connection for up to 256 s, which adds an unnecessary delay to
the coordinator's startup sequence and therefore the usability of the
API.

Address this by reversing the order of the two startup actions.

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>

…instead (#6255)

For links to internal pages, `{{site.baseurl}}` (without the leading
`.`) does not
work in current Hugo, and it is better to replace it by using relative
links:

`{{.Site.BaseURL}}` is replaced in the rendered output, but it doesn't
work when
viewing and editing the files using Markdown editors and viewers like on
GitHub/Lab
as well as IDEs with improved support for Markdown editing(in editor and
preview).

As the relative links work in all cases like in the editors and
previews,
fix those (currently broken) links to use the relative links instead.

While at those, also replace the link name "here" with a more specific
link name.

PS: The only place were `{{.Site.BaseURL}}` or similar is needed is the
link in
the `logo.html` template for
`img="{{.Site.BaseURL}}/images/xapi-project.png"`

When the coordinator restarts. the no-other-masters check in the startup
sequence does two things for each pool member:

1. It checks that the host agrees that it is are not the coordinator.
2. It unblocks the host's master_connection thread, which is likely
waiting
   for a reconnection delay to expire, which may be up to 256 seconds
   (exponential backoff is used). The delay is interrupted to
   immediately unblock DB calls.

Licensing initialisation comes earlier in the startup sequence, but
under certain circumstance make calls to other host, in particular after
an upgrade. A this time, hosts may still be blocked on the
master_connection for up to 256 s, which adds an unnecessary delay to
the coordinator's startup sequence and therefore the usability of the
API.

Address this by reversing the order of the two startup actions.

The call currently calls `network.attach` on all networks, but this
fails for PIFs that are not managed by xapi. Simply skip those.

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>

…6259)

The call currently calls `network.attach` on all networks, but this
fails for PIFs that are not managed by xapi. Simply skip those.

This reverts commit 889dfa6. As there
is no need to clean up the source VM earlier at all, VM_save already
does the job of deactivating the source VM datapath.

Signed-off-by: Vincent Liu <shuntian.liu2@cloud.com>

Previously the `post_detach_hook` was run after the VDI is detached on
the source VM, which is at the very end of the SXM, where the source VM
is shutdown. However, the job of `post_detach_hook` is to call
`Remote.receive_finalize` which will destroy the mirroring datapath.
This should have been called as soon as we deactivate the datapath on
the source VM, at which point the source VM will stop writing using that
datapath. This commit changes `post_detach_hook` to
`post_deactivate_hook` and moves its calling locations accordingly.

Signed-off-by: Vincent Liu <shuntian.liu2@cloud.com>

…6254)

Optional improvement for fast CI completion when only Hugo docs change
on push/PRs:

When only Hugo docs change on push and PRs, other workflows can be
skipped using
`paths-ignore:` for `docs/**` and `.github/workflows/hugo.yml` to not
trigger other
workflows if only these paths change when pushing to a branch / work on
a PR.

This is completely optional, but would be nice to have when only working
on Hugo docs.
It does not change scheduled CI runs. It changes only on-demand push/PR
workflow runs.

…t_deactivate (#6260)

There are two parts to this PR:

1. Reverts the VM migration ordering change, which was previously
thought to be necessary as I did not see `VM_save` would actually
deactivate the source VM datapath. Thanks @edwintorok for pointing that
out.
2. Change `post_detach_hook` to `post_deactivate_hook`, as this should
have been called as soon as the datapath is deactivated, at which point
all r/w using that datapath will be stopped.

More details in the commit message.