Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 4. Preparing for the Overcloud upgrade


This process prepares the overcloud for the upgrade process.

Prerequisites

  • You have upgraded the undercloud to the latest version.

4.1. Red Hat Subscription Manager (RHSM) composable service

The rhsm composable service provides a method to register overcloud nodes through Ansible. Each role in the default roles_data file contains a OS::TripleO::Services::Rhsm resource, which is disabled by default. To enable the service, register the resource to the rhsm composable service file:

resource_registry:
  OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/extraconfig/services/rhsm.yaml
Copy to Clipboard Toggle word wrap

The rhsm composable service accepts a RhsmVars parameter, which allows you to define multiple sub-parameters relevant to your registration. For example:

parameter_defaults:
  RhsmVars:
    rhsm_repos:
      - rhel-7-server-rpms
      - rhel-7-server-extras-rpms
      - rhel-7-server-rh-common-rpms
      - rhel-ha-for-rhel-7-server-rpms
      - rhel-7-server-openstack-14-rpms
      - rhel-7-server-rhceph-3-osd-rpms
      - rhel-7-server-rhceph-3-mon-rpms
      - rhel-7-server-rhceph-3-tools-rpms
    rhsm_username: "myusername"
    rhsm_password: "p@55w0rd!"
    rhsm_org_id: "1234567"
Copy to Clipboard Toggle word wrap

You can also use the RhsmVars parameter in combination with role-specific parameters (e.g. ControllerParameters) to provide flexibility when enabling specific repositories for different nodes types.

4.2. Switching to the rhsm composable service

The previous rhel-registration method runs a bash script to handle the overcloud registration. The scripts and environment files for this method are located in the core Heat template collection at /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration/.

Complete the following steps to switch from the rhel-registration method to the rhsm composable service.

Procedure

  1. Exclude the rhel-registration environment files from future deployments operations. In most cases, exclude the following files:

    • rhel-registration/environment-rhel-registration.yaml
    • rhel-registration/rhel-registration-resource-registry.yaml
  2. If you use a custom roles_data file, ensure that each role in your roles_data file contains the OS::TripleO::Services::Rhsm composable service. For example:

    - name: Controller
      description: |
        Controller role that has all the controller services loaded and handles
        Database, Messaging and Network functions.
      CountDefault: 1
      ...
      ServicesDefault:
        ...
        - OS::TripleO::Services::Rhsm
        ...
    Copy to Clipboard Toggle word wrap
  3. Add the environment file for rhsm composable service parameters to future deployment operations.

This method replaces the rhel-registration parameters with the rhsm service parameters and changes the Heat resource that enables the service from:

resource_registry:
  OS::TripleO::NodeExtraConfig: rhel-registration.yaml
Copy to Clipboard Toggle word wrap

To:

resource_registry:
  OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/extraconfig/services/rhsm.yaml
Copy to Clipboard Toggle word wrap

You can also include the /usr/share/openstack-tripleo-heat-templates/environments/rhsm.yaml environment file with your deployment to enable the service.

4.3. rhel-registration to rhsm mappings

Expand
rhel-registrationrhsm / RhsmVars

rhel_reg_method

rhsm_method

rhel_reg_org

rhsm_org_id

rhel_reg_pool_id

rhsm_pool_ids

rhel_reg_activation_key

rhsm_activation_key

rhel_reg_auto_attach

rhsm_autosubscribe

rhel_reg_sat_url

rhsm_satellite_url

rhel_reg_repos

rhsm_repos

rhel_reg_user

rhsm_username

rhel_reg_password

rhsm_password

rhel_reg_http_proxy_host

rhsm_rhsm_proxy_hostname

rhel_reg_http_proxy_port

rhsm_rhsm_proxy_port

rhel_reg_http_proxy_username

rhsm_rhsm_proxy_user

rhel_reg_http_proxy_password

rhsm_rhsm_proxy_password

4.4. Updating composable services

This section contains information about new and deprecated composable services.

  • If you use the default roles_data file, these services are included automatically.
  • If you use a custom roles_data file, add the new services and remove the deprecated services for each relevant role.

Controller Nodes

The following services have been deprecated for Controller nodes. Remove them from your Controller role.

Expand
ServiceReason

OS::TripleO::Services::CeilometerApi

OS::TripleO::Services::CeilometerCollector

OS::TripleO::Services::CeilometerExpirer

OpenStack Platform no longer includes Ceilometer services.

OS::TripleO::Services::RabbitMQ

This service has been substituted for two new services:

OS::TripleO::Services::OsloMessagingRpc

OS::TripleO::Services::OsloMessagingNotify

OS::TripleO::Services::NovaConsoleauth

This service is deprecated.

The following services are new for Controller nodes. Add them to your Controller role.

Expand
ServiceReason

OS::TripleO::Services::CinderBackendNVMeOF

Only required if enabling the Block Storage (cinder) NVMeOF backend,

OS::TripleO::Services::ContainerImagePrepare

Run the commands to automatically pull and prepare container images relevant to the services in your overcloud.

