openstack/tripleo-docs
Code Issues Proposed changes

Merge "Update the documentation to use limit option."

Browse Source
This commit is contained in:
Zuul 2019-02-15 13:17:30 +00:00 committed by Gerrit Code Review
commit c629e34161
3 changed files with 55 additions and 53 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
doc/source/upgrade/fast_forward_upgrade.rst
View File

@ -351,16 +351,12 @@ openstack overcloud upgrade run
This will run the ansible playbooks to deliver the upgrade configuration.
By default, 3 playbooks are executed: the upgrade_steps_playbook, then the
deploy_steps_playbook and finally the post_upgrade_steps_playbook. These
playbooks are invoked on those overcloud nodes specified by the ``--roles`` or
``--nodes`` parameters, which are mutually exclusive. You are expected to use
``--roles`` for controlplane nodes, since these need to be upgraded in the same
step. For non controlplane nodes, such as Compute or Storage, you can use
``--nodes`` to specify a single node or list of nodes to upgrade. The controller
nodes need to be the first upgraded, following by the compute and storage ones.
playbooks are invoked on those overcloud nodes specified by the ``--limit``
parameter.
.. code-block:: bash
openstack overcloud upgrade run --roles Controller
openstack overcloud upgrade run --limit Controller
.. note::
@ -372,14 +368,27 @@ nodes need to be the first upgraded, following by the compute and storage ones.
.. code-block:: bash
openstack overcloud upgrade run --roles Controller --playbook upgrade_steps_playbook.yaml
openstack overcloud upgrade run --roles Controller --playbook deploy_steps_playbook.yaml
openstack overcloud upgrade run --roles Controller --playbook post_upgrade_steps_playbook.yaml
openstack overcloud upgrade run --limit Controller --playbook upgrade_steps_playbook.yaml
openstack overcloud upgrade run --limit Controller --playbook deploy_steps_playbook.yaml
openstack overcloud upgrade run --limit Controller --playbook post_upgrade_steps_playbook.yaml
After all three playbooks have been executed without error on all nodes of
the controller role the controlplane will have been fully upgraded to Queens.
At a minimum an operator should check the health of the pacemaker cluster
.. admonition:: Stable Branch
:class: stable
The ``--limit`` was introduced in the Stein release. In previous versions,
use ``--nodes`` or ``--roles`` paremeters.
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,
you often want to specify a single node or a list of nodes to ``--limit``.
The controller nodes need to be the first upgraded, following by the compute
and storage ones.
.. code-block:: bash
[root@overcloud-controller-0 ~]# pcs status | grep -C 10 -i "error\|fail\|unmanaged"
@ -401,17 +410,17 @@ during upgrade prepare with the ``--container-registry-file`` parameter.
completed, or it may drive unexpected results.
For non controlplane nodes, such as Compute or ObjectStorage, you can use
``--nodes overcloud-compute-0`` to upgrade particular nodes, or even
``--limit overcloud-compute-0`` to upgrade particular nodes, or even
"compute0,compute1,compute3" for multiple nodes. Note these are again
upgraded in parallel. Also note that you can still use the ``--roles`` parameter
with non controlplane roles if that is preferred.
upgraded in parallel. Also note that you can pass roles names to upgrade all
nodes in a role at the same time is preferred.
.. code-block:: bash
openstack overcloud upgrade run --nodes overcloud-compute-0
openstack overcloud upgrade run --limit overcloud-compute-0
Use of ``--nodes`` allows the operator to upgrade some subset, perhaps just one,
compute or other non controlplane node and verify that the upgrade is
Use of ``--limit`` allows the operator to upgrade some subset, perhaps just
one, compute or other non controlplane node and verify that the upgrade is
successful. One may even migrate workloads onto the newly upgraded node and
confirm there are no problems, before deciding to proceed with upgrading the
remaining nodes that are still on Newton.
@ -420,19 +429,13 @@ Again you can optionally step through the upgrade playbooks if you prefer. Be
sure to run upgrade_steps_playbook.yaml then deploy_steps_playbook.yaml and
finally post_upgrade_steps_playbook.yaml in that order.
.. code-block:: bash
openstack overcloud upgrade run --nodes overcloud-compute-1 \
--playbook upgrade_steps_playbook.yaml
# etc for the other 2 as above example for controller
For re-run, you can specify ``--skip-tags validation`` to skip those step 0
ansible tasks that check if services are running, in case you can't or
don't want to start them all.
.. code-block:: bash
openstack overcloud upgrade run --roles Controller --skip-tags validation
openstack overcloud upgrade run --limit Controller --skip-tags validation
openstack overcloud ceph-upgrade run
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

45
doc/source/upgrade/major_upgrade.rst
View File

