Fixed some typos and links in Airship docs

Signed-off-by: bijayasharma <vetbijaya@gmail.com>
Change-Id: I5d453720a586368d7ca37536511c0043fd418fde

.github/ISSUE_TEMPLATE/feature_request.md

@@ -12,4 +12,3 @@ A description of the documentation enhancement or addition.
 
 **Proposed change**
 A detailed description of the new change, any verbiage to be included, etc.
-

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
@@ -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.
@@ -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
 
@@ -444,4 +444,3 @@ the nodes and clean up the deployment artifacts on the build node as follows:
    rm -rf ~/.airship/ /srv/images/*
    docker rm -f -v $(sudo docker ps --all -q | xargs -I{} sudo bash -c 'if docker inspect {} | grep -q airship; then echo {} ; fi')
    docker rmi -f $(sudo docker images --all -q | xargs -I{} sudo bash -c 'if docker image inspect {} | grep -q airship; then echo {} ; fi')
-

doc/source/airship2/site-setup.rst

@@ -7,7 +7,7 @@ Component Overview
 ------------------
 
 Airship uses a command line utility airshipctl that drives the deployment and
-lifecycling management of Kubernetes clouds and software stacks.
+life cycling management of Kubernetes clouds and software stacks.
 
 This utility articulates lifecycle management as a list of phases, or as a
 plan of phases or plan. For each of these phases, a YAML document set is
@@ -87,7 +87,7 @@ Disk
    support the integration with the `Rook Storage Operator`_. However, the
    manifests for the Rook deployment can be found in the
    ``manifests/function/rook-operator`` directory. If you plan to include
-   Rook for Ceph storage, it is recommeneded to have the additional disks
+   Rook for Ceph storage, it is recommended to have the additional disks
    on all the controller nodes and worker nodes:
 
    - Two disks JBOD: Ceph Journal and Metadata

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/crd-conventions.rst

@@ -20,7 +20,7 @@ CRD Conventions
 ===============
 
 Airship will use CRDs to enrich the Kubernetes API with Airship-specific
-document schema.  Airship projects will follow the following conventions
+document schema. Airship projects will follow the following conventions
 when defining Custom Resource Definitions (CRDs).
 
 Note that Airship integrates and consumes a number of projects from
@@ -41,4 +41,3 @@ this list may grow in the future.
    following the convention ``<function>.airshipit.org``.
 
 .. _Kubernetes API Conventions: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md
-

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.