tripleo-docs/doc/source/install/post_deployment/package_update.rst

Updating Packages on Overcloud Nodes

The update of overcloud packages to the latest version of the current release is referred to as the 'minor update' in TripleO (distinguishing it from the 'major upgrade' to the next release). In the Pike cycle the minor update workflow has changed significantly compared to previous cycles. There are thus version specific sections below.

Updating your Overcloud - Pike and beyond

Note

The minor update workflow described below is generally not well tested for non containerized Pike environments. The main focus for the TripleO upgrades engineering and QE teams has been on testing the minor update within a containerized Pike environment.

In particular there are currently no pacemaker update_tasks for the non containerized cluster services (i.e., puppet/services/pacemaker) and those will need to be considered and added. You should reach out to the TripleO community if this is an important feature for you and you'd like to contribute to it.

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 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.

There are essentially two steps: first perform a (relatively short) Heat stack update against the overcloud to generate the "config" ansible playbooks, and then execute these. See bug 1715557 for more information about this mechanism and its implementation.

1. You must first re-run the openstack overcloud container image prepare command to generate a docker registry file with the latest images see ../containers_deployment/overcloud for more information.

2. Perform a heat stack update to generate the ansible playbooks, specifying 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 parameter:

openstack overcloud update --nodes 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 is used on the playbooks).

Updating your Overcloud - Ocata and earlier

Updating packages on all overcloud nodes involves two steps. The first one makes sure that the overcloud plan is updated (a new tripleo-heat-templates rpm might have brought fixes/changes to the templates):

openstack overcloud deploy --update-plan-only \
--templates \
-e <full environment>

By using the parameter --update-plan-only we make sure we update only the stored overcloud plan and not the overcloud itself. Make sure you pass the exact same environment parameters that were used at deployment time.

The second step consists in updating the packages themselves on all overcloud nodes with a command similar to the following:

openstack overcloud update stack -i overcloud

This command updates the UpdateIdentifier parameter and triggers stack update operation. If this parameter is set, yum update command is executed on each node. Because running update on all nodes in parallel might be unsafe (an update of a package might involve restarting a service), the command above sets breakpoints on each overcloud node so nodes are updated one by one. When the update is finished on a node the command will prompt for removing breakpoint on next one.

Note

Make sure you use the -i parameter, otherwise update runs on background and does not prompt for removing of breakpoints.

Note

Multiple breakpoints can be removed by specifying list of nodes with a regular expression.

Note

If the update command is aborted for some reason you can always continue in the process by re-running same command.

Note

The --templates and --environment-file (-e) are now deprecated. They can still be passed to the command, but they will be silently ignored. This is due to the plan now used for deployment should only be modified via plan modification commands.