@ -205,15 +205,12 @@ openstack overcloud upgrade run
The `upgrade run` command runs the Ansible playbooks to deliver the upgrade configuration.
By default, 3 playbooks are executed: the upgrade_steps_playbook, then the
deploy_steps_playbook and finally the post_upgrade_steps_playbook. These
playbooks are invoked on those overcloud nodes specified by the ``--roles`` or
``--nodes`` parameters, which are mutually exclusive. You are expected to use
``--roles`` for controlplane nodes, since these need to be upgraded in the same
step. For non controlplane nodes, such as Compute or Storage, you can use
``--nodes`` to specify a single node or list of nodes to upgrade.
playbooks are invoked on those overcloud nodes specified by the ``--limit``
parameter.
.. code-block:: bash
openstack overcloud upgrade run --roles Controller
openstack overcloud upgrade run --limit Controller
**Optionally** specify ``--playbook`` to manually step through the upgrade
playbooks: You need to run all three in this order and as specified below
@ -221,9 +218,9 @@ playbooks: You need to run all three in this order and as specified below
.. code-block:: bash
openstack overcloud upgrade run --roles Controller --playbook upgrade_steps_playbook.yaml
openstack overcloud upgrade run --roles Controller --playbook deploy_steps_playbook.yaml
openstack overcloud upgrade run --roles Controller --playbook post_upgrade_steps_playbook.yaml
openstack overcloud upgrade run --limit Controller --playbook upgrade_steps_playbook.yaml
openstack overcloud upgrade run --limit Controller --playbook deploy_steps_playbook.yaml
openstack overcloud upgrade run --limit Controller --playbook post_upgrade_steps_playbook.yaml
After all three playbooks have been executed without error on all nodes of
the controller role the controlplane will have been fully upgraded to Queens.
@ -242,30 +239,20 @@ passed during upgrade prepare.
[root@overcloud-controller-0 ~]# docker ps -a
For non controlplane nodes, such as Compute or ObjectStorage, you can use
``--nodes overcloud-compute-0`` to upgrade particular nodes, or even
``--limit overcloud-compute-0`` to upgrade particular nodes, or even
"compute0,compute1,compute3" for multiple nodes. Note these are again
upgraded in parallel. Also note that you can still use the ``--roles`` parameter
with non controlplane roles if that is preferred.
upgraded in parallel. Also note that you can pass roles names to upgrade all
nodes in a role at the same time is preferred.
.. code-block:: bash
openstack overcloud upgrade run --nodes overcloud-compute-0
openstack overcloud upgrade run --limit overcloud-compute-0
Use of ``--nodes`` allows the operator to upgrade some subset, perhaps just one,
Use of ``--limit`` allows the operator to upgrade some subset, perhaps just one,
compute or other non controlplane node and verify that the upgrade is
successful. One may even migrate workloads onto the newly upgraded node and
confirm there are no problems, before deciding to proceed with upgrading the
remaining nodes that are still on Pike.
Again you can optionally step through the upgrade playbooks if you prefer. Be
sure to run upgrade_steps_playbook.yaml then deploy_steps_playbook.yaml and
finally post_upgrade_steps_playbook.yaml in that order.
.. code-block:: bash
openstack overcloud upgrade run --nodes overcloud-compute-1 \
--playbook upgrade_steps_playbook.yaml
# etc for the other 2 as above example for controller
remaining nodes.
For re-run, you can specify ``--skip-tags`` validation to skip those step 0
ansible tasks that check if services are running, in case you can't or
@ -273,7 +260,13 @@ don't want to start them all.
.. code-block:: bash
openstack overcloud upgrade run --roles Controller --skip-tags validation
openstack overcloud upgrade run --limit Controller --skip-tags validation
.. admonition:: Stable Branch
:class: stable
The --limit was introduced in the Stein release. In previous versions, use
--nodes or --roles parmeters.
openstack overcloud external-upgrade run (for services)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

14
doc/source/upgrade/minor_update.rst
View File

@ -99,11 +99,11 @@ the OpenStack release that you currently operate, perform these steps:
#. **Update run**
Run the update procedure on a subset of nodes selected via the
``--nodes`` parameter:
``--limit`` parameter:
.. code-block:: bash
openstack overcloud update run --nodes overcloud-controller-0
openstack overcloud update run --limit overcloud-controller-0
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`
@ -224,10 +224,16 @@ the registry file generated from the first step above::
openstack overcloud update --init-minor-update --container-registry-file latest-images.yaml
3. Invoke the minor update on the nodes specified with the ``--nodes``
3. Invoke the minor update on the nodes specified with the ``--limit``
parameter::
openstack overcloud update --nodes controller-0
openstack overcloud update --limit controller-0
.. admonition:: Stable Branch
:class: stable
The `--limit` was introduced in the Stein release. In previous versions,
use `--nodes` or `--roles` parmeters.
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).