Fix typos
This patch tries to fix maximum typos in docs. Change-Id: Ic406e3a4423cdd7c46c8a4497d43d63c95b2a9f5
This commit is contained in:
Rajesh Tailor
parent
78374417bb
commit
6447c381b1
@ -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::
|
||||
|
||||
@ -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")
|
||||
|
||||
@ -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,
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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::
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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;
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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).
|
||||
|
||||
@ -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).
|
||||
|
||||
@ -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``.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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 => {
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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'`
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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::
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
::
|
||||
|
||||
|
||||
@ -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::
|
||||
|
||||
|
||||
@ -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 \
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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 \
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
.. _update_network_configuration_post_deploymenet:
|
||||
.. _update_network_configuration_post_deployment:
|
||||
|
||||
Updating network configuration on the Overcloud after a deployment
|
||||
==================================================================
|
||||
|
||||
@ -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,
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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).
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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::
|
||||
|
||||
|
||||
@ -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::
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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/>`_.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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"
|
||||
|
||||
Loading…
Reference in New Issue
Block a user