Hugo docs: Fix random typos and simple word repetitions here and there. (#6269)

Apply a few trivial spelling fixes here and there for:
- Accidental typos
- Word repetitions
- Uppercase of "Markdown" and "JSON-RPC"

Author: psafont

.github/workflows/shellcheck.yaml

@@ -2,10 +2,6 @@ name: ShellCheck
 
 on:
   pull_request:
-    # When only Hugo docs change, this workflow is not required:
-    paths-ignore:
-      - 'doc/**'
-      - '.github/workflows/hugo.yml'
   merge_group:
 
 concurrency:  # On new push, cancel old workflows from the same PR, branch or tag:

doc/content/design/emulated-pci-spec.md

@@ -11,7 +11,7 @@ status: proposed
 At present (early March 2015) the datamodel defines a VM as having a "platform" string-string map, in which two keys are interpreted as specifying a PCI device which should be emulated for the VM. Those keys are "device_id" and "revision" (with int values represented as decimal strings).
 
 Limitations:
-* Hardcoded defaults are used for the the vendor ID and all other parameters except device_id and revision.
+* Hardcoded defaults are used for the vendor ID and all other parameters except device_id and revision.
 * Only one emulated PCI device can be specified.
 
 When instructing qemu to emulate PCI devices, qemu accepts twelve parameters for each device.

doc/content/design/user-certificates.md

@@ -220,7 +220,7 @@ A new class, Certificate, will be added with the following schema:
 | ---------- | --------- | ----- |
 | uuid       |           |
 | type       | CA        | Certificate trusted by all hosts
-|            | Host      | Certificate that the host present sto normal clients
+|            | Host      | Certificate that the host presents to normal clients
 | name       | String    | Name, only present for trusted certificates
 | host       | Ref _host | Host where the certificate is installed
 | not_before | DateTime  | Date after which the certificate is valid

doc/content/squeezed/architecture/index.md

@@ -18,7 +18,7 @@ includes:
   together describe a range, within which the domain's actual used memory
   should remain.
 - Per-domain calibration data which allows us to compute the necessary balloon
-  target value to achive a particular memory usage value.
+  target value to achieve a particular memory usage value.
 
 Squeezed is a single-threaded program which receives commands from xenopsd over
 a Unix domain socket. When Xenopsd wishes to start a new VM, squeezed will be

doc/content/squeezed/squeezer.md

@@ -4,7 +4,7 @@ hidden: true
 ---
 
 {{% notice warning %}}
-This was converted to markdown from squeezer.tex. It is not clear how much
+This was converted to Markdown from squeezer.tex. It is not clear how much
 of this document is still relevant and/or already present in the other docs.
 {{% /notice %}}
 

doc/content/toolstack/high-level/environment.md

@@ -7,14 +7,14 @@ The Toolstack runs in an environment on a server (host) that has:
 
 - Physical hardware.
 - The Xen hypervisor.
-- The control domain (domain 0): the priviledged domain that the Toolstack runs in.
-- Other, mostly unpriviledged domains, usually for guests (VMs).
+- The control domain (domain 0): the privileged domain that the Toolstack runs in.
+- Other, mostly unprivileged domains, usually for guests (VMs).
 
 The Toolstack relies on various bits of software inside the control domain, and directly communicates with most of these:
 
 - Linux kernel including drivers for hardware and Xen paravirtualised devices (e.g. `netback` and `blkback`).
   - Interacts through `/sys` and `/proc`, udev scripts, xenstore, ...
-- CentOS distibution including userspace tools and libraries.
+- CentOS distribution including userspace tools and libraries.
   - systemd, networking tools, ...
 - Xen-specific libraries, especially `libxenctrl` (a.k.a. `libxc`)
 - `xenstored`: a key-value pair configuration database

doc/content/toolstack/responsibilities.md

@@ -3,7 +3,7 @@ title = "Responsibilities"
 weight = 10
 +++
 
-The XAPI Toolstack forms the main control plane of a pool of XenServer hosts. It allow the administrator to:
+The XAPI Toolstack forms the main control plane of a pool of XenServer hosts. It allows the administrator to:
 
 - Configure the hardware resources of XenServer hosts: storage, networking, graphics, memory.
 - Create, configure and destroy VMs and their virtual resources.

doc/content/xen-api/topics/udhcp.md

@@ -11,7 +11,7 @@ the network.
 
 It should be noted that for this reason, that callers who modify the
 default configuration should be aware that their changes may have an
-adverse affect on other consumers of the HIMN.
+adverse effect on other consumers of the HIMN.
 
 Version history
 ---------------

doc/content/xen-api/wire-protocol.md

@@ -285,7 +285,7 @@ contains the members `jsonrpc`, `method`, `params`, and `id`.
   (requests without responses).
 
 For example, the body of a JSON-RPC v2.0 request to retrieve the VMs resident on
-a host may may look like this:
+a host may look like this:
 
 ```json
   {
@@ -538,7 +538,7 @@ you must login and initiate a session. For example:
 where `uname` and `password` refer to your username and password, as defined by
 the Xen administrator, while `version` and `originator` are optional. The
 `session ref` returned by `session.login_with_password` is passed
-to subequent RPC calls as an authentication token. Note that a session
+to subsequent RPC calls as an authentication token. Note that a session
 reference obtained by a login request to the XML-RPC backend can be used in
 subsequent requests to the JSON-RPC backend, and vice-versa.
 
@@ -565,7 +565,7 @@ Instead of returning its result directly, an asynchronous RPC call
 returns an identifier of type `task ref` which is subsequently used
 to track the status of a running asynchronous RPC.
 
-Note that an asychronous call may fail immediately, before a task has even been
+Note that an asynchronous call may fail immediately, before a task has even been
 created. When using the XML-RPC wire protocol, this eventuality is represented
 by wrapping the returned `task ref` in an XML-RPC struct with a `Status`,
 `ErrorDescription`, and `Value` fields, exactly as specified above; the

doc/content/xenopsd/design/Tasks.md

@@ -124,7 +124,7 @@ helper function
 [perform_atomics](https://github.com/xapi-project/xenopsd/blob/f876f9029cf53f14a52bf42a4a3a03265e048926/lib/xenops_server.ml#L1092)
 which divides the progress 'bar' into sections, where each "micro-op" can have
 a different size (`weight`). A progress callback function is passed into
-each Xenopsd backend function so it can be updated with fine granulatiry. For
+each Xenopsd backend function so it can be updated with fine granularity. For
 example note the arguments to
 [B.VM.save](https://github.com/xapi-project/xenopsd/blob/f876f9029cf53f14a52bf42a4a3a03265e048926/lib/xenops_server.ml#L1092)