OS::TripleO::Services::DesignateApi

OS::TripleO::Services::DesignateCentral

OS::TripleO::Services::DesignateProducer

OS::TripleO::Services::DesignateWorker

OS::TripleO::Services::DesignateMDNS

OS::TripleO::Services::DesignateSink

Services for DNS-as-a-Service (designate).

OS::TripleO::Services::IronicInspector

Service for Bare Metal Introspection for the overcloud.

OS::TripleO::Services::IronicNeutronAgent

The networking agent for OpenStack Bare Metal (ironic).

OS::TripleO::Services::OsloMessagingRpc

OS::TripleO::Services::OsloMessagingNotify

Replacement services for the OS::TripleO::Services::RabbitMQ service.

OS::TripleO::Services::Xinetd

Service to remove xinetd, which is no longer used in a containerized overcloud.

Compute Nodes

The following services are new for Compute nodes. Add them to your Compute role.

Expand
ServiceReason

OS::TripleO::Services::NovaLibvirtGuests

Service to enable libvirt-guests on Compute nodes.

All Nodes

The following services are new for all nodes. Add them to all roles.

Expand
ServiceReason

OS::TripleO::Services::MetricsQdr

Service to enable Qpid Dispatch Router service for metrics and monitoring.

OS::TripleO::Services::Rhsm

Service to enable Ansible-based Red Hat Subscription Management.

4.5. Deprecated parameters

The following parameters are deprecated and have been replaced with role-specific parameters:

Expand
Old ParameterNew Parameter

controllerExtraConfig

ControllerExtraConfig

OvercloudControlFlavor

OvercloudControllerFlavor

controllerImage

ControllerImage

NovaImage

ComputeImage

NovaComputeExtraConfig

ComputeExtraConfig

NovaComputeServerMetadata

ComputeServerMetadata

NovaComputeSchedulerHints

ComputeSchedulerHints

NovaComputeIPs

ComputeIPs

SwiftStorageServerMetadata

ObjectStorageServerMetadata

SwiftStorageIPs

ObjectStorageIPs

SwiftStorageImage

ObjectStorageImage

OvercloudSwiftStorageFlavor

OvercloudObjectStorageFlavor

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'
  ...
Copy to Clipboard Toggle word wrap

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'
  ...
Copy to Clipboard Toggle word wrap

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'
  ...
Copy to Clipboard Toggle word wrap

4.6. 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 of an environment file. The following table maps deprecated options to their Heat template equivalents.

Expand
Table 4.1. Mapping deprecated CLI options to Heat template parameters
OptionDescriptionHeat Template Parameter

--control-scale

The number of Controller nodes to scale out

ControllerCount

--compute-scale

The number of Compute nodes to scale out

ComputeCount

--ceph-storage-scale

The number of Ceph Storage nodes to scale out

CephStorageCount

--block-storage-scale

The number of Cinder nodes to scale out

BlockStorageCount

--swift-storage-scale

The number of Swift nodes to scale out

ObjectStorageCount

--control-flavor

The flavor to use for Controller nodes

OvercloudControllerFlavor

--compute-flavor

The flavor to use for Compute nodes

OvercloudComputeFlavor

--ceph-storage-flavor

The flavor to use for Ceph Storage nodes

OvercloudCephStorageFlavor

--block-storage-flavor

The flavor to use for Cinder nodes

OvercloudBlockStorageFlavor

--swift-storage-flavor

The flavor to use for Swift storage nodes

OvercloudSwiftStorageFlavor

--neutron-flat-networks

Defines the flat networks to configure in neutron plugins. Defaults to "datacentre" to permit external network creation

NeutronFlatNetworks

--neutron-physical-bridge

An Open vSwitch bridge to create on each hypervisor. This defaults to "br-ex". Typically, this should not need to be changed

HypervisorNeutronPhysicalBridge

--neutron-bridge-mappings

The logical to physical bridge mappings to use. Defaults to mapping the external bridge on hosts (br-ex) to a physical name (datacentre). Use this for the default floating network

NeutronBridgeMappings

--neutron-public-interface

Defines the interface to bridge onto br-ex for network nodes

NeutronPublicInterface

--neutron-network-type

The tenant network type for Neutron

NeutronNetworkType

--neutron-tunnel-types

The tunnel types for the Neutron tenant network. To specify multiple values, use a comma separated string

NeutronTunnelTypes

--neutron-tunnel-id-ranges

Ranges of GRE tunnel IDs that you want to make available for tenant network allocation

NeutronTunnelIdRanges

--neutron-vni-ranges

Ranges of VXLAN VNI IDs that you want to make available for tenant network allocation

NeutronVniRanges

--neutron-network-vlan-ranges

The Neutron ML2 and Open vSwitch VLAN mapping range to support. Defaults to permitting any VLAN on the 'datacentre' physical network

NeutronNetworkVLANRanges

--neutron-mechanism-drivers

The mechanism drivers for the neutron tenant network. Defaults to "openvswitch". To specify multiple values, use a comma-separated string

NeutronMechanismDrivers

