Fix typos

This patch tries to fix maximum typos in docs.

Change-Id: Ic406e3a4423cdd7c46c8a4497d43d63c95b2a9f5

deploy-guide/source/deployment/3rd_party.rst

@@ -153,8 +153,8 @@ Here are some of them:
   the default path for <config-file> will be modified.
 * `--exclude` to skip some containers during the build.
 * `--registry` to specify a Container Registry where the images will be pushed.
-* `--authfile` to specify an authentification file if the Container Registry
-  requires authentification.
+* `--authfile` to specify an authentication file if the Container Registry
+  requires authentication.
 * `--skip-build` if we don't want to build and push images. It will only
   generate the configuration files.
 * `--push` to push the container images into the Container Registry.
@@ -305,7 +305,7 @@ Either way, if you need to run a privileged container, make sure to set this par
 
     privileged: true
 
-If privilege mode isn't required, it is suggested to set it to false for security reaons.
+If privilege mode isn't required, it is suggested to set it to false for security reasons.
 
 Kernel modules will need to be loaded when the container will be started by Docker. To do so, it is
 suggested to configure the composable service which deploys the module in the container this way::

deploy-guide/source/deployment/ansible_config_download.rst

@@ -392,7 +392,7 @@ deploy_steps_playbook.yaml
 __________________________
 ``deploy_steps_playbook.yaml`` is the playbook used for deployment and template
 update. It applies all the software configuration necessary to deploy a full
-overcluod based on the templates provided as input to the deployment command.
+overcloud based on the templates provided as input to the deployment command.
 
 This section will summarize at high level the different ansible plays used
 within this playbook. The play names shown here are the same names used within
@@ -410,7 +410,7 @@ Gather facts from overcloud
 
   tags: facts
 Load global variables
-  Loads all varaibles from `l`global_vars.yaml``
+  Loads all variables from `l`global_vars.yaml``
 
   tags: always
 Common roles for TripleO servers
@@ -441,13 +441,13 @@ External deployment step [1,2,3,4,5]
 Overcloud deploy step tasks for [1,2,3,4,5]
   Applies tasks from the ``deploy_steps_tasks`` template interface
 
-  tags: overcloud, deploy_setps
+  tags: overcloud, deploy_steps
 Overcloud common deploy step tasks [1,2,3,4,5]
   Applies the common tasks done at each step to include puppet host
   configuration, ``container-puppet.py``, and ``paunch`` or
   ``tripleo_container_manage`` Ansible role (container configuration).
 
-  tags: overcloud, deploy_setps
+  tags: overcloud, deploy_steps
 Server Post Deployments
   Applies server specific Heat deployments for configuration done after the 5
   step deployment process.
@@ -722,7 +722,7 @@ previewed is dependent on many factors such as the underlying tools in use
 (puppet, docker, etc) and the support for ansible check mode in the given
 ansible module.
 
