Fix spelling errors in docs folders

Updated rst files with correct spelling.

Change-Id: Idada9491c6c8b98be721fcfc410323f56a93c9c4

doc/source/airship1/airship-1-flow.rst

@@ -19,7 +19,7 @@ Airship 1.0 Deploy and Update Site Flow
    and finally site-level repositories.  These may be entirely different
    repositories with different permissions.  Pegleg facilitates cloning
    all of these at the correct revisions according to the definition for
-   that site. Pegleg can be driven via a jenkins pipeline, which can be
+   that site. Pegleg can be driven via a Jenkins pipeline, which can be
    further abstracted in something like an NC3C dashboard, or it can be
    driven on the command line directly by imitating the behavior in the
    pipeline.
@@ -73,7 +73,7 @@ Airship 1.0 Deploy and Update Site Flow
 |vspace|
 
 3. Once pegleg has decrypted the secrets in the document set within an
-   ephemeral jenkins pipeline, pegleg collect is called to assemble them
+   ephemeral Jenkins pipeline, pegleg collect is called to assemble them
    all, and finally that is piped to the shipyard client which will
    publish them via REST API to a Shipyard API service running within the
    site. There are two scenarios under which Shipyard may be running in

doc/source/airship2/layering.rst

@@ -57,7 +57,7 @@ and relationships between layers are captured by a
 ``kustomization.yaml`` referencing an external Kustomization.  Additionally,
 Airship layers may refer to layers in other code repositories, and Airship
 will ensure all required projects are present and in expected locations relative
-to a site defintion.  This allows for operator-specific (upstream or downstream)
+to a site definition.  This allows for operator-specific (upstream or downstream)
 repositories to inherit and reuse the bulk of declarative intent from
 common, upstream sources; e.g. the Airship Treasuremap_ project.
 By convention, Airship manifests can be found in a project's
@@ -88,7 +88,7 @@ which is used by projects such as ``kubectl``, ``kpt``, and ``airshipctl``.
 Airshipctl incorporates Kustomize into its higher-order functionality, so
 that it's invoked as part of ``airshipctl phase run``, rendering
 manifests into a deployable form before deploying them directly to a
-Kubernetes apiserver.  However, Airship follows the design decision for
+Kubernetes api server.  However, Airship follows the design decision for
 its YAMLs to be fully renderable using the stock ``kustomize`` command.
 
 The basic building block for Kustomize manifests is called a "kustomization",
@@ -119,7 +119,7 @@ ReplacementTransformer
 Kustomize is very good at layering patches on top of resources, but has
 some weakness when performing substitution/replacement type operations,
 i.e., taking information from one document and injecting it into another
-document.  This operation is very critical to Airship from a de-duplication
+document.  This operation is very critical to Airship from a deduplication
 perspective, since the same information (e.g. a Kubernetes version or
 some networking information) would be needed in multiple resources.
 Replacement helps satisfy the DRY principle.  Although Kustomize has a few
@@ -147,7 +147,7 @@ While ReplacementTransformer modifies existing resources, the Templater
 is a Kustomize "generator" plugin that creates brand new resources based
 on a Go Template.  This is helpful when you have a number of resources
 that are nearly identical, and allows the common parts to be
-de-duplicated into a template.  An example of this would be resources
+deduplicated into a template.  An example of this would be resources
 that are specific per-host (like Metal3 ``BareMetalHost``).
 
 The ReplacementTransformer and Templater can also be combined in a chain,
@@ -164,7 +164,7 @@ Encryption, Decryption, and Secret Generation
 Encryption and decryption is handled via the `sops` KRM Function maintained
 by the KPT community.  This function in turn uses the Mozilla SOPS tool
 to perform asymmetric key-based decryption on encrypted values within
-YAML resources.  
+YAML resources.
 
 In addition, passwords, keys, and other sensitive secrets can be generated
 from scratch on a site-by-site basis.  This helps ensure that secrets are
