Hugo docs: Fix a few minor spelling issues (missing spaces, words, etc)

doc/content/design/patches-in-vdis.md

@@ -71,7 +71,7 @@ Changes beneath the XenAPI
 Summary of the impact on the admin
 ==================================
 
-- There will nolonger be a size limit on hotfixes imposed by the mechanism
+- There will no longer be a size limit on hotfixes imposed by the mechanism
   itself.
 - There must be enough free space in an SR connected to the host to be able
   to apply a patch on that host.

doc/content/design/schedule-snapshot.md

@@ -28,8 +28,8 @@ Introduction
 * Multiple VMs can be a part of VMSS but a VM cannot be a part of multiple VMSS.
 * A VMSS takes VMs snapshot with type [`snapshot`, `checkpoint`, `snapshot_with_quiesce`].
 * VMSS takes snapshot of VMs on configured intervals:
-	* `hourly` -> On everyday, Each hour, Mins [0;15;30;45]
-	* `daily` -> On everyday, Hour [0 to 23], Mins [0;15;30;45]
+	* `hourly` -> On every day, Each hour, Mins [0;15;30;45]
+	* `daily` -> On every day, Hour [0 to 23], Mins [0;15;30;45]
 	* `weekly` -> Days [`Monday`,`Tuesday`,`Wednesday`,`Thursday`,`Friday`,`Saturday`,`Sunday`], Hour[0 to 23], Mins [0;15;30;45]
 * VMSS will have a limit on retaining number of VM snapshots in range [1 to 10].
 

doc/content/design/user-certificates.md

@@ -16,7 +16,7 @@ and not impersonating the actual host.
 Historically there has not been a supported mechanism to do this, and as a
 result users have had to rely on guides written by third parties that show how
 to manually replace the xapi-ssl.pem file on a host. This process is
-error-prone, and if a mistake is made, can result in an unuseable system.
+error-prone, and if a mistake is made, can result in an unusable system.
 This design provides a fully supported mechanism to allow replacing the
 certificates.
 
@@ -200,7 +200,7 @@ should be removed to avoid a build-up of messages.
 
 Additionally, the task may also produce messages for expired server
 certificates which must use the name `HOST_SERVER_CERTIFICATE_EXPIRED`.
-These kind of message must contain the message "The TLS server certificate has
+This kind of message must contain the message "The TLS server certificate has
 expired." as well as the expiry date, like the expiring messages.
 They also may replace the existing expiring messages in a host.
 
@@ -246,7 +246,7 @@ and it will accept the parameter `host-uuid=<uuid>`.
 ## Recovery mechanism
 
 In the case a certificate is let to expire TLS clients connecting to the host
-will refuse establish the connection.
+will refuse to establish the connection.
 This means that the host is going to be unable to be managed using the xapi
 API (Xencenter, or a CVAD control plane)
 

doc/content/xen-api/basics.md

@@ -15,7 +15,7 @@ recognized). No specific language bindings are prescribed, although examples
 are given in the Python programming language.
 
 Although we adopt some terminology from object-oriented programming,
-future client language bindings may or may not be object oriented.
+future client language bindings may or may not be object-oriented.
 The API reference uses the terminology _classes_ and _objects_.
 For our purposes a _class_ is simply a hierarchical namespace;
 an _object_ is an instance of a class with its fields set to

doc/content/xen-api/evolution.md

@@ -60,11 +60,10 @@ The numbered state changes in the diagram have the following meaning:
 4. Deprecate: declare that the use of this XenAPI element should be avoided from
    now on. Reasons for doing this include: the element is redundant (it
    duplicates functionality elsewhere), it is inconsistent with other parts of
-   the XenAPI, it is insecure or inefficient (for examples of deprecation
-   policies of other projects, see
-   [symbian](http://developer.symbian.org/wiki/index.php/Public_API_Change_Control_Process)
-   [eclipse](http://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy)
-   [oval](http://oval.mitre.org/language/about/deprecation.html).
+   the XenAPI, it is insecure or inefficient.
+   For examples of deprecation policies of other projects, see the policies of the
+   [eclipse](https://github.com/eclipse-platform/eclipse.platform/blob/master/docs/Eclipse_API_Central_Deprecation_Policy.md)
+   and [oval](http://oval.mitre.org/language/about/deprecation.html) projects.
 5. Remove: the element is taken out of the public API and can no longer be used.
 
 Each lifecycle transition must be accompanied by an explanation describing the

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

@@ -540,7 +540,7 @@ 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
 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.
+subsequent requests to the JSON-RPC backend, and vice versa.
 
 A session can be terminated with the `session.logout` function:
 

doc/content/xenopsd/design/Tasks.md

@@ -175,7 +175,7 @@ types of cancel callback:
 2. cancellable subprocesses
 
 Xenstore watches are used for device hotplug and unplug. Xenopsd has to wait for
-the backend or for a udev script to do something. If that blocks then we need
+the backend or for a udev script to do something. If that blocks, we need
 a way to cancel the watch. The easiest way to cancel a watch is to watch an
 additional path (a "cancel path") and delete it, see
 [cancellable_watch](https://github.com/xapi-project/xenopsd/blob/f876f9029cf53f14a52bf42a4a3a03265e048926/xc/cancel_utils.ml#L117).