--neutron-disable-tunneling

Disables tunneling in case you aim to use a VLAN segmented network or flat network with Neutron

No parameter mapping.

--validation-errors-fatal

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

--ntp-server

Sets the NTP server to use to synchronize time

NtpServer

These parameters have been removed from Red Hat OpenStack Platform. It is recommended that you convert your CLI options to Heat parameters and add them to an environment file.

4.7. Composable networks

This version of Red Hat OpenStack Platform introduces a new feature for composable networks. If you use 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
Copy to Clipboard Toggle word wrap

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 contains a mapping of composable networks to custom standalone roles:

Expand
RoleNetworks Required

Ceph Storage Monitor

Storage, StorageMgmt

Ceph Storage OSD

Storage, StorageMgmt

Ceph Storage RadosGW

Storage, StorageMgmt

Cinder API

InternalApi

Compute

InternalApi, Tenant, Storage

Controller

External, InternalApi, Storage, StorageMgmt, Tenant

Database

InternalApi

Glance

InternalApi

Heat

InternalApi

Horizon

InternalApi

Ironic

None required. Uses the Provisioning/Control Plane network for API.

Keystone

InternalApi

Load Balancer

External, InternalApi, Storage, StorageMgmt, Tenant

Manila

InternalApi

Message Bus

InternalApi

Networker

InternalApi, Tenant

Neutron API

InternalApi

Nova

InternalApi

OpenDaylight

External, InternalApi, Tenant

Redis

InternalApi

Sahara

InternalApi

Swift API

Storage

Swift Storage

StorageMgmt

Telemetry

InternalApi

Important

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.

4.8. Updating network interface templates

A new feature in OpenStack Platform 14 allows you to specify routes for each network in the overcloud’s network_data file. To accommodate this new feature, the network interface templates now require parameters for the route list in each network. These parameters use the following format:

[network-name]InterfaceRoutes

Even if your overcloud does not use a routing list, you must still include these parameters for each network interface template.

  • If you use one of the default NIC template sets, these parameters are included automatically.
  • If you use a custom set of static NIC template, add these new parameters to the parameters of each role’s template.

Red Hat OpenStack Platform includes a script to automatically add the missing parameters to your template files.

Procedure

  1. Change to the director’s core template collection:

    $ cd /usr/share/openstack-tripleo-heat-templates
    Copy to Clipboard Toggle word wrap
  2. Run the merge-new-params-nic-config-script.py python script in the tools directory. For example, to update a custom Controller node NIC template, run the script with the following options:

    $ python ./tools/merge-new-params-nic-config-script.py --role-name Controller -t /home/stack/ccsosp-templates/custom-nics/controller.yaml
    Copy to Clipboard Toggle word wrap

    Note the following options used with this script:

    • --role-name defines the name of the role to use as a basis for the template update.
    • -t, --template defines the filename of the NIC template to update.
    • -n, --network-data defines the relative path to the network_data file. Use this option for custom network_data files. If omitted, the script uses the default file.
    • -r, --roles-data, defines the relative path to the roles_data.yaml file. Use this option for custom roles_data files. If omitted, the script uses the default file.
  3. The script saves a copy of the original template and adds a timestamp extension to the copy’s filename. To compare the differences between the original and updated template, run the following command:

    $ diff /home/stack/ccsosp-templates/custom-nics/controller.yaml.[TIMESTAMP] /home/stack/ccsosp-templates/custom-nics/controller.yaml
    Copy to Clipboard Toggle word wrap

    Replace [TIMESTAMP] with the timestamp on the original filename.

    The output displays the new route parameters for that role:

    StorageMgmtInterfaceRoutes:
      default: []
      description: >
        Routes for the storage_mgmt network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
        the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
      type: json
    TenantInterfaceRoutes:
      default: []
      description: >
        Routes for the tenant network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
        the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
      type: json
    ExternalInterfaceRoutes:
      default: []
      description: >
        Routes for the external network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
        the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
      type: json
    InternalApiInterfaceRoutes:
      default: []
      description: >
        Routes for the internal_api network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
        the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
      type: json
    ManagementInterfaceRoutes:
      default: []
      description: >
        Routes for the management network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
        the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
      type: json
    StorageInterfaceRoutes:
      default: []
      description: >
        Routes for the storage network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
        the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
      type: json
    Copy to Clipboard Toggle word wrap

For more information, see "Isolating Networks".

When upgrading to the containerized environment, use the CinderVolumeOptVolumes parameter to add docker volume mounts. This enables custom configuration files on the host to be made available to the cinder-volume service when it’s running in a container.

For example:

parameter_defaults:
  CinderVolumeOptVolumes:
    /etc/cinder/nfs_shares1:/etc/cinder/nfs_shares1
    /etc/cinder/nfs_shares2:/etc/cinder/nfs_shares2
Copy to Clipboard Toggle word wrap

4.10. Next Steps

The overcloud preparation stage is complete. You can now perform an upgrade of the overcloud to 14 using the steps in Chapter 5, Upgrading the Overcloud.

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat