Fix typos in doc pages

Change-Id: Ia68d3469318dd423ceb0843c39d3ac2734a5f264
changes/16/858516/2
Rajesh Tailor 8 months ago
parent e92287808d
commit 6901c3aa8a

@ -27,7 +27,7 @@
color: rgba(0, 0, 0, 0.9) !important;
}
/* NOTES, ADMONITTIONS AND TAGS */
/* NOTES, ADMONITIONS AND TAGS */
.admonition {
font-size: 85%; /* match code size */
background: rgb(240, 240, 240);

@ -216,7 +216,7 @@ Here are some of them:
Tips and Tricks with tripleo_container_image_build
..................................................
Here's a non-exaustive list of tips and tricks that might make things faster,
Here's a non-exhaustive list of tips and tricks that might make things faster,
especially on a dev env where you need to build multiple times the containers.
Inject a caching proxy

@ -145,7 +145,7 @@ with ``--override-ansible-cfg`` on the deployment command.
For example the following command will use the configuration options from
``/home/stack/ansible.cfg``. Any options specified in the override file will
take precendence over the defaults::
take precedence over the defaults::
openstack overcloud deploy \
...

@ -87,7 +87,7 @@ that it can run all the steps:
The environment files with the parameters and resource registry overrides
required is automatically included when the ``overcloud deploy`` command is
run with the arguments: ``--vip-file``, ``--baremetal-deployement`` and
run with the arguments: ``--vip-file``, ``--baremetal-deployment`` and
``--network-config``.
#. Run Config-Download and the deploy-steps playbook
@ -369,7 +369,7 @@ Migrating existing deployments
To facilitate the migration for deployed overclouds tripleoclient commands to
extract information from deployed overcloud stacks has been added. During the
upgrade to Wallaby these tools will be executed as part of the underlcoud
upgrade to Wallaby these tools will be executed as part of the undercloud
upgrade, placing the generated YAML definition files in the working directory
(Defaults to: ``~/overcloud-deploy/$STACK_NAME/``). Below each export command
is described, and examples to use them manually with the intent for developers
@ -379,7 +379,7 @@ during the undercloud upgrade.
There is also a tool ``convert_heat_nic_config_to_ansible_j2.py`` that can be
used to convert heat template NIC config to Ansible j2 templates.
.. warning:: If migrating to use Networking v2 while using the non-Epemeral
.. warning:: If migrating to use Networking v2 while using the non-Ephemeral
heat i.e ``--heat-type installed``, the existing overcloud stack
must **first** be updated to set the ``deletion_policy`` for
``OS::Nova`` and ``OS::Neutron`` resources. This can be done
@ -474,7 +474,7 @@ generate a Baremetal Provision definition YAML file from a deployed overcloud
stack. The YAML definition file can then be used with ``openstack overcloud
node provision`` command and/or the ``openstack overcloud deploy`` command.
**Example**: Export deployed overcloud nodes to Baremtal Deployment YAML
**Example**: Export deployed overcloud nodes to Baremetal Deployment YAML
definition
.. code-block:: bash

@ -2,7 +2,7 @@ Containers based Overcloud Deployment
======================================
This documentation explains how to deploy a fully containerized overcloud
utilizing Podman which is the default since the Stein releasee.
utilizing Podman which is the default since the Stein release.
The requirements for a containerized overcloud are the same as for any other
overcloud deployment. The real difference is in where the overcloud services

@ -127,7 +127,7 @@ Deploying a Standalone OpenStack node
be bound to by haproxy while the other by backend services on the same.
.. Note: The following example utilizes 2 interfaces. NIC1 which will serve as
the management inteface. It can have any address and will be left untouched.
the management interface. It can have any address and will be left untouched.
NIC2 will serve as the OpenStack & Provider network NIC. The following
exports should be configured for your network and interface.
@ -179,7 +179,7 @@ Deploying a Standalone OpenStack node
floating IP.
.. Note: NIC1 will serve as the management, OpenStack and Provider network
inteface. The exports should be configured for your network and interface.
interface. The exports should be configured for your network and interface.
.. code-block:: bash

@ -53,7 +53,7 @@ Preparing the Baremetal Environment
Networking
^^^^^^^^^^
The overcloud nodes will be deployed from the undercloud machine and therefore the machines need to have their network settings modified to allow for the overcloud nodes to be PXE boot'ed using the undercloud machine. As such, the setup requires that:
The overcloud nodes will be deployed from the undercloud machine and therefore the machines need to have their network settings modified to allow for the overcloud nodes to be PXE booted using the undercloud machine. As such, the setup requires that:
* All overcloud machines in the setup must support IPMI
* A management provisioning network is setup for all of the overcloud machines.

@ -217,7 +217,7 @@ overcloud to connect to an external ceph cluster:
Deploying Manila with an External CephFS Service
------------------------------------------------
If chosing to configure Manila with Ganesha as NFS gateway for CephFS,
If choosing to configure Manila with Ganesha as NFS gateway for CephFS,
with an external Ceph cluster, then add `environments/manila-cephfsganesha-config.yaml`
to the list of environment files used to deploy the overcloud and also
configure the following parameters::

@ -72,12 +72,12 @@ Examples
NovaPMEMNamespaces: "6G:ns1,6G:ns1,6G:ns2,100G:ns3"
The following example will peform following steps:
The following example will perform following steps:
* ensure **ndctl** tool is installed on hosts with role **ComputePMEM**
* create PMEM namespaces as specified in the **NovaPMEMNamespaces** parameter.
- ns0, ns1, ns2 with size 6GiB
- ns3 with size 100GiB
* set Nova prameter **pmem_namespaces** in nova.conf to map create namespaces to vPMEM as specified in **NovaPMEMMappings**.
* set Nova parameter **pmem_namespaces** in nova.conf to map create namespaces to vPMEM as specified in **NovaPMEMMappings**.
In this example the label '6GB' will map to one of ns0, ns1 or ns2 namespace and the label 'LARGE' will map to ns3 namespace.
After deployment you need to configure flavors as described in documentation `Nova: Configure a flavor <https://docs.openstack.org/nova/latest/admin/virtual-persistent-memory.html#configure-a-flavor>`_

@ -384,7 +384,7 @@ Network data YAML options
See `Options for network data YAML subnet definitions`_ for a list of all
documented sub-options for the subnet definitions.
type: *dictonary*
type: *dictionary*
Options for network data YAML subnet definitions
@ -419,7 +419,7 @@ Options for network data YAML subnet definitions
type: *list*
elements: *dictonary*
elements: *dictionary*
:suboptions:
@ -447,7 +447,7 @@ Options for network data YAML subnet definitions
type: *list*
elements: *dictonary*
elements: *dictionary*
:suboptions:
@ -475,7 +475,7 @@ Options for network data YAML subnet definitions
type: *list*
elements: *dictonary*
elements: *dictionary*
:suboptions:
@ -504,7 +504,7 @@ Options for network data YAML subnet definitions
type: *list*
elements: *dictonary*
elements: *dictionary*
:suboptions:

@ -23,7 +23,7 @@ These roles can be listed using the `tripleoclient` by running::
With these provided roles, the user deploying the overcloud can generate a
`roles_data.yaml` file that contains the roles they would like to use for the
overcloud nodes. Additionally the user can manage their personal custom roles
in a similar manor by storing the individual files in a directory and using
in a similar manner by storing the individual files in a directory and using
the `tripleoclient` to generate their `roles_data.yaml`. For example, a user
can execute the following to create a `roles_data.yaml` containing only the
`Controller` and `Compute` roles::

@ -283,7 +283,7 @@ by this ansible way.
.. code-block:: bash
export CONTAINERCLI=podman #choose appropriate contaier cli here
export CONTAINERCLI=podman #choose appropriate container cli here
source stackrc
mkdir inventories
for i in overcloud cell1; do \

@ -20,7 +20,7 @@ the cell host discovery:
# CONTAINERCLI can be either docker or podman
export CONTAINERCLI='docker'
# run cell host dicovery
# run cell host discovery
ssh heat-admin@${CTRL_IP} sudo ${CONTAINERCLI} exec -i -u root nova_api \
nova-manage cell_v2 discover_hosts --by-service --verbose
@ -34,7 +34,7 @@ the cell host discovery:
.. note::
Optionally the cell uuid cal be specificed to the `discover_hosts` and
Optionally the cell uuid cal be specified to the `discover_hosts` and
`list_hosts` command to only target against a specific cell.
Delete a compute from a cell

@ -147,7 +147,7 @@ been added to the network definitions in the network_data.yaml file format:
The cell controllers use virtual IPs, therefore the existing VIPs from the
central overcloud stack should not be referenced. In case cell controllers
and cell computes get split into sepearate stacks, the cell compute stack
and cell computes get split into separate stacks, the cell compute stack
network_data file need an external_resource_vip_id reference to the cell
controllers VIP resource.
@ -382,7 +382,7 @@ Add the following content into a parameter file for the cell, e.g. `cell1/cell1.
CellControllerCount: 3
ComputeCount: 0
# Compute names need to be uniq, make sure to have a uniq
# Compute names need to be unique, make sure to have a unique
# hostname format for cell nodes
ComputeHostnameFormat: 'cell1-compute-%index%'

@ -354,7 +354,7 @@ The command line interface supports the following options::
addition to registry authentication via
ContainerImageRegistryCredentials.
--cephadm-default-container
Use the default continer defined in cephadm instead of
Use the default container defined in cephadm instead of
container_image_prepare_defaults.yaml. If this is
used, 'cephadm bootstrap' is not passed the --image
parameter.
@ -445,7 +445,7 @@ initial Ceph configuration file which can be passed with the --config
option. These settings may also be modified after `openstack overcloud
ceph deploy`.
The deprecated Heat paramters `CephPoolDefaultSize` and
The deprecated Heat parameters `CephPoolDefaultSize` and
`CephPoolDefaultPgNum` no longer have any effect as these
configurations are not made during overcloud deployment.
However, during overcloud deployment pools are created and
@ -956,7 +956,7 @@ Then the Ceph cluster will have the following parameters set::
ms_bind_ipv6 = True
Because the storage networks in network_data.yaml contain `ipv6:
true`, the ipv6_subet values are extracted and the Ceph globals
true`, the ipv6_subset values are extracted and the Ceph globals
`ms_bind_ipv4` is set `false` and `ms_bind_ipv6` is set `true`.
It is not supported to have the ``public_network`` use IPv4 and
the ``cluster_network`` use IPv6 or vice versa.

@ -102,7 +102,7 @@ Deploying the Overcloud
Provision networks and ports if using Neutron
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If using Neutron for resource managment, Network resources for the deployment
If using Neutron for resource management, Network resources for the deployment
still must be provisioned with the ``openstack overcloud network provision``
command as documented in :ref:`custom_networks`.
@ -559,7 +559,7 @@ The following is a sample environment file that shows setting these values
Use ``DeployedServerPortMap`` to assign an ControlPlane Virtual IP address from
any CIDR, and the ``RedisVirtualFixedIPs`` and ``OVNDBsVirtualFixedIPs``
parameters to assing the ``RedisVip`` and ``OVNDBsVip``::
parameters to assign the ``RedisVip`` and ``OVNDBsVip``::
resource_registry:
OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml

@ -972,7 +972,7 @@ the command from example_export_dcn_ (Victoria or prior releases).
``network_data_v2.yaml``, ``vip_data.yaml``, and ``baremetal_deployment.yaml``
are the same files used with the ``control-plane`` stack. However, the files
will need to be modified if the ``edge-0`` or ``edge-1`` stacks require
addditional provisioning of network resources for new subnets. Update the files
additional provisioning of network resources for new subnets. Update the files
as needed and continue to use the same files for all ``overcloud deploy``
commands across all stacks.

@ -391,7 +391,7 @@ you need to disable image conversion you may override the
parameter_defaults:
GlanceImageImportPlugin: []
The ``glance.yaml`` file sets the following to configue the local Glance backend::
The ``glance.yaml`` file sets the following to configure the local Glance backend::
parameter_defaults:
GlanceShowMultipleLocations: true
@ -456,7 +456,7 @@ config-download. If the ``--cephx-key-client-name`` is not passed,
then the default cephx client key called `openstack` will be
extracted.
The genereated ``~/central_ceph_external.yaml`` should look something
The generated ``~/central_ceph_external.yaml`` should look something
like the following::
parameter_defaults:
@ -484,14 +484,14 @@ cluster.
The ``openstack overcloud export ceph`` command will obtain all of the
values from the config-download directory of the stack specified by
`--stack` option. All values are extracted from the
``cephadm/ceph_client.yml`` file. This file is genereated when
``cephadm/ceph_client.yml`` file. This file is generated when
config-download executes the export tasks from the tripleo-ansible
role `tripleo_cephadm`. It should not be necessary to extract these
values manually as the ``openstack overcloud export ceph`` command
will genereate a valid YAML file with `CephExternalMultiConfig`
will generate a valid YAML file with `CephExternalMultiConfig`
populated for all stacks passed with the `--stack` option.
The `ceph_conf_overrides` section of the file genereated by ``openstack
The `ceph_conf_overrides` section of the file generated by ``openstack
overcloud export ceph`` should look like the following::
ceph_conf_overrides:
@ -879,7 +879,7 @@ Use the `openstack overcloud export ceph` command to create
In the above example a coma-delimited list of Heat stack names is
provided to the ``--stack`` option. Pass as many stacks as necessary
for all deployed DCN sites so that the configuration data to connect
to every DCN Ceph cluster is extracted into the single genereated
to every DCN Ceph cluster is extracted into the single generated
``dcn_ceph_external.yaml`` file.
If you created a separate cephx key called external on each DCN ceph
@ -1017,7 +1017,7 @@ described above.
Thus, for a three stack deployment the following will be the case.
- The initial deployment of the cental stack is configured with one
- The initial deployment of the central stack is configured with one
external Ceph cluster called central, which is the default store for
Cinder, Glance, and Nova. We will refer to this as the central
site's "primary external Ceph cluster".
@ -1082,7 +1082,7 @@ Ensure you have Glance 3.0.0 or newer as provided by the
Authenticate to the control-plane using the RC file generated
by the stack from the first deployment which contains Keystone.
In this example the stack was called "control-plane" so the file
to source beofre running Glance commands will be called
to source before running Glance commands will be called
"control-planerc".
Confirm the expected stores are available:
@ -1324,7 +1324,7 @@ site, which is the default backend for Glance.
After the above is run the output of `openstack image show
$IMAGE_ID -f value -c properties` should contain a JSON data structure
whose key called `stores` should looke like "dcn0,central" as
whose key called `stores` should look like "dcn0,central" as
the image will also exist in the "central" backend which stores its
data on the central Ceph cluster. The same image at the Central site
may then be copied to other DCN sites, booted in the vms or volumes

@ -50,7 +50,7 @@ Architecture
Deploying the Operational Tool Server
-------------------------------------
There is an ansible project called opstools-ansible (OpsTools_) on github that helps to install the Operator Server, further documentation of the operational tool server instalation can be founded at (OpsToolsDoc_).
There is an ansible project called opstools-ansible (OpsTools_) on github that helps to install the Operator Server, further documentation of the operational tool server installation can be founded at (OpsToolsDoc_).
.. _OpsTools: https://github.com/centos-opstools/opstools-ansible
.. _OpsToolsDoc: https://github.com/centos-opstools/opstools-doc
@ -135,7 +135,7 @@ Before deploying the Overcloud
LoggingSharedKey: secret # The key
LoggingSSLCertificate: | # The content of the SSL Certificate
-----BEGIN CERTIFICATE-----
...contens of server.pem here...
...contents of server.pem here...
-----END CERTIFICATE-----
- Performance Monitoring::

@ -91,7 +91,7 @@ Example::
type: ovs_dpdk_port
name: dpdk0
mtu: 2000
rx_queu: 2
rx_queue: 2
members:
-
type: interface

@ -8,14 +8,14 @@ OpenvSwitch before network deployment (os-net-config), but after the
hugepages are created (hugepages are created using kernel args). This
requirement is also valid for some 3rd party SDN integration. This kind of
configuration requires additional TripleO service definitions. This document
explains how to acheive such deployments on and after `train` release.
explains how to achieve such deployments on and after `train` release.
.. note::
In `queens` release, the resource `PreNetworkConfig` can be overriden to
In `queens` release, the resource `PreNetworkConfig` can be overridden to
achieve the required behavior, which has been deprecated from `train`
onwards. The implementations based on `PreNetworkConfig` should be
moved to other available aternates.
moved to other available alternates.
The TripleO service `OS::TripleO::BootParams` configures the parameter
`KernelArgs` and reboots the node using the `tripleo-ansible` role

@ -400,7 +400,7 @@ Example ``roles_data`` below. (The list of default services has been left out.)
#############################################################################
- name: Controller
description: |
Controller role that has all the controler services loaded and handles
Controller role that has all the controller services loaded and handles
Database, Messaging and Network functions.
CountDefault: 1
tags:
@ -557,7 +557,7 @@ network configuration templates as needed.
be used for both compute roles (``computeleaf0`` and
``computeleaf1``).
Create a environement file (``network-environment-overrides.yaml``) with
Create a environment file (``network-environment-overrides.yaml``) with
``resource_registry`` overrides to specify the network configuration templates
to use. For example::

@ -26,7 +26,7 @@ baremetal on which SR-IOV needs to be enabled.
Also, SR-IOV requires mandatory kernel parameters to be set, like
``intel_iommu=on iommu=pt`` on Intel machines. In order to enable the
configuration of kernel parametres to the host, host-config-pre-network
configuration of kernel parameters to the host, host-config-pre-network
environment file has to be added for the deploy command.
Adding the following arguments to the ``openstack overcloud deploy`` command

@ -323,7 +323,7 @@ For reference, the Novajoin based composable service is located at
tripleo-ipa Composable Service
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you're deploying *TLS-everwhere* with tripleo-ipa prior to Victoria, you need to
If you're deploying *TLS-everywhere* with tripleo-ipa prior to Victoria, you need to
override the default Novajoin composable service. Add the following composable service to
the ``resource_registry`` in ``tls-parameters.yaml``::

@ -2,7 +2,7 @@ Tolerate deployment failures
============================
When proceeding to large scale deployments, it happens very often to have
infrastucture problems such as network outages, wrong configurations applied
infrastructure problems such as network outages, wrong configurations applied
on hardware, hard drive issues, etc.
It is unpleasant to deploy hundred of nodes and only have a few of them which

@ -34,7 +34,7 @@ baremetal on which vDPA needs to be enabled.
Also, vDPA requires mandatory kernel parameters to be set, like
``intel_iommu=on iommu=pt`` on Intel machines. In order to enable the
configuration of kernel parametres to the host, The ``KernelArgs`` role
configuration of kernel parameters to the host, The ``KernelArgs`` role
parameter has to be defined accordingly.
Adding the following arguments to the ``openstack overcloud deploy`` command
@ -146,7 +146,7 @@ Scheduling instances
Normally, the ``PciPassthroughFilter`` is sufficient to ensure that a vDPA instance will
land on a vDPA host. If we want to prevent other instances from using a vDPA host, we need
to setup the `isolate-aggreate feature
to setup the `isolate-aggregate feature
<https://docs.openstack.org/nova/latest/reference/isolate-aggregates.html>`_.
Example::
@ -431,7 +431,7 @@ Validating the OVN agents::
+--------------------------------------+----------------------+-------------------------+-------------------+-------+-------+----------------------------+
Other usefull commands for troubleshooting::
Other useful commands for troubleshooting::
[root@computevdpa-0 ~]# ovs-appctl dpctl/dump-flows -m type=offloaded
[root@computevdpa-0 ~]# ovs-appctl dpctl/dump-flows -m

@ -11,7 +11,7 @@ by following the process outlined in on this page.
If you're just scaling down nodes and plan to re-use them. Use :ref:`scale_roles`
instead. For temporary issues with nodes, they can be blacklisted temporarily
using ``DeploymentServerBlacklist``.
This guide is specifcally for removing nodes from the environment.
This guide is specifically for removing nodes from the environment.
.. note::
If your Compute node is still hosting VM's, ensure they are migrated to

@ -17,7 +17,7 @@ where instance creation times must be minimized.
Since Ussuri Nova also provides an API to pre-cache images on Compute nodes.
See the `Nova Image pre-caching documentation <https://docs.openstack.org/nova/ussuri/admin/image-caching.html#image-pre-caching>`_.
.. note:: The Nova Image Cache is not used when using Ceph RBD for Glange images and Nova ephemeral disk. See `Nova Image Caching documentation <https://docs.openstack.org/nova/ussuri/admin/image-caching.html>`_.
.. note:: The Nova Image Cache is not used when using Ceph RBD for Glance images and Nova ephemeral disk. See `Nova Image Caching documentation <https://docs.openstack.org/nova/ussuri/admin/image-caching.html>`_.
Image Cache Cleanup
-------------------
@ -131,7 +131,7 @@ Pre-caching on one node and distributing to remaining nodes
In the case of a :doc:`../features/distributed_compute_node` it may be desirable to transfer an image to a single compute node at a remote site and then redistribute it from that node to the remaining compute nodes.
The SSH/SCP configuration that exists between the compute nodes to support cold migration/resize is reused for this purpose.
.. warning:: SSH/SCP is inefficient over high latency networks. The method should only be used when the compute nodes targetted by the playbook are all within the same site. To ensure this is the case set tripleo_nova_image_cache_plan to the stack name of the site. Multiple runs of ansible-playbook are then required, targetting a different site each time.
.. warning:: SSH/SCP is inefficient over high latency networks. The method should only be used when the compute nodes targeted by the playbook are all within the same site. To ensure this is the case set tripleo_nova_image_cache_plan to the stack name of the site. Multiple runs of ansible-playbook are then required, targeting a different site each time.
To enable this simply set `tripleo_nova_image_cache_use_proxy: true` in the arguments file.
The image is distributed from the first compute node by default. To use a specific compute node also set `tripleo_nova_image_cache_proxy_hostname`.

@ -81,7 +81,7 @@ What are these above vars:
* `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 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.
* `gather_facts`: We need to set gather_facts to true as os_tempest rely on targeted environment facts for installing stuff.
Here are the `defaults vars of os_tempest role <https://docs.openstack.org/openstack-ansible-os_tempest/latest/user/default.html>`_.

@ -678,7 +678,7 @@ Generate tempest.conf and run tempest tests within the container
with a command which copies your `tempest.conf` from `container_tempest`
directory to `tempest_workspace/etc` directory::
$ cp /home/stack/container_tempest/tempets.conf /home/stack/tempest_workspace/etc/tempest.conf
$ cp /home/stack/container_tempest/tempest.conf /home/stack/tempest_workspace/etc/tempest.conf
* Set executable privileges to the `tempest_script.sh` script::

@ -810,7 +810,7 @@ Following there is a list of all the changes needed:
10. If using a modified version of the core Heat template collection from
Newton, you need to re-apply your customizations to a copy of the Queens
version. To do this, use a git version control system or similar toolings
version. To do this, use a git version control system or similar tooling
to compare.

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

@ -8,7 +8,7 @@ Bare Metal service to provision baremetal before the overcloud is deployed.
This adds a new provision step before the overcloud deploy, and the output of
the provision is a valid :doc:`../features/deployed_server` configuration.
In the Wallaby release the baremetal provisining was extended to also manage
In the Wallaby release the baremetal provisioning was extended to also manage
the neutron API resources for :doc:`../features/network_isolation` and
:doc:`../features/custom_networks`, and apply network configuration on the
provisioned nodes using os-net-config.

@ -18,7 +18,7 @@ and only see the ``enroll`` state if their power management fails to validate::
openstack overcloud import instackenv.json
Nodes can optionally be introspected in this step by passing the --provide flag
which will progress them through through the manageable_ state and eventually to
which will progress them through the manageable_ state and eventually to
the available_ state ready for deployment.
manageable

@ -7,7 +7,7 @@
#. Download and install the python-tripleo-repos RPM from
the appropriate RDO repository
.. admonition:: CentOS Strem 8
.. admonition:: CentOS Stream 8
:class: centos8
Current `Centos 8 RDO repository <https://trunk.rdoproject.org/centos8/component/tripleo/current/>`_.

@ -140,7 +140,7 @@ Hack the promotion with testproject
Finally testproject_ and the ability to run individual periodic jobs on
demand is an important part of the ruck|rover toolbox. In some cases you may
want to run a job for verification of a given launchpad bug that affects
perioric jobs.
periodic jobs.
However another important use is when the ruck|rover notice that one of the
jobs in criteria failed on something they (now) know how to fix, or on some
@ -191,7 +191,7 @@ at time of writing we see::
priority=1
So the centos7 master tripleo-ci-testing *hash* is
*544864ccc03b053317f5408b0c0349a42723ce73_ebb98bd9a*. The corrresponding repo
*544864ccc03b053317f5408b0c0349a42723ce73_ebb98bd9a*. The corresponding repo
is given by the baseurl above and if you navigate to that URL with your
browser you can see the list of packages used in the jobs. Thus, the job
specified in the example above for testproject

@ -115,7 +115,7 @@ Troubleshooting a failed job
When your newly added job fails, you may want to download its logs for a local
inspection and root cause analysis. Use the
`tripleo-ci gethelogs script
`tripleo-ci getthelogs script
<https://github.com/openstack-infra/tripleo-ci/blob/master/scripts/getthelogs>`_
for that.
@ -157,7 +157,7 @@ Some of the overridable settings are:
- `tempest_format`: To run tempest using different format (packages, containers, venv).
- `tempest_extra_config`: A dict of additional tempest config to be overridden.
- `tempest_plugins`: A list of tempest plugins needs to be installed.
- `standalone_environment_files`: List of environment files to be overriden
- `standalone_environment_files`: List of environment files to be overridden
by the featureset configuration on standalone deployment. The environment
file should exist in tripleo-heat-templates repo.
- `test_white_regex`: Regex to be used by tempest

@ -10,7 +10,7 @@ briefly remind folks of their options.
---------------------------------------------------------------
RDO's zuul is setup to directly inherit from upstream zuul. Any TripleO
job that executes upstream should be rerunable in RDO's zuul. A distinct
job that executes upstream should be re-runnable in RDO's zuul. A distinct
advantage here is that you can ask RDO admins to hold the job for you,
get your ssh keys on the box and debug the live environment. It's good
stuff. To hold a node, ask your friends in #rhos-ops

@ -91,13 +91,13 @@ In some cases bugs are fixed once a new version of some service is released
service/project). In this case the rover is expected to know what that fix is
and do everything they can to make it available in the jobs. This will range
from posting gerrit reviews to bump some service version in requirements.txt
through to simply harrassing the 'right folks' ;) in the relevant `TripleO Squad`_.
through to simply harassing the 'right folks' ;) in the relevant `TripleO Squad`_.
In other cases bugs may be deprioritized - for example if the job is non voting
or is not in the promotion criteria then any related bugs are less likely to
be getting the rover's attention. If you are interested in such jobs or bugs
then you should go to #OFTC oooq channel and find the folks with "ruck" or
"rover" in their nick and harrass them about it!
"rover" in their nick and harass them about it!
Of course for other cases there are bona fide bugs with the `TripleO CI code`_
that the rover is expected to fix. To avoid being overwhelmed time management
@ -176,7 +176,7 @@ Grafana is also useful for tracking promotions across branches.
represent promotions and height shows the number of promotions on that day.
Finally grafana tracks a list of all running jobs hilighting the failures in
Finally grafana tracks a list of all running jobs highlighting the failures in
red.
.. image:: ./_images/grafana3.png

