Merge "Remove repeated words"

deploy-guide/source/deployment/network_v2.rst

@@ -6,7 +6,7 @@ Networking Version 2 (Two)
 Introduction
 ------------
 
-In the the Wallaby cycle TripleO Networking has been refactored so that no
+In the Wallaby cycle TripleO Networking has been refactored so that no
 OS::Neutron heat resources are used. This was a pre-requisite for
 :doc:`./ephemeral_heat`. Managing non-ephemeral neutron resources with an
 ephemeral heat stack is not feasible, so the management of neutron resources

deploy-guide/source/features/baremetal_overcloud.rst

@@ -206,7 +206,7 @@ Additional configuration
 Using a Custom Network for Overcloud Provisioning
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The Pike release provided the the ability to define a custom network,
+The Pike release provided the ability to define a custom network,
 this has been further enhanced in Queens to allow for the definition
 of a VLAN in the network definition.  Using a custom network to provision
 Overcloud nodes for Ironic has the advantage of moving all Ironic services

deploy-guide/source/features/deploy_cellv2_advanced.rst

@@ -94,7 +94,7 @@ a new flavor and tag the cell controller.
 
 Run cell deployment
 ___________________
-To deploy the cell controller stack we use use the same `overcloud deploy`
+To deploy the cell controller stack we use the same `overcloud deploy`
 command as it was used to deploy the `overcloud` stack and add the created
 export environment files:
 
@@ -193,7 +193,7 @@ Deploy the cell computes
 
 Run cell deployment
 ___________________
-To deploy the overcloud we can use use the same `overcloud deploy` command as
+To deploy the overcloud we can use the same `overcloud deploy` command as
 it was used to deploy the `cell1-ctrl` stack and add the created export
 environment files:
 

deploy-guide/source/features/deploy_cellv2_basic.rst

@@ -236,7 +236,7 @@ Verify the tagged cellcontroller:
 
 Run cell deployment
 ___________________
-To deploy the overcloud we can use use the same `overcloud deploy` command as
+To deploy the overcloud we can use the same `overcloud deploy` command as
 it was used to deploy the `overcloud` stack and add the created export
 environment files:
 

deploy-guide/source/features/deploy_cellv2_manage_cell.rst

@@ -34,7 +34,7 @@ the cell host discovery:
 
 .. note::
 
-  Optionally the cell uuid cal be specified to the `discover_hosts` and
+  Optionally the cell uuid can be specified to the `discover_hosts` and
   `list_hosts` command to only target against a specific cell.
 
 Delete a compute from a cell

deploy-guide/source/features/deploy_cellv2_routed.rst

@@ -438,7 +438,7 @@ a new flavor and tag the cell controller.
 
 Run cell deployment
 ___________________
-To deploy the overcloud we can use use the same `overcloud deploy` command as
+To deploy the overcloud we can use the same `overcloud deploy` command as
 it was used to deploy the `overcloud` stack and add the created export
 environment files:
 
@@ -538,7 +538,7 @@ In addition we add the `external_resource_vip_id` of the VIP of the stack which
 should be reused for this network (Storage).
 
 Important is that the `external_resource_vip_id` for the InternalApi points
-the the VIP of the cell controller stack!
+the VIP of the cell controller stack!
 
 .. code-block:: bash
 
@@ -665,7 +665,7 @@ Deploy the cell computes
 
 Run cell deployment
 ___________________
-To deploy the overcloud we can use use the same `overcloud deploy` command as
+To deploy the overcloud we can use the same `overcloud deploy` command as
 it was used to deploy the `cell1-ctrl` stack and add the created export
 environment files:
 

deploy-guide/source/features/distributed_multibackend_storage.rst

@@ -677,7 +677,7 @@ The output of the above command,
 used when deploying the overcloud in the next section.
 
 The ``--config ~/dcn0/initial-ceph.conf`` is optional and
-may be be used for initial Ceph configuration. If the Ceph cluster
+may be used for initial Ceph configuration. If the Ceph cluster
 will be hyper-converged with compute services then create this file
 like the following so Ceph will not consume memory that Nova compute
 instances will need::

deploy-guide/source/features/network_isolation.rst