-The ``--diff`` option can aloso be used with ``--check`` to show the
+The ``--diff`` option can also be used with ``--check`` to show the
 differences that would result from changes.
 
 See `Ansible Check Mode ("Dry Run")

deploy-guide/source/deployment/container_image_prepare.rst

@@ -301,7 +301,7 @@ include:
 - As part of a development workflow where local changes need to be deployed for
   testing and development
 - When changes need to be deployed but are not available through an image
-  build pipeline (proprietry addons, emergency fixes)
+  build pipeline (proprietary addons, emergency fixes)
 
 The modification is done by invoking an ansible role on each image which needs
 to be modified. The role takes a source image, makes the requested changes,

deploy-guide/source/deployment/instack_undercloud.rst

@@ -32,7 +32,7 @@
 
    .. note::
       The undercloud is intended to work correctly with SELinux enforcing.
-      Installatoins with the permissive/disabled SELinux are not recommended.
+      Installations with the permissive/disabled SELinux are not recommended.
       The ``undercloud_enable_selinux`` config option controls that setting.
 
    .. note::
@@ -152,7 +152,7 @@
        actually deployed is completely changed and what is more, for the first
        time aligns with the overcloud deployment. See the command
        ``openstack tripleo deploy --standalone`` help for details.
-       That interface extention for standalone clouds is experimental for Rocky.
+       That interface extension for standalone clouds is experimental for Rocky.
        It is normally should not be used directly for undercloud installations.
 
 #. Run the command to install the undercloud:

deploy-guide/source/deployment/install_overcloud.rst

@@ -281,7 +281,7 @@ Load the images into the containerized undercloud Glance::
 
 To upload a single image, see :doc:`upload_single_image`.
 
-If working with multiple architectures and/or plaforms with an architecure these
+If working with multiple architectures and/or platforms with an architecture these
 attributes can be specified at upload time as in::
 
     openstack overcloud image upload

deploy-guide/source/deployment/install_undercloud.rst

@@ -43,7 +43,7 @@ Installing the Undercloud
 
    .. note::
       The undercloud is intended to work correctly with SELinux enforcing.
-      Installatoins with the permissive/disabled SELinux are not recommended.
+      Installations with the permissive/disabled SELinux are not recommended.
       The ``undercloud_enable_selinux`` config option controls that setting.
 
    .. note::
@@ -185,7 +185,7 @@ Installing the Undercloud
        actually deployed is completely changed and what is more, for the first
        time aligns with the overcloud deployment. See the command
        ``openstack tripleo deploy --standalone`` help for details.
-       That interface extention for standalone clouds is experimental for Rocky.
+       That interface extension for standalone clouds is experimental for Rocky.
        It is normally should not be used directly for undercloud installations.
 
 #. Run the command to install the undercloud:

deploy-guide/source/deployment/standalone.rst

@@ -5,7 +5,7 @@ Standalone Containers based Deployment
    This currently is only supported in Rocky or newer versions.
 
 This documentation explains how the underlying framework used by the
-Containterized Undercloud deployment mechanism can be reused to deploy a single
+Containerized Undercloud deployment mechanism can be reused to deploy a single
 node capable of running OpenStack services for development.
 
 
@@ -219,7 +219,7 @@ Deploying a Standalone OpenStack node
       :class: ceph
 
       Create an additional environment file which directs ceph-ansible
-      to use the block device with logical volumes and fecth directory
+      to use the block device with logical volumes and fetch directory
       backup created earlier. In the same file pass additional Ceph
       parameters for the OSD scenario and Ceph networks. Set the
       placement group and replica count to values which fit the number

deploy-guide/source/deployment/tips_tricks.rst

@@ -86,7 +86,7 @@ system, which is often the preferred way to operate.
 
 Restarting nova_scheduler for example::
 
-    $ sudo systemctl restart triplo_nova_scheduler
+    $ sudo systemctl restart tripleo_nova_scheduler
 
 Stopping a container with systemd::
 

deploy-guide/source/environments/baremetal.rst

@@ -296,7 +296,7 @@ using the ``enabled_drivers`` option. It is deprecated in the Queens release
 cycle and should no longer be used. See the `hardware types migration guide`_
 for information on how to migrate existing nodes.
 
-Both hardware types and classic drivers can be equially used in the
+Both hardware types and classic drivers can be equally used in the
 ``pm_addr`` field of the ``instackenv.json``.
 
 See https://docs.openstack.org/ironic/latest/admin/drivers.html for the most

deploy-guide/source/features/baremetal_overcloud.rst

@@ -1108,7 +1108,7 @@ switch with ironic/neutron controlling the vlan id for the switch::
       +---------------+        +-----------------+
 
 Switch config for xe-0/0/7 should be removed before deployment, and
-xe-0/0/1 shoud be a member of the vlan range 1200-1299::
+xe-0/0/1 should be a member of the vlan range 1200-1299::
 
   xe-0/0/1 {
       native-vlan-id XXX;

deploy-guide/source/features/ceph_config.rst

@@ -226,8 +226,8 @@ using the following defaults:
 
 * CephClusterName: 'ceph'
 * CephClientUserName: 'openstack'
-* CephClientKey: This value is randomly genereated per Heat stack. If
-  it is overridden the recomendation is to set it to the output of
+* CephClientKey: This value is randomly generated per Heat stack. If
+  it is overridden the recommendation is to set it to the output of
   `ceph-authtool --gen-print-key`.
 
 If the above values are overridden, the keyring file will have a

deploy-guide/source/features/composable_services.rst

@@ -45,7 +45,7 @@ You can then pass the environment file on deployment as follows::
 The same approach can be used for any role.
 
 .. warning::
-  While considerable flexibilty is available regarding service placement with
+  While considerable flexibility is available regarding service placement with
   these interfaces, the flexible placement of pacemaker managed services is only
   available since the Ocata release.
 

deploy-guide/source/features/deploy_cellv2.rst

@@ -2,7 +2,7 @@ Deploy an additional nova cell v2
 =================================
 
 .. warning::
-   Multi cell cupport is only supported in Stein and later versions.
+   Multi cell support is only supported in Stein and later versions.
 
 The different sections in this guide assume that you are ready to deploy a new
 overcloud, or already have installed an overcloud (min Stein release).

deploy-guide/source/features/deploy_cellv2_routed.rst

@@ -524,7 +524,7 @@ like this:
         external_resource_segment_id: 730769f8-e78f-42a3-9dd4-367a212e49ff
 
 Previously we already added the `external_resource_network_id` and `external_resource_subnet_id`
-for the network in the upper level hirarchy.
+for the network in the upper level hierarchy.
 
 In addition we add the `external_resource_vip_id` of the VIP of the stack which
 should be reused for this network (Storage).

deploy-guide/source/features/deploy_manila.rst

@@ -128,7 +128,7 @@ network to the instance.
 .. note::
 
     Cloud-init by default configures only first network interface to use DHCP
-    which means that user intances will not have network interface for storage
+    which means that user instances will not have network interface for storage
     network autoconfigured. You can configure it manually or use
     `dhcp-all-interfaces <https://docs.openstack.org/diskimage-builder/elements/dhcp-all-interfaces/README.html>`_.
 
