diff --git a/deploy-guide/source/deployment/network_v2.rst b/deploy-guide/source/deployment/network_v2.rst index 0d47e9db..ac03387b 100644 --- a/deploy-guide/source/deployment/network_v2.rst +++ b/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 diff --git a/deploy-guide/source/features/baremetal_overcloud.rst b/deploy-guide/source/features/baremetal_overcloud.rst index e03ade4b..b05bd3ff 100644 --- a/deploy-guide/source/features/baremetal_overcloud.rst +++ b/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 diff --git a/deploy-guide/source/features/deploy_cellv2_advanced.rst b/deploy-guide/source/features/deploy_cellv2_advanced.rst index 0060369a..d158d7f9 100644 --- a/deploy-guide/source/features/deploy_cellv2_advanced.rst +++ b/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: diff --git a/deploy-guide/source/features/deploy_cellv2_basic.rst b/deploy-guide/source/features/deploy_cellv2_basic.rst index a8d61ae2..94bc1017 100644 --- a/deploy-guide/source/features/deploy_cellv2_basic.rst +++ b/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: diff --git a/deploy-guide/source/features/deploy_cellv2_manage_cell.rst b/deploy-guide/source/features/deploy_cellv2_manage_cell.rst index 703e8430..0033558e 100644 --- a/deploy-guide/source/features/deploy_cellv2_manage_cell.rst +++ b/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 diff --git a/deploy-guide/source/features/deploy_cellv2_routed.rst b/deploy-guide/source/features/deploy_cellv2_routed.rst index aa9dca9c..bf31df2d 100644 --- a/deploy-guide/source/features/deploy_cellv2_routed.rst +++ b/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: diff --git a/deploy-guide/source/features/distributed_multibackend_storage.rst b/deploy-guide/source/features/distributed_multibackend_storage.rst index ac76498b..0334a80d 100644 --- a/deploy-guide/source/features/distributed_multibackend_storage.rst +++ b/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:: diff --git a/deploy-guide/source/features/network_isolation.rst b/deploy-guide/source/features/network_isolation.rst index 6d057f1f..9a6c5a40 100644 --- a/deploy-guide/source/features/network_isolation.rst +++ b/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 diff --git a/deploy-guide/source/features/security_hardening.rst b/deploy-guide/source/features/security_hardening.rst index a85cb3ef..956210ea 100644 --- a/deploy-guide/source/features/security_hardening.rst +++ b/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 `_. VXLAN and nftables diff --git a/deploy-guide/source/post_deployment/tempest/tempest.rst b/deploy-guide/source/post_deployment/tempest/tempest.rst index b36b717b..32b76863 100644 --- a/deploy-guide/source/post_deployment/tempest/tempest.rst +++ b/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 +++++++++++++++++++++++++++++ diff --git a/deploy-guide/source/provisioning/baremetal_provision.rst b/deploy-guide/source/provisioning/baremetal_provision.rst index 3e97865c..b8393180 100644 --- a/deploy-guide/source/provisioning/baremetal_provision.rst +++ b/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``, diff --git a/doc/source/developer/tht_walkthrough/design-patterns.rst b/doc/source/developer/tht_walkthrough/design-patterns.rst index c2e0b514..f4fe738e 100644 --- a/doc/source/developer/tht_walkthrough/design-patterns.rst +++ b/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: diff --git a/doc/source/developer/tht_walkthrough/tls_for_services.rst b/doc/source/developer/tht_walkthrough/tls_for_services.rst index 0582dc1b..3cbefd7b 100644 --- a/doc/source/developer/tht_walkthrough/tls_for_services.rst +++ b/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 diff --git a/doc/source/upgrade/developer/upgrades/major_upgrade.rst b/doc/source/upgrade/developer/upgrades/major_upgrade.rst index d1cf041f..c2fd8724 100644 --- a/doc/source/upgrade/developer/upgrades/major_upgrade.rst +++ b/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_. diff --git a/doc/source/upgrade/developer/upgrades/minor_update.rst b/doc/source/upgrade/developer/upgrades/minor_update.rst index 0eb07ac0..c4512ff9 100644 --- a/doc/source/upgrade/developer/upgrades/minor_update.rst +++ b/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