diff --git a/deploy-guide/source/deployment/3rd_party.rst b/deploy-guide/source/deployment/3rd_party.rst index 2740e38c..9c8f4611 100644 --- a/deploy-guide/source/deployment/3rd_party.rst +++ b/deploy-guide/source/deployment/3rd_party.rst @@ -153,8 +153,8 @@ Here are some of them: the default path for 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:: diff --git a/deploy-guide/source/deployment/ansible_config_download.rst b/deploy-guide/source/deployment/ansible_config_download.rst index b88d699c..b597a87a 100644 --- a/deploy-guide/source/deployment/ansible_config_download.rst +++ b/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") diff --git a/deploy-guide/source/deployment/container_image_prepare.rst b/deploy-guide/source/deployment/container_image_prepare.rst index 66277e56..36437fe7 100644 --- a/deploy-guide/source/deployment/container_image_prepare.rst +++ b/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, diff --git a/deploy-guide/source/deployment/instack_undercloud.rst b/deploy-guide/source/deployment/instack_undercloud.rst index 672e5701..aa8aaace 100644 --- a/deploy-guide/source/deployment/instack_undercloud.rst +++ b/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: diff --git a/deploy-guide/source/deployment/install_overcloud.rst b/deploy-guide/source/deployment/install_overcloud.rst index 3f3125ba..8dc9394f 100644 --- a/deploy-guide/source/deployment/install_overcloud.rst +++ b/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 diff --git a/deploy-guide/source/deployment/install_undercloud.rst b/deploy-guide/source/deployment/install_undercloud.rst index a2bafb7f..aea5b7ff 100644 --- a/deploy-guide/source/deployment/install_undercloud.rst +++ b/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: diff --git a/deploy-guide/source/deployment/standalone.rst b/deploy-guide/source/deployment/standalone.rst index 23b15906..4df467bf 100644 --- a/deploy-guide/source/deployment/standalone.rst +++ b/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 diff --git a/deploy-guide/source/deployment/tips_tricks.rst b/deploy-guide/source/deployment/tips_tricks.rst index 3b0ecc11..5ce02033 100644 --- a/deploy-guide/source/deployment/tips_tricks.rst +++ b/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:: diff --git a/deploy-guide/source/environments/baremetal.rst b/deploy-guide/source/environments/baremetal.rst index d8e64e51..c821307b 100644 --- a/deploy-guide/source/environments/baremetal.rst +++ b/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 diff --git a/deploy-guide/source/features/baremetal_overcloud.rst b/deploy-guide/source/features/baremetal_overcloud.rst index 17765e7d..f39c0c9d 100644 --- a/deploy-guide/source/features/baremetal_overcloud.rst +++ b/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; diff --git a/deploy-guide/source/features/ceph_config.rst b/deploy-guide/source/features/ceph_config.rst index e07fae7e..1750d699 100644 --- a/deploy-guide/source/features/ceph_config.rst +++ b/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 diff --git a/deploy-guide/source/features/composable_services.rst b/deploy-guide/source/features/composable_services.rst index 0695709c..13296376 100644 --- a/deploy-guide/source/features/composable_services.rst +++ b/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. diff --git a/deploy-guide/source/features/deploy_cellv2.rst b/deploy-guide/source/features/deploy_cellv2.rst index 2bc6b0f7..ef238d1f 100644 --- a/deploy-guide/source/features/deploy_cellv2.rst +++ b/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). diff --git a/deploy-guide/source/features/deploy_cellv2_routed.rst b/deploy-guide/source/features/deploy_cellv2_routed.rst index 41f87f65..7507343b 100644 --- a/deploy-guide/source/features/deploy_cellv2_routed.rst +++ b/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). diff --git a/deploy-guide/source/features/deploy_manila.rst b/deploy-guide/source/features/deploy_manila.rst index 181b46ec..93201431 100644 --- a/deploy-guide/source/features/deploy_manila.rst +++ b/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 `_. @@ -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``. diff --git a/deploy-guide/source/features/deployed_server.rst b/deploy-guide/source/features/deployed_server.rst index a0f60538..5e585fad 100644 --- a/deploy-guide/source/features/deployed_server.rst +++ b/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 diff --git a/deploy-guide/source/features/distributed_compute_node.rst b/deploy-guide/source/features/distributed_compute_node.rst index 61cb88b7..a036f027 100644 --- a/deploy-guide/source/features/distributed_compute_node.rst +++ b/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 => { diff --git a/deploy-guide/source/features/distributed_multibackend_storage.rst b/deploy-guide/source/features/distributed_multibackend_storage.rst index 26438ac8..1288c6fe 100644 --- a/deploy-guide/source/features/distributed_multibackend_storage.rst +++ b/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. diff --git a/deploy-guide/source/features/domain_specific_ldap_backends.rst b/deploy-guide/source/features/domain_specific_ldap_backends.rst index 453a3a0d..bd068f59 100644 --- a/deploy-guide/source/features/domain_specific_ldap_backends.rst +++ b/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'` diff --git a/deploy-guide/source/features/ipsec.rst b/deploy-guide/source/features/ipsec.rst index 9e37e06a..067dc501 100644 --- a/deploy-guide/source/features/ipsec.rst +++ b/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 diff --git a/deploy-guide/source/features/node_specific_hieradata.rst b/deploy-guide/source/features/node_specific_hieradata.rst index 36457a9c..99bc973b 100644 --- a/deploy-guide/source/features/node_specific_hieradata.rst +++ b/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. diff --git a/deploy-guide/source/features/ops_tools.rst b/deploy-guide/source/features/ops_tools.rst index ea1a773e..70d63cb0 100644 --- a/deploy-guide/source/features/ops_tools.rst +++ b/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:: diff --git a/deploy-guide/source/features/security_hardening.rst b/deploy-guide/source/features/security_hardening.rst index 3dd94faa..930e0475 100644 --- a/deploy-guide/source/features/security_hardening.rst +++ b/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 diff --git a/deploy-guide/source/post_deployment/backup_and_restore/03_undercloud_restore.rst b/deploy-guide/source/post_deployment/backup_and_restore/03_undercloud_restore.rst index 15e35195..42b1c795 100644 --- a/deploy-guide/source/post_deployment/backup_and_restore/03_undercloud_restore.rst +++ b/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 with the host related to each user. +Remove old user permissions if it exists, replace with the host related to each user. :: diff --git a/deploy-guide/source/post_deployment/backup_and_restore/05_rear.rst b/deploy-guide/source/post_deployment/backup_and_restore/05_rear.rst index da14a816..68db73b4 100644 --- a/deploy-guide/source/post_deployment/backup_and_restore/05_rear.rst +++ b/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:: diff --git a/deploy-guide/source/post_deployment/fernet_key_rotation.rst b/deploy-guide/source/post_deployment/fernet_key_rotation.rst index fda7b686..90983466 100644 --- a/deploy-guide/source/post_deployment/fernet_key_rotation.rst +++ b/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 \ diff --git a/deploy-guide/source/post_deployment/tempest/os_tempest.rst b/deploy-guide/source/post_deployment/tempest/os_tempest.rst index 67980bcf..3f758459 100644 --- a/deploy-guide/source/post_deployment/tempest/os_tempest.rst +++ b/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. diff --git a/deploy-guide/source/post_deployment/tempest/tempest.rst b/deploy-guide/source/post_deployment/tempest/tempest.rst index 4a44767b..57dd5bf2 100644 --- a/deploy-guide/source/post_deployment/tempest/tempest.rst +++ b/deploy-guide/source/post_deployment/tempest/tempest.rst @@ -117,7 +117,7 @@ configuration, the following is the default:: * Running tempest against overcloud:: - $ cd + $ cd $ bash quickstart.sh \ --bootstrap \ diff --git a/deploy-guide/source/post_deployment/updating_network_configuration_post_deployment.rst b/deploy-guide/source/post_deployment/updating_network_configuration_post_deployment.rst index 9c35071a..a7315abd 100644 --- a/deploy-guide/source/post_deployment/updating_network_configuration_post_deployment.rst +++ b/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 ================================================================== diff --git a/deploy-guide/source/post_deployment/upgrade/fast_forward_upgrade.rst b/deploy-guide/source/post_deployment/upgrade/fast_forward_upgrade.rst index 36b849b0..beb06534 100644 --- a/deploy-guide/source/post_deployment/upgrade/fast_forward_upgrade.rst +++ b/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, diff --git a/deploy-guide/source/post_deployment/upgrade/major_upgrade.rst b/deploy-guide/source/post_deployment/upgrade/major_upgrade.rst index e75aa017..45aab7fd 100644 --- a/deploy-guide/source/post_deployment/upgrade/major_upgrade.rst +++ b/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 diff --git a/deploy-guide/source/post_deployment/upgrade/minor_update.rst b/deploy-guide/source/post_deployment/upgrade/minor_update.rst index 0ea2ce05..672591a5 100644 --- a/deploy-guide/source/post_deployment/upgrade/minor_update.rst +++ b/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). diff --git a/deploy-guide/source/post_deployment/validations/cli.rst b/deploy-guide/source/post_deployment/validations/cli.rst index 8aa614c2..b07b218a 100644 --- a/deploy-guide/source/post_deployment/validations/cli.rst +++ b/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 diff --git a/deploy-guide/source/post_deployment/validations/index.rst b/deploy-guide/source/post_deployment/validations/index.rst index 4409f578..dca0162f 100644 --- a/deploy-guide/source/post_deployment/validations/index.rst +++ b/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 diff --git a/deploy-guide/source/troubleshooting/troubleshooting-log-and-status-capture.rst b/deploy-guide/source/troubleshooting/troubleshooting-log-and-status-capture.rst index 8218e37a..3559e947 100644 --- a/deploy-guide/source/troubleshooting/troubleshooting-log-and-status-capture.rst +++ b/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:: diff --git a/deploy-guide/source/troubleshooting/troubleshooting-nodes.rst b/deploy-guide/source/troubleshooting/troubleshooting-nodes.rst index 50f1abe5..4aabb687 100644 --- a/deploy-guide/source/troubleshooting/troubleshooting-nodes.rst +++ b/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:: diff --git a/doc/source/ci/baremetal_jobs.rst b/doc/source/ci/baremetal_jobs.rst index aa7894f7..396af4d2 100644 --- a/doc/source/ci/baremetal_jobs.rst +++ b/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 diff --git a/doc/source/ci/dlrn-promoter-overview.rst b/doc/source/ci/dlrn-promoter-overview.rst index 6fc3f3c9..b345acf1 100644 --- a/doc/source/ci/dlrn-promoter-overview.rst +++ b/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 `_ to push the RDO containers at each stage to `docker.io `_. diff --git a/doc/source/ci/third_party_dependencies_ci.rst b/doc/source/ci/third_party_dependencies_ci.rst index 63e24ba6..eb4d3940 100644 --- a/doc/source/ci/third_party_dependencies_ci.rst +++ b/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 diff --git a/doc/source/developer/tht_walkthrough/changes-puppet-tripleo.rst b/doc/source/developer/tht_walkthrough/changes-puppet-tripleo.rst index 3dfe3499..7feb09b5 100644 --- a/doc/source/developer/tht_walkthrough/changes-puppet-tripleo.rst +++ b/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. diff --git a/doc/source/upgrade/developer/upgrades/major_upgrade_with_os.plantuml b/doc/source/upgrade/developer/upgrades/major_upgrade_with_os.plantuml index 7bfd65df..3d88e3ff 100644 --- a/doc/source/upgrade/developer/upgrades/major_upgrade_with_os.plantuml +++ b/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"