diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md index 403533f..c6479f0 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.md +++ b/.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. - diff --git a/doc/source/airship2/layering.rst b/doc/source/airship2/layering.rst index 70d4056..2cc6feb 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 @@ -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..2c6065b 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. @@ -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') - diff --git a/doc/source/airship2/site-setup.rst b/doc/source/airship2/site-setup.rst index 235c81b..0955341 100644 --- a/doc/source/airship2/site-setup.rst +++ b/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 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/crd-conventions.rst b/doc/source/develop/crd-conventions.rst index 4054370..9eaa437 100644 --- a/doc/source/develop/crd-conventions.rst +++ b/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 ``.airshipit.org``. .. _Kubernetes API Conventions: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md - 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.