Some documentaion improvements for ironic docs

The documentation contains a significant amount of grammar mistakes.

This could cause confusion in certain scenarios to correctly understanding the
context. Starting to go though the documentation and pushing this commit
as a start.

Change-Id: If2c18909a83ba501b5ffae494934fb631b009e54

doc/source/admin/agent-power.rst

@@ -26,7 +26,7 @@ The expected workflow is as follows:
    power only requires to be able to connect to the agent.
 
 #. The operator moves the node to `available`. Cleaning happens normally via
-   the already running agent. If reboot is needed, it is done by telling the
+   the already running agent. If a reboot is needed, it is done by telling the
    agent to reboot the node in-band.
 
 #. A user deploys the node. Deployment happens normally via the already
@@ -70,7 +70,7 @@ Limitations
 
 * Undeploy and rescue are not supported, you need to add BMC credentials first.
 
-* If any errors happens in the process, recovery will likely require BMC
+* If any errors happen in the process, recovery will likely require BMC
   credentials.
 
 * Only rebooting is possible through the API, power on/off commands will fail.

doc/source/admin/agent-token.rst

@@ -25,26 +25,26 @@ How it works
 
 These tokens are provided in one of two ways to the running agent.
 
-1. A pre-generated token which is embedded into virtual media ISOs.
-2. A one-time generated token that are provided upon the first "lookup"
+1. A pre-generated token that is embedded into virtual media ISOs.
+2. A one-time generated token that is provided upon the first "lookup"
    of the node.
 
-In both cases, the tokens are a randomly generated using the Python
+In both cases, the tokens are randomly generated using the Python
 ``secrets`` library. As of mid-2020, the default length is 43 characters.
 
 Once the token has been provided, the token cannot be retrieved or accessed.
-It remains available to the conductors, and is stored in memory of the
+It remains available to the conductors, and is stored in the memory of the
 ``ironic-python-agent``.
 
 .. note::
    In the case of the token being embedded with virtual media, it is read
-   from a configuration file with-in the image. Ideally this should be paired
+   from a configuration file within the image. Ideally, this should be paired
    with Swift temporary URLs.
 
 With the token is available in memory in the agent, the token is embedded with
 ``heartbeat`` operations to the ironic API endpoint. This enables the API to
 authenticate the heartbeat request, and refuse "heartbeat" requests from the
-``ironic-python-agent``. As of the Victoria release, use of Agent Token is
+``ironic-python-agent``. As of the Victoria release, the use of Agent Token is
 required for all agents and the previously available setting to force this
 functionality to be mandatory, ``[DEFAULT]require_agent_token`` has been removed
 and no longer has any effect.
@@ -73,7 +73,7 @@ With PXE/iPXE/etc.
 Agent Configuration
 ===================
 
-An additional setting which may be leveraged with the ``ironic-python-agent``
+An additional setting that may be leveraged with the ``ironic-python-agent``
 is a ``agent_token_required`` setting. Under normal circumstances, this
 setting can be asserted via the configuration supplied from the Bare Metal
 service deployment upon the ``lookup`` action, but can be asserted via the

doc/source/admin/anaconda-deploy-interface.rst

@@ -64,7 +64,7 @@ package groups that need to be in the image:
         install cloud-init
         ts run
 
-An OS tarball can be created using following set of commands, along with the above
+An OS tarball can be created using the following set of commands, along with the above
 ``baremetal.yum`` file:
 
 .. code-block:: shell
@@ -155,12 +155,12 @@ ironic node:
 
 .. warning::
    In the Ironic Project terminology, the word ``template`` often refers to
-   a file which is supplied to the deployment, which Ironic supplies
+   a file that is supplied to the deployment, which Ironic supplies
    parameters to render a specific output. One critical example of this in
    the Ironic workflow, specifically with this driver, is that the generated
    ``agent token`` is conveyed to the booting ramdisk, facilitating it to call
    back to Ironic and indicate the state. This token is randomly generated
-   for every deploy, and is required. Specifically this is leveraged in the
+   for every deploy, and is required. Specifically, this is leveraged in the
    template's ``pre``, ``onerror``, and ``post`` steps.
    For more information on Agent Token, please see :doc:`/admin/agent-token`.
 
