diff --git a/doc/source/upgrade/fast_forward_upgrade.rst b/doc/source/upgrade/fast_forward_upgrade.rst index dd6c1f40..3147744c 100644 --- a/doc/source/upgrade/fast_forward_upgrade.rst +++ b/doc/source/upgrade/fast_forward_upgrade.rst @@ -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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/source/upgrade/major_upgrade.rst b/doc/source/upgrade/major_upgrade.rst index d8d0e19f..963cbc94 100644 --- a/doc/source/upgrade/major_upgrade.rst +++ b/doc/source/upgrade/major_upgrade.rst @@ -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) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/source/upgrade/minor_update.rst b/doc/source/upgrade/minor_update.rst index 56d6eb41..4d63e640 100644 --- a/doc/source/upgrade/minor_update.rst +++ b/doc/source/upgrade/minor_update.rst @@ -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).