@@ -170,7 +170,7 @@ Deploying the Overcloud with an External Backend
 
    - Fill in or override the values of parameters for your back end.
 
-   - Since you have copied the file out of its original locaation,
+   - Since you have copied the file out of its original location,
      replace relative paths in the resource_registry with absolute paths
      based on ``/usr/share/openstack-tripleo-heat-templates``.
 

deploy-guide/source/features/deployed_server.rst

@@ -324,7 +324,7 @@ from any CIDR::
       OS::TripleO::Network::Ports::ControlPlaneVipPort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
 
       # Set VIP's for redis and OVN to noop to default to the ctlplane VIP
-      # The cltplane VIP is set with control_virtual_ip in
+      # The ctlplane VIP is set with control_virtual_ip in
       # DeployedServerPortMap below.
       #
       # Alternatively, these can be mapped to deployed-neutron-port.yaml as

deploy-guide/source/features/distributed_compute_node.rst

@@ -16,7 +16,7 @@ management between the control plane stack and the stacks for additional compute
 nodes. The stacks can be managed, scaled, and updated separately.
 
 Using separate stacks also creates smaller failure domains as there are less
-baremetal nodes in each invidiual stack. A failure in one baremetal node only
+baremetal nodes in each individual stack. A failure in one baremetal node only
 requires that management operations to address that failure need only affect
 the single stack that contains the failed node.
 
@@ -339,7 +339,7 @@ Extract the needed data from the control plane stack:
   in the overcloud deployment. Some passwords in the file may be removed if
   they are not needed by DCN. For example, the passwords for RabbitMQ, MySQL,
   Keystone, Nova and Neutron should be sufficient to launch an instance.  When
