オーバークラウドのアップグレードプロセスにより、重要なポイントで主要のサービスは無効化されます。このため、アップグレード中は、オーバークラウドサービスを使用して新規リソースを作成することはできません。この間には、オーバークラウドで実行中のワークロードはアクティブな状態のままなので、インスタンスはアップグレード中にも稼働し続けることになります。

アップグレード中にはユーザーがオーバークラウドのサービスにアクセスできないように、メンテナンスの時間帯を計画することが重要となります。

オーバークラウドのアップグレードプロセスでは、次のいずれかを行うことができます。

オーバークラウドのアップグレードプロセスを円滑にするには、全コンピュートノードをアップグレードする前に環境内にある個々のコンピュートノードのいくつかでアップグレードをテストすると役立ちます。これにより、アップグレード中に大きな問題が発生しなくなり、ワークロードのダウンタイムを最小限に抑えることができます。

アップグレードをテストするノードを選択するにあたっては、以下の推奨事項を参考にしてください。

「6章オーバークラウドのアップグレード」の手順では、全コンピュートノードでアップグレードを実行する前のアップグレードのテスト用のコンピュートノードの例として、compute-0 を使用しています。

次のステップでは、roles_data ファイルを更新して、新しいコンポーザブルサービスが環境内の適切なロールに追加されるようにします。既存の roles_data ファイルを手動で編集するには、以下に記載する OpenStack Platform 13 のロール向けの新規コンポーザブルサービスの一覧を使用してください。

Red Hat OpenStack Platform の今回のバージョンには、新たなコンポーザブルサービスが含まれています。自分独自のロールにカスタムの roles_data ファイルを使用する場合には、これらの新しい必須サービスを該当するロールに追加してください。

上記に加えて、特定のカスタムロール向けのサービスの最新のリストは、『Advanced Overcloud Customization』ガイドの「Service Architecture: Standalone Roles」の項を参照してください。

新規コンポーザブルサービスに加えて、OpenStack Platform 13 で非推奨になったサービスについても注意してください。

カスタムの roles_data ファイルを使用する場合には、該当するロールから以下のサービスを削除してください。

カスタムの roles_data ファイルを使用する場合には、各ロールから以下のサービスを削除してください。

上記に加えて、特定のカスタムロール向けのサービスの最新のリストは、『Advanced Overcloud Customization』ガイドの「Service Architecture: Standalone Roles」の項を参照してください。

以下のパラメーターは非推奨となり、ロール固有のパラメーターに置き換えられた点に注意してください。

カスタムの環境ファイルでこれらのパラメーターを更新します。

OpenStack Platform 環境で非推奨となったこれらのパラメーターがまだ必要な場合には、デフォルトの roles_data ファイルで使用することができます。ただし、カスタムの roles_data ファイルを使用していて、オーバークラウドにそれらの非推奨パラメーターが引き続き必要な場合には、roles_data ファイルを編集して各ロールに以下の設定を追加することによって、パラメーターへのアクセスを可能にすることができます。

- name: Controller
  uses_deprecated_params: True
  deprecated_param_extraconfig: 'controllerExtraConfig'
  deprecated_param_flavor: 'OvercloudControlFlavor'
  deprecated_param_image: 'controllerImage'
  ...

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

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

環境ファイルの parameter_defaults セクションに追加する Heat テンプレートのパラメーターの使用が優先されるため、一部のコマンドラインオプションは古いか非推奨となっています。以下の表では、非推奨となったパラメーターと、それに相当する Heat テンプレートのオプションを対照しています。

これらのパラメーターは Red Hat OpenStack Platform から削除されました。CLI オプションは Heat パラメーターに変換して、環境ファイルに追加することを推奨します。

本ガイドの後半には、 これらの新しいパラメーターを含む deprecated_cli_options.yaml 環境ファイルの例を記載しています。

Red Hat OpenStack Platform の今回のバージョンでは、コンポーザブルネットワーク向けの新機能が導入されています。カスタムの roles_data ファイルを使用する場合には、ファイルを編集して、コンポーザブルネットワークを各ロールに追加します。コントローラーノードの場合の例を以下に示します。

- name: Controller
  networks:
    - External
    - InternalApi
    - Storage
    - StorageMgmt
    - Tenant

その他の構文例については、デフォルトの /usr/share/openstack-tripleo-heat-templates/roles_data.yaml ファイルを確認してください。また、ロールの例のスニペットについては、/usr/share/openstack-tripleo-heat-templates/roles を確認してください。

カスタムのスタンドアロンロールとコンポーザブルネットワークの対応表を以下に示します。

コンテナー化されたサービスにアップグレードされたため、Ceph Storage ノードのインストールと更新の方法が変わりました。Ceph Storage の設定では、ceph-ansible パッケージ内の Playbook のセットを使用するようになりました。このパッケージはアンダークラウドにインストールします。