@@ -185,7 +185,7 @@ one resource.  However, it does not solve for the case where some piece
 of configuration, e.g. a Kubernetes version number, needs to be applied
 against multiple resources that need it.  Using patches alone, this would
 result in duplicating the same version number defined in multiple patches
-within the same layer, increasing both maintenace effort and opportunity
+within the same layer, increasing both maintenance effort and opportunity
 for human error.  To address this, Airship uses the ReplacementTransformer
 plugin described above.
 
@@ -303,7 +303,7 @@ on an operator-by-operator basis (for shared network services like DNS),
 and on a site-by-site basis (for subnet IP address ranges).
 This information is extracted into a VariableCatalogue with
 ``name: networks``.  Individual functions that consume the information will
-provide their own replacent rules to do so.
+provide their own replacement rules to do so.
 
 A default/example set of values is defined in the ``airshipctl-catalogues``
 function, and it can be patched (or duplicated) at the Type or Site levels to

doc/source/airship2/site-authoring.rst

@@ -78,7 +78,7 @@ tasks.
    ./tools/init_site.sh
 
 .. note::
-   The environment variables have default values that point to arishipctl
+   The environment variables have default values that point to airshipctl
    release tag v2.0.0 and treasuremap release tag v2.0.0. You only need
    to (re)set them in the command line if you want a different release
    version, a branch or a specific commit.
@@ -123,7 +123,7 @@ Before you start, collect the following network information:
    * PXE network interface name
    * The name of the two 25G networks used for the bonded interface
    * OAM, Calico and Storage VLAN ID's
-   * OAM, Calico and Storage netowrk configuration
+   * OAM, Calico and Storage network configuration
    * PXE, OAM, Calico and Storage IP addresses for ephemeral/controller nodes
      and worker nodes
    * Kubernetes and ingress virtual IP address (on OAM)

doc/source/airship2/site-deployment.rst

@@ -3,8 +3,8 @@
 Site Deployment Guide
 =====================
 
-This document is the Airshp 2 site deployment guide for a standard greenfield
-bare metal deployment. The following sections decribes how to apply the site
+This document is the Airship 2 site deployment guide for a standard greenfield
+bare metal deployment. The following sections describes how to apply the site
 manifests for a given site.
 
 Prerequisites
@@ -27,10 +27,10 @@ sets of commands together for a particular deployment step into one phase apply
 command. This greatly simplifies executing deployment.
 
 The Airship 2 deployment uses heavily the ``airshipctl`` commands, especially the
-``airshipctl phase run`` commands. You may find it helpful to get familirized with
+``airshipctl phase run`` commands. You may find it helpful to get familiarized with
 the `airshipctl command reference`_ and `example usage`_.
 
-To faciliate the site deployment, the Airship Treasuremap project provides a
+To facilitate the site deployment, the Airship Treasuremap project provides a
 set of deployment scripts in the ``tools/deployment`` directory. These scripts
 are wrappers of the `airshipctl` commands with additional flow controls. They
 are numbered sequentially in the order of the deployment operations.
@@ -51,7 +51,7 @@ already configured with default values for a typical deployment or inferred
 from other configuration files or site manifests. In most situations, users
 do not need to manually set the values for these environment variables.
 
- * ``KUBECONFIG``: The location of kubeconfig file. Default value:
+ * ``KUBECONFIG``: The location of the kubeconfig file. Default value:
    ``$HOME/.airship/kubeconfig``.
  * ``KUBECONFIG_TARGET_CONTEXT``: The name of the kubeconfig context for the
    target cluster. Default value: "target-cluster". You can find it defined
@@ -183,7 +183,7 @@ used by other systems. Secrets can also be internally generated by Airshipctl,
 e.g., Openstack Keystone password, that no external systems will provide or
 need.
 
-To have Airshipctl generate and encrypt the secrets, run the following scrript
+To have Airshipctl generate and encrypt the secrets, run the following script
 from the treasuremap directory:
 
 .. code-block:: bash
@@ -296,7 +296,7 @@ Estimated runtime: **10 minutes**
 .. note:: If desired or if Redfish is not available, the ISO image can be
   mounted through other means, e.g. out-of-band management or a USB drive.
 