-  the export comman is run, the Ceph passwords are excluded so that DCN
+  the export common is run, the Ceph passwords are excluded so that DCN
   deployments which include Ceph do not reuse the same Ceph password and
   instead new ones are generated per DCN deployment.
 
@@ -1114,7 +1114,7 @@ were to run the following::
 
   tripleo-ansible-inventory --static-yaml-inventory inventory.yaml --stack central,edge0
 
-then you could use the genereated inventory.yaml as follows::
+then you could use the generated inventory.yaml as follows::
 
   (undercloud) [stack@undercloud ~]$ ansible -i inventory.yaml -m ping central
   central-controller-0 | SUCCESS => {

deploy-guide/source/features/distributed_multibackend_storage.rst

@@ -11,7 +11,7 @@ Features
 
 This Distributed Multibackend Storage design extends the architecture
 described in :doc:`distributed_compute_node` to support the following
-worklow.
+workflow.
 
 - Upload an image to the Central site using `glance image-create`
   command with `--file` and `--store default_backend` parameters.

deploy-guide/source/features/domain_specific_ldap_backends.rst

@@ -281,7 +281,7 @@ following template as a configuration::
   :doc:`ssl` document.
 
 * $SUFFIX will be the domain for your users. Given a domain, the suffix DN can
-  be created withwith the following snippet::
+  be created with the following snippet::
 
       suffix=`echo $DOMAIN | sed -e 's/^/dc=/' -e 's/\./,dc=/g'`
 

deploy-guide/source/features/ipsec.rst

@@ -107,7 +107,7 @@ that looks as follows::
 The ``IpsecVars`` option is able to change any parameter in the tripleo-ipsec
 ansible role.
 
-.. note:: For more information on the algorithms that Libreswan suppports,
+.. note:: For more information on the algorithms that Libreswan supports,
           please check the `Libreswan documentation`_
 
 .. note:: For more information on the available parameters, check the README

deploy-guide/source/features/node_specific_hieradata.rst

@@ -93,8 +93,8 @@ may not always point to the same device on reboot. Thus, `by_path` is
 recommended and is the default if `-k` is not specified.
 
 Ironic will have one of the available disks on the system reserved as
-the root disk. The utility will always exlude the root disk from the
-list of devices genereated.
+the root disk. The utility will always exclude the root disk from the
+list of devices generated.
 
 Use `./make_ceph_disk_list.py --help` to see other available options.
 

deploy-guide/source/features/ops_tools.rst

@@ -108,7 +108,7 @@ Before deploying the Overcloud
 
 3. Configure the environment
 
-   The easiest way to configure our environment will be to create a parameter file, let's called paramters.yaml with all the paramteres defined.
+   The easiest way to configure our environment will be to create a parameter file, let's called parameters.yaml with all the parameters defined.
 
    - Availability Monitoring::
 

deploy-guide/source/features/security_hardening.rst

@@ -113,7 +113,7 @@ Audit
 -----
 
 Having a system capable of recording all audit events is key for troubleshooting
-and peforming analysis of events that led to a certain outcome. The audit system
+and performing analysis of events that led to a certain outcome. The audit system
 is capable of logging many events such as someone changing the system time,
 changes to Mandatory / Discretionary Access Control, creating / destroying users
 or groups.
@@ -251,7 +251,7 @@ example structure::
 
 .. note::
    Operators should select their own required AIDE values, as the example list
-   above is not activley maintained or benchmarked. It only seeks to provide
+   above is not actively maintained or benchmarked. It only seeks to provide
    an document the YAML structure required.
 
 If above environment file were saved as `aide.yaml` it could then be passed to

deploy-guide/source/post_deployment/backup_and_restore/03_undercloud_restore.rst

@@ -88,7 +88,7 @@ node, the user is able to log in as the stack user, and
 have the Backup restored in the folder
 `/var/tmp/test_bk_down`, follow the next steps.
 
-Syncronize the stack home directory, haproxy configuration,
+Synchronize the stack home directory, haproxy configuration,
 certificates and hieradata with the backup content:
 
 ::
@@ -171,7 +171,7 @@ the DB password to be able to reinstall the Undercloud:
   oldpassword=$(sudo cat /var/tmp/test_bk_down/root/.my.cnf | grep -m1 password | cut -d'=' -f2 | tr -d "'")
   mysqladmin -u root -p$oldpassword password ''
 
-Remove old user permisology if it exists, replace <node> with the host related to each user.
+Remove old user permissions if it exists, replace <node> with the host related to each user.
 
 ::
 

deploy-guide/source/post_deployment/backup_and_restore/05_rear.rst

@@ -96,7 +96,7 @@ verify we can restore it from the Hypervisor.
 
 3. Prepare the hypervisor.
 
-We will run in the Hypervison some pre backup steps in
+We will run in the Hypervisor some pre backup steps in
 order to have the correct configuration to mount the
 backup bucket from the Undercloud node::
 

deploy-guide/source/post_deployment/fernet_key_rotation.rst

@@ -4,7 +4,7 @@ Rotation Keystone Fernet Keys from the Overcloud
 ================================================
 
 Like most passwords in your overcloud deployment, keystone fernet keys are also
-stored as part of the deployment plan in mistral. The overcloud deplotment's
+stored as part of the deployment plan in mistral. The overcloud deployment's
 fernet keys can be rotated with the following command::
 
     openstack workflow execution create \

deploy-guide/source/post_deployment/tempest/os_tempest.rst

@@ -76,10 +76,10 @@ What are these above vars:
 * `tempest_public_subnet_cidr`: Based on the standalone deployment IP, we need to pass a required cidr.
 * `tempest_public_subnet_gateway_ip and tempest_public_subnet_allocation_pools`:
    Subnet Gateway IP and allocation pool can be calculated based on the value of `tempest_public_subnet_cidr` nthhost value.
-* `tempest_use_tempestconf`: For generating tempest.conf, we use python-tempestconf tool. By default It is setted to false. Set to `true` for using it
-* `tempest_run_stackviz`: Stackviz is very useful in CI for analizing tempest results, for local use, we set it to false. By default it is setted to true.
+* `tempest_use_tempestconf`: For generating tempest.conf, we use python-tempestconf tool. By default It is set to false. Set it to `true` for using it
+* `tempest_run_stackviz`: Stackviz is very useful in CI for analyzing tempest results, for local use, we set it to false. By default it is set to true.
 * `tempest_tempest_conf_overrides`: In order to pass additional tempest configuration to python-tempestconf tool, we can pass a dictionary of values.
-* `tempest_test_whitelist`: We need to pass a list of tests which we wish to run on the targest host as a list.
+* `tempest_test_whitelist`: We need to pass a list of tests which we wish to run on the target host as a list.
 * `tempest_test_blacklist`: In order to skip tempest tests, we can pass the list here.
 * `gather_facts`: We need to set gather_facts to true as os_tempest rely on targetted environment facts for installing stuff.
 

deploy-guide/source/post_deployment/tempest/tempest.rst

@@ -117,7 +117,7 @@ configuration, the following is the default::
 
 * Running tempest against overcloud::
 
-    $ cd <path to triplo-quickstart repo>
+    $ cd <path to tripleo-quickstart repo>
 
     $ bash quickstart.sh \
       --bootstrap \

deploy-guide/source/post_deployment/updating_network_configuration_post_deployment.rst

@@ -1,4 +1,4 @@
-.. _update_network_configuration_post_deploymenet:
+.. _update_network_configuration_post_deployment:
 
 Updating network configuration on the Overcloud after a deployment
 ==================================================================

deploy-guide/source/post_deployment/upgrade/fast_forward_upgrade.rst

@@ -382,7 +382,7 @@ At a minimum an operator should check the health of the pacemaker cluster
    :class: stable
 
    The ``--limit`` was introduced in the Stein release. In previous versions,
-   use ``--nodes`` or ``--roles`` paremeters.
+   use ``--nodes`` or ``--roles`` parameters.
 
 For control plane nodes, you are expected to upgrade all nodes within a role at
 the same time: pass a role name to ``--limit``. For non-control-plane nodes,

deploy-guide/source/post_deployment/upgrade/major_upgrade.rst

@@ -65,7 +65,7 @@ The upgrade workflow essentially consists of the following steps:
    Finally run a heat stack update, unsetting any upgrade specific variables
    and leaving the heat stack in a healthy state for future updates.
 
-Detailed infromation and pointers can be found in the relevant the
+Detailed information and pointers can be found in the relevant the
 queens-upgrade-dev-docs_.
 
 .. _queens-upgrade-dev-docs: https://docs.openstack.org/tripleo-docs/latest/install/developer/upgrades/major_upgrade.html # WIP @ https://review.opendev.org/#/c/569443/
@@ -266,7 +266,7 @@ don't want to start them all.
    :class: stable
 
    The --limit was introduced in the Stein release. In previous versions, use
-   --nodes or --roles parmeters.
+   --nodes or --roles parameters.
 
 openstack overcloud external-upgrade run (for services)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -612,7 +612,7 @@ major-upgrade-composable-steps that come first, as described above.
    are 'fully' upgraded after each step completes, rather than having to wait
    for the final converge step as has previously been the case. In the case of
    Ocata to Pike the full puppet/docker config is applied to bring up the
-   overclod services in containers.
+   overcloud services in containers.
 
    The tripleo_upgrade_node.sh_ script and puppet configuration are delivered to
    the nodes with ``disable_upgrade_deployment`` set ``True`` during the initial

deploy-guide/source/post_deployment/upgrade/minor_update.rst

@@ -202,7 +202,7 @@ Updating your Overcloud - Pike
 For the Pike cycle the minor update workflow is significantly different to
 previous cycles. In particular, rather than using a static yum_update.sh_
 we now use service specific ansible update_tasks_ (similar to the upgrade_tasks
-used for the major upgrade worklow since Ocata). Furthermore, these are not
+used for the major upgrade workflow since Ocata). Furthermore, these are not
 executed directly via a Heat stack update, but rather, together with the
 docker/puppet config, collected and written to ansible playbooks. The operator
 then invokes these to deliver the minor update to particular nodes.