@ -89,7 +89,7 @@ Here are a non-exhaustive list of things that are expected:
which doesn't only mean +1/-1, but also comments the code that confirm
that the patch is ready (or not) to be merged into the repository.
This capacity to provide these kind of reviews is strongly evaluated when
recruiting new core reviewers. It is prefered to provide quality reviews
recruiting new core reviewers. It is preferred to provide quality reviews
over quantity. A negative review needs productive feedback and harmful
comments won't help to build credibility within the team.

@ -142,7 +142,7 @@ Prepare version tags
Based on the versions.csv data, an openstack/releases patch needs to be created
to tag the release with the provided hashes. You can determine which TripleO
projects are needed by finding the projects taged with "team: tripleo_".
projects are needed by finding the projects tagged with "team: tripleo_".
`An example review`_. Please be aware of changes between versions and create
the appropriate version number as necessary (e.g. major, feature, or bugfix).

@ -26,7 +26,7 @@ how to use this command as an operator.
.. _building_containers_deploy_guide: https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/3rd_party.html
One of the TipleO CI jobs that executes this command is the
One of the TripleO CI jobs that executes this command is the
tripleo-build-containers-centos-7_ job. This job invokes the overcloud container
image build command in the build.sh.j2_ template::

Loading…
Cancel
Save