Chapter 5. Preparing for the Overcloud Upgrade
This process prepares the overcloud for the upgrade process.
Prerequisites
- You have upgraded the undercloud to the latest version.
5.1. Preparing Overcloud Registration Details
You need to provide the overcloud with the latest subscription details to ensure the overcloud consumes the latest packages during the upgrade process.
Prerequisites
- A subscription containing the latest OpenStack Platform repositories.
- If using activation keys for registration, create a new activation key including the new OpenStack Platform repositories.
Procedure
Edit the environment file containing your registration details. For example:
$ vi ~/templates/rhel-registration/environment-rhel-registration.yaml
Edit the following parameter values:
rhel_reg_repos- Update to include the new repositories for Red Hat OpenStack Platform 13.
rhel_reg_activation_key- Update the activation key to access the Red Hat OpenStack Platform 13 repositories.
rhel_reg_sat_repo- If using a newer version of Red Hat Satellite 6, update the repository containing Satellite 6’s management tools.
- Save the environment file.
Related Information
- For more information about registration parameters, see "Registering the Overcloud with an Environment File" in the Advanced Overcloud Customizations guide.
5.2. Deprecated parameters
Note that the following parameters are deprecated and have been replaced with role-specific parameters:
| Old Parameter | New Parameter |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Update these parameters in your custom environment files.
If your OpenStack Platform environment still requires these deprecated parameters, the default roles_data file allows their use. However, if you are using a custom roles_data file and your overcloud still requires these deprecated parameters, you can allow access to them by editing the roles_data file and adding the following to each role:
Controller Role
- name: Controller uses_deprecated_params: True deprecated_param_extraconfig: 'controllerExtraConfig' deprecated_param_flavor: 'OvercloudControlFlavor' deprecated_param_image: 'controllerImage' ...
Compute Role
- name: Compute uses_deprecated_params: True deprecated_param_image: 'NovaImage' deprecated_param_extraconfig: 'NovaComputeExtraConfig' deprecated_param_metadata: 'NovaComputeServerMetadata' deprecated_param_scheduler_hints: 'NovaComputeSchedulerHints' deprecated_param_ips: 'NovaComputeIPs' deprecated_server_resource_name: 'NovaCompute' disable_upgrade_deployment: True ...
Object Storage Role
- name: ObjectStorage uses_deprecated_params: True deprecated_param_metadata: 'SwiftStorageServerMetadata' deprecated_param_ips: 'SwiftStorageIPs' deprecated_param_image: 'SwiftStorageImage' deprecated_param_flavor: 'OvercloudSwiftStorageFlavor' disable_upgrade_deployment: True ...
5.3. Deprecated CLI options
Some command line options are outdated or deprecated in favor of using Heat template parameters, which you include in the parameter_defaults section on an environment file. The following table maps deprecated options to their Heat template equivalents.
Table 5.1. Mapping deprecated CLI options to Heat template parameters
| Option | Description | Heat Template Parameter |
|---|---|---|
|
| The number of Controller nodes to scale out |
|
|
| The number of Compute nodes to scale out |
|
|
| The number of Ceph Storage nodes to scale out |
|
|
| The number of Cinder nodes to scale out |
|
|
| The number of Swift nodes to scale out |
|
|
| The flavor to use for Controller nodes |
|
|
| The flavor to use for Compute nodes |
|
|
| The flavor to use for Ceph Storage nodes |
|
|
| The flavor to use for Cinder nodes |
|
|
| The flavor to use for Swift storage nodes |
|
|
| Defines the flat networks to configure in neutron plugins. Defaults to "datacentre" to permit external network creation |
|
|
| An Open vSwitch bridge to create on each hypervisor. This defaults to "br-ex". Typically, this should not need to be changed |
|
|
| The logical to physical bridge mappings to use. Defaults to mapping the external bridge on hosts (br-ex) to a physical name (datacentre). You would use this for the default floating network |
|
|
| Defines the interface to bridge onto br-ex for network nodes |
|
|
| The tenant network type for Neutron |
|
|
| The tunnel types for the Neutron tenant network. To specify multiple values, use a comma separated string |
|
|
| Ranges of GRE tunnel IDs to make available for tenant network allocation |
|
|
| Ranges of VXLAN VNI IDs to make available for tenant network allocation |
|
|
| The Neutron ML2 and Open vSwitch VLAN mapping range to support. Defaults to permitting any VLAN on the 'datacentre' physical network |
|
|
| The mechanism drivers for the neutron tenant network. Defaults to "openvswitch". To specify multiple values, use a comma-separated string |
|
|
| Disables tunneling in case you aim to use a VLAN segmented network or flat network with Neutron | No parameter mapping. |
|
| The overcloud creation process performs a set of pre-deployment checks. This option exits if any fatal errors occur from the pre-deployment checks. It is advisable to use this option as any errors can cause your deployment to fail. | No parameter mapping |
|
| Sets the NTP server to use to synchronize time |
|
These parameters have been removed from Red Hat OpenStack Platform. It is recommended to convert your CLI options to Heat parameters and add them to an environment file.
5.4. Composable networks
This version of Red Hat OpenStack Platform introduces a new feature for composable networks. If using a custom roles_data file, edit the file to add the composable networks to each role. For example, for Controller nodes:
- name: Controller
networks:
- External
- InternalApi
- Storage
- StorageMgmt
- Tenant
Check the default /usr/share/openstack-tripleo-heat-templates/roles_data.yaml file for further examples of syntax. Also check the example role snippets in /usr/share/openstack-tripleo-heat-templates/roles.
The following table provides a mapping of composable networks to custom standalone roles:
| Role | Networks Required |
|---|---|
| Ceph Storage Monitor |
|
| Ceph Storage OSD |
|
| Ceph Storage RadosGW |
|
| Cinder API |
|
| Compute |
|
| Controller |
|
| Database |
|
| Glance |
|
| Heat |
|
| Horizon |
|
| Ironic | None required. Uses the Provisioning/Control Plane network for API. |
| Keystone |
|
| Load Balancer |
|
| Manila |
|
| Message Bus |
|
| Networker |
|
| Neutron API |
|
| Nova |
|
| OpenDaylight |
|
| Redis |
|
| Sahara |
|
| Swift API |
|
| Swift Storage |
|
| Telemetry |
|
In previous versions, the *NetName parameters (e.g. InternalApiNetName) changed the names of the default networks. This is no longer supported. Use a custom composable network file. For more information, see "Using Composable Networks" in the Advanced Overcloud Customization guide.
5.5. Checking custom Puppet parameters
If you use the ExtraConfig interfaces for customizations of Puppet parameters, Puppet might report duplicate declaration errors during the upgrade. This is due to changes in the interfaces provided by the puppet modules themselves.
This procedure shows how to check for any custom ExtraConfig hieradata parameters in your environment files.
Procedure
Select an environment file and the check if it has an
ExtraConfigparameter:$ grep ExtraConfig ~/templates/custom-config.yaml
-
If the results show an
ExtraConfigparameter for any role (e.g.ControllerExtraConfig) in the chosen file, check the full parameter structure in that file. If the parameter contains any puppet Hierdata with a
SECTION/parametersyntax followed by avalue, it might have been been replaced with a parameter with an actual Puppet class. For example:parameter_defaults: ExtraConfig: neutron::config::dhcp_agent_config: 'DEFAULT/dnsmasq_local_resolv': value: 'true'Check the director’s Puppet modules to see if the parameter now exists within a Puppet class. For example:
$ grep dnsmasq_local_resolv
If so, change to the new interface.
The following are examples to demonstrate the change in syntax:
Example 1:
parameter_defaults: ExtraConfig: neutron::config::dhcp_agent_config: 'DEFAULT/dnsmasq_local_resolv': value: 'true'Changes to:
parameter_defaults: ExtraConfig: neutron::agents::dhcp::dnsmasq_local_resolv: trueExample 2:
parameter_defaults: ExtraConfig: ceilometer::config::ceilometer_config: 'oslo_messaging_rabbit/rabbit_qos_prefetch_count': value: '32'Changes to:
parameter_defaults: ExtraConfig: oslo::messaging::rabbit::rabbit_qos_prefetch_count: '32'
5.6. Converting network interface templates to the new structure
Previously the network interface structure used a OS::Heat::StructuredConfig resource to configure interfaces:
resources:
OsNetConfigImpl:
type: OS::Heat::StructuredConfig
properties:
group: os-apply-config
config:
os_net_config:
network_config:
[NETWORK INTERFACE CONFIGURATION HERE]
The templates now use a OS::Heat::SoftwareConfig resource for configuration:
resources:
OsNetConfigImpl:
type: OS::Heat::SoftwareConfig
properties:
group: script
config:
str_replace:
template:
get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh
params:
$network_config:
network_config:
[NETWORK INTERFACE CONFIGURATION HERE]
This configuration takes the interface configuration stored in the $network_config variable and injects it as a part of the run-os-net-config.sh script.
It is mandatory to update your network interface template to use this new structure and check your network interface templates still conforms to the syntax. Not doing so can cause failure during the fast forward upgrade process.
The director’s Heat template collection contains a script to help convert your templates to this new format. This script is located in /usr/share/openstack-tripleo-heat-templates/tools/yaml-nic-config-2-script.py. For an example of usage:
$ /usr/share/openstack-tripleo-heat-templates/tools/yaml-nic-config-2-script.py \
--script-dir /usr/share/openstack-tripleo-heat-templates/network/scripts \
[NIC TEMPLATE] [NIC TEMPLATE] ...Ensure your templates does not contain any commented lines when using this script. This can cause errors when parsing the old template structure.
For more information, see "Isolating Networks".
If you enabled High Availability for Compute Instances (Instance HA) in Red Hat OpenStack Platform 12 or earlier and you want to perform an upgrade to version 13 or later, you must manually disable Instance Ha first. For instructions, see Disabling Instance HA from previous versions.
5.7. Next Steps
The overcloud preparation stage is complete. You can now perform an upgrade of the overcloud to 13 using the steps in Chapter 6, Upgrading the Overcloud.