@@ -233,7 +233,7 @@ parameter::
    :class: stable
 
    The `--limit` was introduced in the Stein release. In previous versions,
-   use `--nodes` or `--roles` parmeters.
+   use `--nodes` or `--roles` parameters.
 
 You can specify a role name, e.g. 'Compute', to execute the minor update on
 all nodes of that role in a rolling fashion (serial:1 is used on the playbooks).

deploy-guide/source/post_deployment/validations/cli.rst

@@ -53,7 +53,7 @@ run of a group or specific validations.
 
 ``--extra-vars-file``: This
 option allows to add a valid ``JSON`` or ``YAML``
-file containg extra variables to a run of a group or specific validations.
+file contaning extra variables to a run of a group or specific validations.
 
 .. code-block:: bash
 

deploy-guide/source/post_deployment/validations/index.rst

@@ -16,7 +16,7 @@ The validations are assigned into various groups that indicate when in
 the deployment workflow they are expected to run:
 
 * **no-op** validations will run a no-op operation to verify that
-  the workflow is working as it supossed to, it will run in both
+  the workflow is working as it supposed to, it will run in both
   the Undercloud and Overcloud nodes.
 
 * **openshift-on-openstack** validations will check that the

deploy-guide/source/troubleshooting/troubleshooting-log-and-status-capture.rst