-Now the ephemeral node is estbalished, we can deploy ``Calico``, ``metal3.io`` and
+Now the ephemeral node is established, we can deploy ``Calico``, ``metal3.io`` and
 ``cluster-api`` components onto the ephemeral node:
 
 .. code-block:: bash
@@ -327,7 +327,7 @@ Create the target Kubernetes cluster resources:
 
 Estimated runtime: **25 minutes**
 
-Deploy infrastructure components inlcuding Calico and meta3.io:
+Deploy infrastructure components including Calico and meta3.io:
 
 .. code-block:: bash
 

doc/source/develop/api-conventions.rst

@@ -109,7 +109,7 @@ Required Headers
 
 X-Auth-Token
   The auth token to identify the invoking user. Required unless the resource is
-  explictly unauthenticated.
+  explicitly unauthenticated.
 
 Optional Headers
 ----------------
@@ -215,14 +215,14 @@ ValidationMessage:
    the design documents by schema and name that were involved in the specific
    validation. If the documents element is not provided, or is an empty list,
    the assumption is that the validation is not traced to a document, and may
-   be a validaiton of environmental or process needs.
+   be a validation of environmental or process needs.
 
    -  schema (required): The schema of the document.
       E.g. drydock/NetworkLink/v1
    -  name (required): The name of the document.
       E.g. pxe-rack1
 
--  error (required): true if the message indcates an error, false if the
+-  error (required): true if the message indicates an error, false if the
    message indicates a non-error.
 -  kind (required): ValidationMessage
 -  level (required): The severity of the validation result. This should align

doc/source/develop/code-conventions.rst

@@ -125,7 +125,7 @@ should implement each of the following Makefile targets:
 -  ``docs`` should render any documentation that has build steps.
 -  ``run_{component_name}`` should build the image and do a rudimentary (at
    least) test of the image's functionality.
--  ``run_images`` performs the inidividual run_{component_name} targets for
+-  ``run_images`` performs the individual run_{component_name} targets for
    projects that produce more than one image.
 -  ``tests`` to invoke linting tests (e.g. PEP-8) and unit tests for the
    components in the project
@@ -255,7 +255,7 @@ target language ecosystem.
 For Python projects, the preferred location for tests is a ``tests`` directory
 under the directory for the module. E.g. Tests for module foo:
 {root}/src/bin/foo/foo/tests.
-An alternataive location is ``tests`` at the root of the project, although this
+An alternative location is ``tests`` at the root of the project, although this
 should only be used if there are not multiple components represented in the
 same repository, or if the tests cross the components in the repository.
 

doc/source/develop/documentation-conventions.rst

@@ -29,7 +29,7 @@ Consumer documentation is that which is intended to be referenced by users of
 the component. This includes information about each of the following:
 
 -  Introduction - the purpose and charter of the software
--  Features - capabilies the software has
+-  Features - capabilities the software has
 -  Usage - interaction with the software - e.g. API and CLI documentation
 -  Setup/Installation - how an end user would set up and run the software
    including system requirements
@@ -41,8 +41,8 @@ Developer Documentation
 Developer documentation is used by developers of the software, and addresses
 the following topics:
 
--  Archiecture and Design - features and structure of the software
--  Inline, Code, Method - documentaiton specific to the fuctions and procedures
+-  Architecture and Design - features and structure of the software
+-  Inline, Code, Method - documentation specific to the functions and procedures
    in the code
 -  Development Environment - explaining how a developer would need to configure
    a working environment for the software

doc/source/develop/service-logging-conventions.rst

@@ -33,7 +33,7 @@ reasonable approximation is desired.
 
 Where:
 
--  Timestamp is like ``2006-02-08 22:20:02,165``, or the standard ouptut from
+-  Timestamp is like ``2006-02-08 22:20:02,165``, or the standard output from
    ``%(asctime)s``
 -  Level is 'DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL', padded to 8
    characters, left aligned.