一部のストレージバックエンドは、設定フックではなく、独自のコンポーザブルサービスを使用するように変更されました。カスタムストレージバックエンドを使用する場合には、environments ディレクトリーで関連する環境ファイルに新規パラメーターとリソースが含まれているかどうかを確認してください。バックエンド用のカスタム環境ファイルを更新します。以下に例を示します。

NetApp Block Storage (cinder) バックエンドは、それぞれのバージョンに以下のリソースを使用していました。

今回の変更の結果、このバックエンドには新しい OS::TripleO::Services::CinderBackendNetApp リソースと、関連付けられたサービステンプレートを使用するようになりました。

オーバークラウドは、アップグレード中にアンダークラウドの OpenStack Object Storage (swift) のパブリック API にアクセスする必要があります。アンダークラウドで自己署名証明書を使用している場合には、アンダークラウドの認証局を各オーバークラウドノードに追加する必要があります。

Fast Forward Upgrade プロセスでは、リポジトリーの切り替えに新しい方法を採用しています。このため、デプロイメントのコマンドから以前の rhel-registration 環境ファイルを削除する必要があります。以下に例を示します。

Fast Forward Upgrade のプロセスでは、アップグレードの各段階でスクリプトを使用してリポジトリーを変更します。このスクリプトは、OS::TripleO::Services::TripleoPackages コンポーザブルサービス (puppet/services/tripleo-packages.yaml) の一部として含まれ、FastForwardCustomRepoScriptContent パラメーターを使用します。スクリプトの内容は以下のとおりです。

#!/bin/bash
set -e
case $1 in
  ocata)
    subscription-manager repos --disable=rhel-7-server-openstack-10-rpms
    subscription-manager repos --enable=rhel-7-server-openstack-11-rpms
    ;;
  pike)
    subscription-manager repos --disable=rhel-7-server-openstack-11-rpms
    subscription-manager repos --enable=rhel-7-server-openstack-12-rpms
    ;;
  queens)
    subscription-manager repos --disable=rhel-7-server-openstack-12-rpms
    subscription-manager repos --enable=rhel-7-server-openstack-13-rpms
    ;;
  *)
    echo "unknown release $1" >&2
    exit 1
esac

director は、スクリプトに対して、OpenStack Platform バージョンのアップストリームのコード名を渡します。

状況によっては、カスタムのスクリプトを使用する必要がある場合があります。以下に例を示します。

このような状況では、FastForwardCustomRepoScriptContent パラメーターを設定してカスタムスクリプトを追加します。

parameter_defaults:
  FastForwardCustomRepoScriptContent: |
    [INSERT UPGRADE SCRIPT HERE]

たとえば、以下のスクリプトは Satellite 6 アクティベーションキーのセットを使用して、リポジトリーを変更します。

parameter_defaults:
  FastForwardCustomRepoScriptContent: |
    set -e
    URL="satellite.example.com"
    case $1 in
      ocata)
        subscription-manager register --baseurl=https://$URL --force --activationkey=rhosp11 --org=Default_Organization
        ;;
      pike)
        subscription-manager register --baseurl=https://$URL --force --activationkey=rhosp12 --org=Default_Organization
        ;;
      queens)
        subscription-manager register --baseurl=https://$URL --force --activationkey=rhosp13 --org=Default_Organization
        ;;
      *)
        echo "unknown release $1" >&2
        exit 1
    esac

本ガイドの後半には、カスタムスクリプトを含む custom_repositories_script.yaml 環境ファイルを記載しています。

Puppet パラメーターのカスタマイズに ExtraConfig インターフェースを使用する場合には、アップグレード中に、Puppet が重複した宣言のエラーを報告する可能性があります。これは、Puppet モジュール自体によって提供されるインターフェースの変更が原因です。

この手順では、環境ファイル内のカスタムの ExtraConfig hieradata パラメーターを確認する方法を説明します。

以前は、ネットワークインターフェースの構造は OS::Heat::StructuredConfig リソースを使用してインターフェースを設定していました。

resources:
  OsNetConfigImpl:
    type: OS::Heat::StructuredConfig
    properties:
      group: os-apply-config
      config:
        os_net_config:
          network_config:
            [NETWORK INTERFACE CONFIGURATION HERE]

テンプレートでは、設定に OS::Heat::SoftwareConfig リソースを使用するようになりました。

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]

この設定は、$network_config 変数に保管されているインターフェースの設定を取得して、それを run-os-net-config.sh スクリプトの一部として挿入します。

director の Heat テンプレートコレクションには、お使いのテンプレートをこの新しい形式に変換するためのスクリプトが含まれています。このスクリプトは、/usr/share/openstack-tripleo-heat-templates/tools/yaml-nic-config-2-script.py にあります。使用方法の例を以下に示します。

$ /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] ...

詳しい情報は、「Isolating Networks」を参照してください。

オーバークラウドの準備段階が完了しました。次に「6章オーバークラウドのアップグレード」に記載の手順でオーバークラウドを 10 から 13 にアップグレードします。