@@ -168,7 +168,7 @@ Standalone deployments
 ----------------------
 
 While this deployment interface driver was developed around the use of other
-OpenStack services, it is not explicitly required. For example HTTP(S) URLs
+OpenStack services, it is not explicitly required. For example, HTTP(S) URLs
 can be supplied by the API user to explicitly set the expected baremetal node
 ``instance_info`` fields
 
@@ -182,7 +182,7 @@ can be supplied by the API user to explicitly set the expected baremetal node
 
 When doing so, you may wish to also utilize a customized kickstart template,
 which can also be a URL. Please reference the ironic community provided
-template *ks.cfg.template* and use it as a basis of your own kickstart
+template *ks.cfg.template* and use it as a basis for your own kickstart
 as it accounts for the particular stages and appropriate callbacks to
 Ironic.
 
@@ -252,7 +252,7 @@ parameter, and the node deployed.
 Deployment Process
 ------------------
 
-At a high level, the mechanics of the anaconda driver works in the following
+At a high level, the mechanics of the anaconda driver work in the following
 flow, where we also note the stages and purpose of each part for informational
 purposes.
 
@@ -281,16 +281,16 @@ based deployments, but the way the anaconda deployment interface works,
 you may need to make some adjustments.
 
 * :oslo.config:option:`conductor.deploy_callback_timeout` likely needs to be adjusted
-  for most ``anaconda`` deployment interface users. By default this
-  is a timer which looks for "agents" which have not checked in with
+  for most ``anaconda`` deployment interface users. By default, this
+  is a timer that looks for "agents" that have not checked in with
   Ironic, or agents which may have crashed or failed after they
   started. If the value is reached, then the current operation is failed.
   This value should be set to a number of seconds which exceeds your
   average anaconda deployment time.
 * :oslo.config:option:`pxe.boot_retry_timeout` can also be triggered and result in
   an anaconda deployment in progress getting reset as it is intended
-  to reboot nodes which might have failed their initial PXE operation.
-  Depending on sizes of images, and the exact nature of what was deployed,
+  to reboot nodes that might have failed their initial PXE operation.
+  Depending on the sizes of images, and the exact nature of what was deployed,
   it may be necessary to ensure this is a much higher value.
 
 Limitations

doc/source/admin/api-audit-support.rst

@@ -4,8 +4,8 @@
 API Audit Logging
 =================
 
-Audit middleware supports delivery of CADF audit events via Oslo messaging
-notifier capability. Based on `notification_driver` configuration, audit events
+Audit middleware supports the delivery of CADF audit events via the Oslo messaging
+notifier capability. Based on the `notification_driver` configuration, audit events
 can be routed to messaging infrastructure (notification_driver = messagingv2)
 or can be routed to a log file (`[oslo_messaging_notifications]/driver = log`).
 
@@ -30,17 +30,17 @@ to ``/etc/ironic/ironic.conf``.
     enabled=true
 
 #. To customize auditing API requests, the audit middleware requires the audit_map_file setting
-   to be defined. Update the value of configuration setting 'audit_map_file' to set its
+   to be defined. Update the value of the configuration setting 'audit_map_file' to set its
    location. Audit map file configuration options for the Bare Metal service are included
    in the etc/ironic/ironic_api_audit_map.conf.sample file. To understand CADF format
-   specified in ironic_api_audit_map.conf file refer to `CADF Format.
+   specified in ironic_api_audit_map.conf file, refer to `CADF Format.
    <http://www.dmtf.org/sites/default/files/standards/documents/DSP2038_1.0.0.pdf>`_::
 
     [audit]
     ...
     audit_map_file=/etc/ironic/api_audit_map.conf
 
-#. Comma separated list of Ironic REST API HTTP methods to be ignored during audit.
+#. Comma-separated list of Ironic REST API HTTP methods to be ignored during audit.
    It is used only when API audit is enabled. For example::
 
     [audit]
@@ -50,7 +50,7 @@ to ``/etc/ironic/ironic.conf``.
 Sample Audit Event
 ==================
 
-Following is the sample of audit event for ironic node list request.
+Following is the sample of the audit event for the ironic node list request.
 
 .. code-block:: json