@@ -180,7 +180,7 @@ Create the networks, segments and subnet resources on the Undercloud
 
 Run the "openstack overcloud network provision" command to create/update the
 networks on the Undercloud. This command will also generate the
-``networks-deployed-environment.yaml`` environment file which must be be used
+``networks-deployed-environment.yaml`` environment file which must be used
 when deploying the overcloud.
 
 .. code-block:: bash
@@ -237,7 +237,7 @@ Create the overcloud network Virtual IPs on the Undercloud
 
 Run the "openstack overcloud network vip provision" command to create/update
 the network Virtual IPs on the Undercloud. This command will also generate the
-``vips-deployed-environment.yaml`` environment file which must be be used when
+``vips-deployed-environment.yaml`` environment file which must be used when
 deploying the overcloud.
 
 .. code-block:: bash

deploy-guide/source/features/security_hardening.rst

@@ -198,7 +198,7 @@ definition. In our case in `deployment/rabbitmq/rabbitmq-container-puppet.yaml`.
           - 25672
           - 25673-25683
 
-Additional information regarding the the available interface options, the role,
+Additional information regarding the available interface options, the role,
 some of the implementation details can be reviewed `here <https://docs.openstack.org/tripleo-ansible/latest/roles/role-tripleo_firewall.html>`_.
 
 VXLAN and nftables

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

@@ -566,7 +566,7 @@ To find out which resources are needed, see
 
 All the steps below use **stack user** as an example. You may be ssh-ed as a
 different user but in that case you **have to** change all of the paths below
-accordingly (instead of stack user user your $USER)
+accordingly (instead of stack user, use your $USER)
 
 Prepare the tempest container
 +++++++++++++++++++++++++++++

deploy-guide/source/provisioning/baremetal_provision.rst

@@ -380,7 +380,7 @@ The ``instances`` ``config_drive`` property supports two sub-properties:
 
 * ``cloud_config``: Dict of cloud-init `cloud-config`_ data for tasks to run on
   node boot. A task specified in an ``instances`` ``cloud_config`` will
-  overwrite a task with the same name in in ``defaults`` ``cloud_config``.
+  overwrite a task with the same name in ``defaults`` ``cloud_config``.
 
 * ``meta_data``: Extra metadata to include with the config-drive cloud-init
   metadata. This will be added to the generated metadata ``public_keys``,

doc/source/developer/tht_walkthrough/design-patterns.rst

@@ -79,7 +79,7 @@ pacemaker.
 In this case mongodb.yaml is using all the common parameter added in the
 MongoDbBase resource.
 
-If using the parameter 'EndpointMap' in the base template, you must the pass it from from the service file,
+If using the parameter 'EndpointMap' in the base template, you must the pass it from the service file,
 and even if it is not used in the service template, it must still be defined.
 
 In the service file:

doc/source/developer/tht_walkthrough/tls_for_services.rst

@@ -535,7 +535,7 @@ modify the ``config_settings`` to add what we need::
 
 * The ``metadata_settings`` section will pass some information to a metadata
   hook that will create the service principal before the certificate request is
-  done. The format as as follows:
+  done. The format as follows:
 
   * ``service``: This contains the service identifier to be used in the
     kerberos service principal. It should match the identifier you put in the

doc/source/upgrade/developer/upgrades/major_upgrade.rst

@@ -41,7 +41,7 @@ you read the following sections:
 openstack overcloud upgrade prepare $ARGS
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The entry point for the the upgrade CLI commands, *prepare*, *run* and
+The entry point for the upgrade CLI commands, *prepare*, *run* and
 *converge*, is given in the python-tripleoclient setup.cfg_. All three
 are also defined in the same file, overcloud-upgrade.py_.
 

doc/source/upgrade/developer/upgrades/minor_update.rst

@@ -65,7 +65,7 @@ The play first executes `update_steps_tasks.yaml` which are tasks
 collected from the ``update_tasks`` entry in composable
 services.
 
-After the update tasks are finished, deployment workflow is is
+After the update tasks are finished, deployment workflow is
 performed on the node being updated. That means reusing
 `host_prep_tasks.yaml` and `common_deploy_steps_tasks.yaml`, which are
 executed like on a fresh deployment, except during minor update