From 3bd726540a894da859150cbe1c68e004a5f6ee62 Mon Sep 17 00:00:00 2001 From: "Herrera, Josh (jh813b)" Date: Tue, 28 Sep 2021 16:58:18 -0700 Subject: [PATCH] Fix spelling errors in docs folders Updated rst files with correct spelling. Change-Id: Idada9491c6c8b98be721fcfc410323f56a93c9c4 --- doc/source/airship1/airship-1-flow.rst | 4 ++-- doc/source/airship2/layering.rst | 14 +++++++------- doc/source/airship2/site-authoring.rst | 4 ++-- doc/source/airship2/site-deployment.rst | 16 ++++++++-------- doc/source/develop/api-conventions.rst | 6 +++--- doc/source/develop/code-conventions.rst | 4 ++-- doc/source/develop/documentation-conventions.rst | 6 +++--- .../develop/service-logging-conventions.rst | 2 +- 8 files changed, 28 insertions(+), 28 deletions(-) diff --git a/doc/source/airship1/airship-1-flow.rst b/doc/source/airship1/airship-1-flow.rst index 360c259..1e6107e 100644 --- a/doc/source/airship1/airship-1-flow.rst +++ b/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 diff --git a/doc/source/airship2/layering.rst b/doc/source/airship2/layering.rst index 70d4056..4ac8324 100644 --- a/doc/source/airship2/layering.rst +++ b/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 diff --git a/doc/source/airship2/site-authoring.rst b/doc/source/airship2/site-authoring.rst index ed3035a..cbccc61 100644 --- a/doc/source/airship2/site-authoring.rst +++ b/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) diff --git a/doc/source/airship2/site-deployment.rst b/doc/source/airship2/site-deployment.rst index 0eadc58..4542384 100644 --- a/doc/source/airship2/site-deployment.rst +++ b/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 diff --git a/doc/source/develop/api-conventions.rst b/doc/source/develop/api-conventions.rst index 520176a..b5038b9 100644 --- a/doc/source/develop/api-conventions.rst +++ b/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 diff --git a/doc/source/develop/code-conventions.rst b/doc/source/develop/code-conventions.rst index 32cd930..474ecf5 100644 --- a/doc/source/develop/code-conventions.rst +++ b/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. diff --git a/doc/source/develop/documentation-conventions.rst b/doc/source/develop/documentation-conventions.rst index 22c13ce..94e2f40 100644 --- a/doc/source/develop/documentation-conventions.rst +++ b/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 diff --git a/doc/source/develop/service-logging-conventions.rst b/doc/source/develop/service-logging-conventions.rst index 11e491e..b19b330 100644 --- a/doc/source/develop/service-logging-conventions.rst +++ b/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.