@@ -13,9 +13,9 @@ logs to the host that the command is executed from.
 Example: Download logs from all controllers
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The required `server_name` option for the command can be a paritial name
+The required `server_name` option for the command can be a partial name
 match for the overcloud nodes. This means `openstack overcloud support report
-colect controller` will match all the overcloud nodes that contain the word
+collect controller` will match all the overcloud nodes that contain the word
 `controller`.  To download the run the command and download them to a local
 directory, run the following command::
 

deploy-guide/source/troubleshooting/troubleshooting-nodes.rst

@@ -98,7 +98,7 @@ power management, and it gets stuck in an abnormal state.
 .. warning::
     Before proceeding with this section, always try to decommission a node
     normally, by scaling down your cloud. Forcing node deletion may cause
-    unpredicable results.
+    unpredictable results.
 
 Ironic requires that nodes that cannot be operated normally are put in the
 maintenance mode. It is done by the following command::

doc/source/ci/baremetal_jobs.rst

@@ -14,7 +14,7 @@ can be included in the TripleO promotion criteria.
 
 The goal is to give developers feedback on real deployments and allow us to
 have better coverage on issues seen in production environments. It also
-allows an aproximation of OVB jobs running in RDO cloud in order to get an
+allows an approximation of OVB jobs running in RDO cloud in order to get an
 "apples-to-apples" comparison to eliminate infra issues.
 
 .. _baremetal_deploy_guide: https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/provisioning/index.html
@@ -114,7 +114,7 @@ Now adding the dlrn reporting ::
       secrets:
          - dlrnapi
 
-Example of a specfic hardware job in Zuul:
+Example of a specific hardware job in Zuul:
 
 Note that multiple jobs cannot be run on the hardware concurrently.
 The base job is modified to include semaphore

doc/source/ci/dlrn-promoter-overview.rst

@@ -121,7 +121,7 @@ https://github.com/rdo-infra/ci-config/blob/master/ci-scripts/dlrnapi_promoter/R
 Pushing RDO containers to ``docker.io``
 ```````````````````````````````````````
 
