ON THIS PAGE
Understand the Update Plan
There is an update_plan section in the Contrail Cloud configuration file that is used for
overcloud update (which has three stages). It is not used for updating any of the other
components. It is very important for the user to understand the idea of update plan and how to
define batches of nodes for update. Use this section to understand the update plan, how it
works, and how to configure the update plan in your site.yml configuration
file.
Overview
The update plan controls the overcloud update sequencing. It allows you to define which node batch to update with each run of the contrail-cloud-update-overcloud-step2.sh script.
The overcloud update contrail-cloud-update-overcloud-step2.sh script will:
- Compare the lock files with your defined batch list to find the next batch that has not already been completed.
- Update all nodes per batch as you defined in the update plan nodes list.
- Update packages and containers for each node you defined in the current batch.
- Update one batch per script run, as defined in the update plan.
- Automatically create a lock file when the batch is processed. This is how the script knows to move on to the next batch.
- Rerun until there are no longer any batches left to update.
Configure Your Update Plan
Use the following sample to configure the update plan in the config/site.yml file. The sample would help you to:
-
Understand the configuration hierarchy.
-
Determine the configuration options.
-
Identify proper indentations and empty space.
-
Understand how to target specific nodes to be updated as workloads are migrated.
# Copyright 2023 Juniper Networks, Inc. All rights reserved.
# Licensed under the Juniper Networks Script Software License (the "License").
# You may not use this script file except in compliance with the License, which is located at
# http://www.juniper.net/support/legal/scriptlicense/
# Unless required by applicable law or otherwise agreed to in writing by the parties,
# software distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
#
#
#
# The update_plan provides the blueprint for working through the deployment update.
# The plan is defined as a series of "batches". Each batch is processed by the
# contrail-cloud-update-overcloud-step2.sh, one batch for each run. Once a batch is
# successfully completed a lock file is created to indicate that state. The next run
# of the contrail-cloud-update-overcloud-step2.sh script will find the next unfinished
# batch to process.
#
update_plan:
# reboot_computes:
# parallel: all computes from batch will be rebooted at one time
# sequence: all computes from batch will be rebooted one by one
# disabled: computes after update will not be rebooted, you need to reboot manually
# Each batch defines:
# name: a unique batch name (used for lock file naming)
# update_type: either "sequence" (one node at a time) or
# "parallel" (all nodes together)
# nodes_list: a list of nodes to apply the update to. The special
# keyword "ControlPlane" represents the Openstack controllers.
# For each of these roles, the update
# will be performed on a single instance at a time sequentially
# until all roles instances are updated.
reboot_computes: parallel
batches:
# The first batch should always be the control plane.
- name: controlplane
update_type: sequence
nodes_list:
- ControlPlane
# This batch is used to update all the DPDK and kernel computes in rack0 in parallel.
- name: computenodes_rack0
update_type: parallel
nodes_list:
- overcloudx51-compdpdk0hw2-0
- overcloudx51-compkernel0hw0-0
- overcloudx51-compkernel0hw1-0
# This batch is used to update all the DPDK and kernel computes in rack1 in parallel.
- name: computenodes_rack1
update_type: parallel
nodes_list:
- overcloudx51-compdpdk1hw3-0
- overcloudx51-compkernel1hw0-0
- overcloudx51-compkernel1hw1-0
# This batch is used to update all the SRIOV computes in sequence (just an example).
- name: sriovnodes
update_type: sequence
nodes_list:
- overcloudx51-compsriov0hw4-0
- overcloudx51-compsriov1hw5-0
# Batch to update ceph storage nodes. To ensure the integrity of the ceph cluster,
# each role instance will be updated sequentially.
- name: cephnodes
update_type: sequence
nodes_list:
- overcloudx51-cephstorage0hw6-0
- overcloudx51-cephstorage0hw6-1
- overcloudx51-cephstorage1hw7-0
Edit the above update plan to match your deployment for each targeted batch.
- Name Your Unique Batch
- Define the Update Type for the Named Node Role
- Define the Nodes in the Named Batch
- Finish Defining Your Remaining Batches
Name Your Unique Batch
During update, you can control the batch order in your update_plan. You
choose a unique batch name to identify each unique batch, and for lock file naming. Choose
a unique name that you define for each batch.
The contrail-cloud-update-overcloud-step2.sh script identifies the first
unique named batch, which has not already been updated. The script creates a lockfile
after each successful batch update to identify it as being completed. To start, you might
configure it to look like this:
update_plan: batches: # unique batch name - name: controller_nodes
Define the Update Type for the Named Node Role
The update_type determines the update order of the nodes in the named
batch run. You have the option of running the update in sequence. The sequence update will
update one node at a time, per batch run. You can also choose to run the update in
parallel. The parallel update will update all nodes together, per batch run.
Use the following sample to update the nodes in the named batch in sequence:
update_plan:
batches:
# update_type: either "sequence" all positions from batch list will be processed one by one
# "parallel" batch will update all positions from list at the same time
update_type: sequenceDefine the Nodes in the Named Batch
Define the nodes in the nodes_list that you would like to update in the
named batch run. These nodes are the specific node names from your environment. Group by
role when you define your batches. As an example, group Ceph servers together, and
computes together.
Run the following commands to collect the server names from the undercloud:
(undercloud) [stack@undercloud ~]$ openstack server list --name ceph -c Name -f value | sort
(undercloud) [stack@undercloud ~]$ openstack server list --name comp -c Name -f value | sort
Following is the sample output from the CLI input above to collect Ceph and compute server names:
overcloudw9o-cephstorage0hw6-0
overcloudw9o-cephstorage1hw7-0
overcloudw9o-cephstorage2hw6-0
overcloudw9o-compdpdk2hw2-0
overcloudw9o-compkernel0hw0-0
overcloudw9o-compsriov1hw3-0
The ControlPlane is a special keyword understood by the update plan. The
ControlPlane represents the OpenStack controllers. The
ControlPlane updates in sequence by default. One OpenStack controller
instance is updated at a time.
Always define the ControlPlane as the first entry in the first batch in
your defined batch list.
update_plan:
batches:
- name: controller_nodes
update_type: sequence
nodes_list:
- ControlPlane
Finish Defining Your Remaining Batches
Define the rest of your batches. Ensure that you target all nodes for update. The
update_plan sample shows an example of how you might define compute
batches by rack, or compute type. Remember that the ControlPlane should
always be the first batch to update. The next batches should include the compute nodes.
The last batches should consist of the storage nodes.