-The DLRN Promotor script calls the `container push playbook
+The DLRN Promoter script calls the `container push playbook
 <https://github.com/rdo-infra/ci-config/blob/master/ci-scripts/container-push/container-push.yml>`_
 to push the RDO containers at each stage to `docker.io
 <https://hub.docker.com/r/tripleopike/centos-binary-heat-api/tags/>`_.

doc/source/ci/third_party_dependencies_ci.rst

@@ -97,12 +97,12 @@ Click on the job link and it will open the build result page. Then click on
 `log_url`, click on the `job-output.txt`. It contains the results of
 ansible playbook runs.
 Look for *ERROR* or failed messages.
-If looks something ovious.
+If looks something obvious.
 Please go ahead and create the bug on launchpad_ against tripleo project with
 all the information.
 
 Once the bug is created, please add `depcheck` tag on the filed launchpad bug.
-This tag is explicitly used for listing bugs related to TripleO CI job failue
+This tag is explicitly used for listing bugs related to TripleO CI job failure
 against ceph-ansible and podman projects.
 
 .. _launchpad: https://bugs.launchpad.net/tripleo/+filebug

doc/source/developer/tht_walkthrough/changes-puppet-tripleo.rst

@@ -41,7 +41,7 @@ structure (``manifests/profile/base/time/ntp.pp``) as:
     $step          = hiera('step'),
   ) {
     #step assigned for core modules.
-    #(Check for further referencies about the configuration steps)
+    #(Check for further references about the configuration steps)
     #https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/puppet/services/README.rst
     if ($step >= 2){
       #We will call the NTP puppet class and assign our configuration values.

doc/source/upgrade/developer/upgrades/major_upgrade_with_os.plantuml

@@ -72,7 +72,7 @@ group Transfer the data to the freshly re-installed controller\n(only required i
 note over "undercloud", "controller-2" #AAFFAA
     Everything is composable, but diagram showcases MariaDB specifically
 end note
-User -> "undercloud" : openstack overcloud external-upgarde run
+User -> "undercloud" : openstack overcloud external-upgrade run
 "undercloud" -> "controller-1" : pcs resource disable\ngalera-bundle
 note right: Disable MariaDB
 "controller-1" -> "controller-2"