リリースノート

Red Hat OpenStack Platform 16.0

Red Hat OpenStack Platform 16.0 リリースの詳細

OpenStack Documentation Team

Red Hat Customer Content Services

概要

本書は、Red Hat OpenStack Platform の本リリースにおける主要機能、機能拡張、既知の問題について記載します。

第1章 はじめに

1.1. 本リリースについて

Red Hat OpenStack Platform の本リリースは、OpenStack「Train」リリースをベースにしています。これには、Red Hat OpenStack Platform 固有の追加機能、既知の問題、および解決済みの問題が含まれます。

本書には、Red Hat OpenStack Platform 固有の変更のみを記載しています。OpenStack「Train」のリリースノートは、https://releases.openstack.org/train/index.html で参照してください。

Red Hat OpenStack Platform は、他の Red Hat 製品が提供するコンポーネントを使用します。これらのコンポーネントのサポートに関する詳しい情報は、「Red Hat OpenStack Platform のライフサイクル」を参照してください。

Red Hat OpenStack Platform を評価するには、「OpenStack を理解する」で登録してください。

注記

Red Hat Enterprise Linux High Availability Add-On は、Red Hat OpenStack Platform の各種ユースケースで利用することができます。このアドオンに関する詳細情報は、http://www.redhat.com/products/enterprise-linux-add-ons/high-availability/ を参照してください。また、Red Hat OpenStack Platform と併用できるパッケージバージョンに関する情報は、「Support Policies for RHEL High Availability Clusters - Cluster Stacks and Resource Managers」を参照してください。

1.2. 要件

Red Hat OpenStack Platform の本バージョンは、最新の Red Hat Enterprise Linux の完全サポート対象リリース (バージョン 8.1) 上で動作します。

Red Hat OpenStack Platform の Dashboard は、OpenStack のリソースやサービスを管理することができる Web ベースのインターフェースです。

本リリースの Dashboard は、以下の Web ブラウザーの最新安定版をサポートします。

  • Chrome
  • Mozilla Firefox
  • Mozilla Firefox ESR
  • Internet Explorer 11 以降 (互換モード が無効な場合)
注記

Red Hat OpenStack Platform をデプロイする前には、利用可能なデプロイメントメソッドの特性を考慮することが重要です。詳しくは、「Installing and Managing Red Hat OpenStack Platform」のアーティクルを参照してください。

1.3. デプロイメント制限事項

Red Hat OpenStack Platform のデプロイメント制限事項の一覧は、「Deployment Limits for Red Hat OpenStack Platform」のアーティクルを参照してください。

1.4. データベースサイズの管理

Red Hat OpenStack Platform 環境内における MariaDB データベースのサイズの維持管理に関する推奨プラクティスは、「Database Size Management for Red Hat Enterprise Linux OpenStack Platform」のアーティクルを参照してください。

1.5. 認定済みのドライバーとプラグイン

Red Hat OpenStack Platform の認定済みドライバー/プラグインの一覧は、「Component, Plug-In, and Driver Support in Red Hat OpenStack Platform」のアーティクルを参照してください。

1.6. 認定済みゲストオペレーティングシステム

Red Hat OpenStack Platform の認定済みゲストオペレーティングシステムの一覧は、「Red Hat OpenStack Platform および Red Hat Enterprise Virtualization で認定されたゲストオペレーティングシステム」のアーティクルを参照してください。

1.7. 認定製品カタログ

Red Hat の公式認定製品カタログについては、認定製品の一覧 を参照してください。

1.8. Bare Metal Provisioning 対応オペレーティングシステム

Bare Metal Provisioning (ironic) で Red Hat OpenStack Platform のベアメタルノードにインストールすることのできるゲストオペレーティングシステムの一覧は、「Supported Operating Systems Deployable With Bare Metal Provisioning (ironic)」のアーティクルを参照してください。

1.9. ハイパーバイザーのサポート

Red Hat OpenStack Platform の本リリースは、libvirt ドライバーとの組み合わせ (コンピュートノード上で KVM をハイパーバイザーで使用する) においてのみサポート対象となります。

Red Hat OpenStack Platform の本リリースは、Bare Metal Provisioning と共に動作します。

Bare Metal Provisioning は、Red Hat OpenStack Platform 7 (Kilo) リリースから完全にサポートされています。Bare Metal Provisioning により、一般的なテクノロジー (PXE や IPMI) を使用したベアメタルマシンのプロビジョニングが可能となり、多様なハードウェアに対応する一方で、ベンダー固有の機能を追加するためのプラグ可能なドライバーをサポートすることができます。

Red Hat は、非推奨の VMware の「direct-to-ESX」ハイパーバイザーや KVM 以外の libvirt ハイパーバイザーなど、他の Compute 仮想化ドライバーに対するサポートは提供していません。

1.10. コンテンツ配信ネットワーク (CDN) のリポジトリー

本項では、Red Hat OpenStack Platform 16.0 のデプロイに必要なリポジトリーについて説明します。

subscription-manager を使用して、コンテンツ配信ネットワーク (CDN) から Red Hat OpenStack Platform 16.0 をインストールすることができます。詳しい情報は、『director のインストールと使用方法』の「アンダークラウドの準備」を参照してください。

警告

Red Hat OpenStack Platform のリポジトリーは、Extra Packages for Enterprise Linux (EPEL) ソフトウェアリポジトリーで提供されているパッケージと競合する場合があります。EPEL ソフトウェアリポジトリーを有効にしているシステムでの Red Hat OpenStack Platform の使用はサポートされていません。

1.10.1. アンダークラウドのリポジトリー

アンダークラウドをインストールおよび設定するには、以下のリポジトリーを有効にします。

コアリポジトリー

以下の表には、アンダークラウドをインストールするためのコアリポジトリーをまとめています。

名前リポジトリー要件の説明

Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)

rhel-8-for-x86_64-baseos-rpms

x86_64 システム用ベースオペレーティングシステムのリポジトリー

Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)

rhel-8-for-x86_64-appstream-rpms

Red Hat OpenStack Platform の依存関係が含まれます。

Red Hat Enterprise Linux 8 for x86_64 - High Availability (RPMs)

rhel-8-for-x86_64-highavailability-rpms

Red Hat Enterprise Linux の高可用性ツール。コントローラーノードの高可用性に使用します。

Red Hat Ansible Engine 2.8 for RHEL 8 x86_64 (RPMs)

ansible-2.8-for-rhel-8-x86_64-rpms

Red Hat Enterprise Linux 用 Ansible エンジン。最新バージョンの Ansible を提供するために使用されます。

Red Hat Satellite Tools for RHEL 8 Server RPMs x86_64

satellite-tools-6.5-for-rhel-8-x86_64-rpms

Red Hat Satellite 6 でのホスト管理ツール

Red Hat OpenStack Platform 16.0 for RHEL 8 (RPMs)

openstack-16-for-rhel-8-x86_64-rpms

Red Hat OpenStack Platform のコアリポジトリー。Red Hat OpenStack Platform director のパッケージが含まれます。

Red Hat Fast Datapath for RHEL 8 (RPMS)

fast-datapath-for-rhel-8-x86_64-rpms

OpenStack Platform 用 Open vSwitch (OVS) パッケージを提供します。

IBM POWER 用リポジトリー

以下の表には、POWER PC アーキテクチャー上で OpenStack Platform を構築するためのリポジトリーをまとめています。コアリポジトリーの該当リポジトリーの代わりに、これらのリポジトリーを使用してください。

名前リポジトリー要件の説明

Red Hat Enterprise Linux for IBM Power, little endian - BaseOS (RPMs)

rhel-8-for-ppc64le-baseos-rpms

ppc64le システム用ベースオペレーティングシステムのリポジトリー

Red Hat Enterprise Linux 8 for IBM Power, little endian - AppStream (RPMs)

rhel-8-for-ppc64le-appstream-rpms

Red Hat OpenStack Platform の依存関係が含まれます。

Red Hat Enterprise Linux 8 for IBM Power, little endian - High Availability (RPMs)

rhel-8-for-ppc64le-highavailability-rpms

Red Hat Enterprise Linux の高可用性ツール。コントローラーノードの高可用性に使用します。

Red Hat Ansible Engine 2.8 for RHEL 8 IBM Power, little endian (RPMs)

ansible-2.8-for-rhel-8-ppc64le-rpms

Red Hat Enterprise Linux 用 Ansible エンジン。最新バージョンの Ansible を提供するために使用されます。

Red Hat OpenStack Platform 16.0 for RHEL 8 (RPMs)

openstack-16-for-rhel-8-ppc64le-rpms

ppc64le システム用 Red Hat OpenStack Platform のコアリポジトリー

1.10.2. オーバークラウドのリポジトリー

オーバークラウドをインストールおよび設定するには、以下のリポジトリーを有効にする必要があります。

コアリポジトリー

以下の表には、オーバークラウドをインストールするためのコアリポジトリーをまとめています。

名前リポジトリー要件の説明

Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)

rhel-8-for-x86_64-baseos-rpms

x86_64 システム用ベースオペレーティングシステムのリポジトリー

Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)

rhel-8-for-x86_64-appstream-rpms

Red Hat OpenStack Platform の依存関係が含まれます。

Red Hat Enterprise Linux 8 for x86_64 - High Availability (RPMs)

rhel-8-for-x86_64-highavailability-rpms

Red Hat Enterprise Linux の高可用性ツール。コントローラーノードの高可用性に使用します。

Red Hat Ansible Engine 2.8 for RHEL 8 x86_64 (RPMs)

ansible-2.8-for-rhel-8-x86_64-rpms

Red Hat Enterprise Linux 用 Ansible エンジン。最新バージョンの Ansible を提供するために使用されます。

Advanced Virtualization for RHEL 8 x86_64 (RPMs)

advanced-virt-for-rhel-8-x86_64-rpms

OpenStack Platform 用仮想化パッケージを提供します。

Red Hat Satellite Tools for RHEL 8 Server RPMs x86_64

satellite-tools-6.5-for-rhel-8-x86_64-rpms

Red Hat Satellite 6 でのホスト管理ツール

Red Hat OpenStack Platform 16.0 for RHEL 8 (RPMs)

openstack-16-for-rhel-8-x86_64-rpms

Red Hat OpenStack Platform のコアリポジトリー

Red Hat Fast Datapath for RHEL 8 (RPMS)

fast-datapath-for-rhel-8-x86_64-rpms

OpenStack Platform 用 Open vSwitch (OVS) パッケージを提供します。

リアルタイムリポジトリー

以下の表には、リアルタイムコンピュート (RTC) 機能用リポジトリーをまとめています。

名前リポジトリー要件の説明

Red Hat Enterprise Linux 8 for x86_64 - Real Time (RPMs)

rhel-8-for-x86_64-rt-rpms

リアルタイム KVM (RT-KVM) のリポジトリー。リアルタイムカーネルを有効化するためのパッケージが含まれています。このリポジトリーは、RT-KVM 対象の全コンピュートノードで有効化する必要があります。注記: このリポジトリーにアクセスするには、別途 Red Hat OpenStack Platform for Real Time SKU のサブスクリプションが必要です。

Red Hat Enterprise Linux 8 for x86_64 - Real Time for NFV (RPMs)

rhel-8-for-x86_64-nfv-rpms

NFV 向けのリアルタイム KVM (RT-KVM) のリポジトリー。リアルタイムカーネルを有効化するためのパッケージが含まれています。このリポジトリーは、RT-KVM 対象の全 NFV コンピュートノードで有効にする必要があります。注記: このリポジトリーにアクセスするには、別途 Red Hat OpenStack Platform for Real Time SKU のサブスクリプションが必要です。

IBM POWER 用リポジトリー

以下の表には、POWER PC アーキテクチャー上で OpenStack Platform を構築するためのリポジトリーをまとめています。コアリポジトリーの該当リポジトリーの代わりに、これらのリポジトリーを使用してください。

名前リポジトリー要件の説明

Red Hat Enterprise Linux for IBM Power, little endian - BaseOS (RPMs)

rhel-8-for-ppc64le-baseos-rpms

ppc64le システム用ベースオペレーティングシステムのリポジトリー

Red Hat Enterprise Linux 8 for IBM Power, little endian - AppStream (RPMs)

rhel-8-for-ppc64le-appstream-rpms

Red Hat OpenStack Platform の依存関係が含まれます。

Red Hat Enterprise Linux 8 for IBM Power, little endian - High Availability (RPMs)

rhel-8-for-ppc64le-highavailability-rpms

Red Hat Enterprise Linux の高可用性ツール。コントローラーノードの高可用性に使用します。

Red Hat Ansible Engine 2.8 for RHEL 8 IBM Power, little endian (RPMs)

ansible-2.8-for-rhel-8-ppc64le-rpms

Red Hat Enterprise Linux 用 Ansible エンジン。最新バージョンの Ansible を提供するために使用されます。

Red Hat OpenStack Platform 16.0 for RHEL 8 (RPMs)

openstack-16-for-rhel-8-ppc64le-rpms

ppc64le システム用 Red Hat OpenStack Platform のコアリポジトリー

1.11. 製品サポート

以下のリソースをご利用いただけます。

カスタマーポータル

Red Hat カスタマーポータルでは、Red Hat OpenStack Platform デプロイメントのプランニング、デプロイ、メンテナンスを支援するために、幅広いリソースを提供しています。カスタマーポータルから、以下のリソースを利用することができます。

  • 製品ドキュメント
  • ナレッジベースのアーティクルおよびソリューション
  • テクニカルブリーフ
  • サポートケース管理

カスタマーポータルには https://access.redhat.com/ からアクセスしてください。

メーリングリスト

Red Hat は、Red Hat OpenStack Platform ユーザーに適した公開メーリングリストを提供しています。

  • rhsa-announce メーリングリストは、Red Hat OpenStack Platform など、全 Red Hat 製品のセキュリティー関連の修正リリースに関する通知を提供します。

「RHSA-announce -- Security announcements for all Red Hat products and services.」でサブスクライブしてください。

第2章 最も重要な新機能

本項では、Red Hat OpenStack Platform の今回のリリースにおける最も重要な新機能の概要を説明します。

2.1. Compute

本項では、Compute サービスの最も重要な新機能について説明します。

Cells v2 を使用したマルチセルデプロイメント
OpenStack Compute は、デフォルトで Cells を活用するようになりました。大規模なデプロイメントで、それぞれ固有のコンピュートノードおよびデータベースを持つ複数のセルを使用する設定が可能です。グローバルサービスが配置およびフェイルセーフ操作を制御し、セル単位に分離することで、セキュリティーとプロセスの独立性が向上します。
CPU がピニングされたインスタンスとピニングされていないインスタンスの単一ホスト上での共存
CPU がピニングされたインスタンス (hw:cpu_policy=dedicated) とピニングされていないインスタンス (hw:cpu_policy=shared) を、同じホスト上でスケジューリングできるようになりました。ホストアグリゲートを使用して、これらのインスタンス種別が別個のホスト上で実行されるようにする必要がなくなりました。
SR-IOV (Single root I/O virtualization) を使用するインスタンスのライブマイグレーション
SR-IOV インターフェースが設定されたインスタンスのライブマイグレーションを実施できるようになりました。移行プロセスの一環として、インターフェースの接続解除/再接続が行われるため、直接モードの SR-IOV インターフェースの場合には、この操作により多少のネットワークダウンタイムが発生します。間接モードの SR-IOV インターフェースの場合には、問題とはなりません。
固定されたインスタンスのライブマイグレーション
この NUMA 対応ライブマイグレーション機能により、NUMA トポロジーが設定されたインスタンスのライブマイグレーションが可能になります。
帯域幅に対応したスケジューリング
Quality of Service (QoS) ポリシーを使用して、最小帯域幅の確保を要求するインスタンスを作成できるようになりました。Compute スケジューリングサービスは、インスタンス用に最小帯域幅確保の要求を満たすホストを選択します。

2.2. Networking

本項では、Networking サービスの最も重要な新機能について説明します。

Load-balancing サービス (Octavia) による ACL のサポート
Red Hat OpenStack Platform Load-balancing サービス (Octavia) は VIP アクセス制御リスト (ACL) をサポートし、リスナーへの着信トラフィックを、許可された送信元 IP アドレス (CIDR) のセットに制限するようになりました。
OVN 内部 API に対する TLS/SSL のサポート
Red Hat OpenStack Platform は、Transport Layer Security (TLS) を使用した OVN の内部 API トラフィックの暗号化をサポートするようになりました。
IPv6 上の OVN デプロイメント
Red Hat OpenStack Platform は、IPv6 ネットワークへの OVN デプロイをサポートするようになりました。

2.3. ストレージ

本項では、ストレージサービスの最も重要な新機能について説明します。

ボリュームクローン時の Block Storage サービスによる鍵の変更
今回のリリースで、Block Storage サービス (cinder) が暗号化されたボリュームをクローンする際に、自動的に暗号鍵を変更するようになりました。この機能により、同じ暗号鍵を 1 度しか使用しないことで、Red Hat OpenStack Platform のセキュリティーが向上します。
Image サービスによる暗号鍵削除の管理
今回のリリースで、Block Storage サービス (cinder) が暗号化されたボリュームを Image サービス (glance) にアップロードする際に、Key Management サービス (barbican) に暗号鍵を作成するようになりました。これにより、暗号鍵と保存されるイメージが 1 対 1 に対応します。暗号鍵を削除することで、Key Management サービスがリソースを無制限に消費するのを防ぐことができます。
director によるバックエンドアベイラビリティーゾーン設定のサポート
今回のリリースで、director が Block Storage バックエンドアベイラビリティーゾーン設定をサポートするようになりました。アベイラビリティーゾーンは、クラウドインスタンスおよびサービスをグループ化するためのプロバイダー固有の方法です。
Data Processing サービス (sahara) の廃止
Data Processing サービス (sahara) は Red Hat OpenStack Platform (RHOSP) 15 で 非推奨になり、RHOSP 16.0 で廃止されました。Red Hat では、RHOSP バージョン 13 および 15 で Data Processing サービスのサポートを継続して提供します。

2.4. Ceph Storage

本項では、Ceph Storage の最も重要な新機能について説明します。

Red Hat Ceph Storage のアップグレード
Red Hat Enterprise Linux 8 との互換性を維持するために、Red Hat OpenStack Platform 16.0 director は Red Hat Ceph Storage 4 をデプロイします。RHEL8 上で実行中の Red Hat OpenStack Platform 16.0 を使用して、RHEL7 上で実行中の既存の外部 Red Hat Ceph Storage 3 クラスターに接続することができます。

2.5. テクノロジープレビュー

本項では、Red Hat OpenStack Platform 16.0 のテクノロジープレビュー機能について説明します。

注記

テクノロジープレビューと記した機能のサポート範囲についての詳しい情報は、「テクノロジプレビュー機能のサポート範囲」を参照してください。

2.5.1. 新規テクノロジープレビュー

単一アンダークラウドからの複数オーバークラウドのデプロイおよび管理

本リリースでは、1 つのアンダークラウドから複数のオーバークラウドをデプロイする機能が追加されました。

  • 1 つのアンダークラウドに対して操作を行い、独立した複数のオーバークラウドを管理します。
  • アンダークラウドでコンテキストを切り替えて、さまざまなオーバークラウドに対する操作を行います。
  • 冗長な管理ノードを削減します。
アンダークラウドミニオン
今回のリリースでは、アンダークラウドミニオンをインストールすることができます。アンダークラウドミニオンにより、別個のホスト上に heat-engine サービスおよび ironic-conductor サービスが追加されます。これらの追加サービスは、アンダークラウドのオーケストレーションおよびプロビジョニング操作をサポートします。アンダークラウドの操作を複数ホスト間に分散することにより、オーバークラウドのデプロイメントにより多くのリソースを割り当てることができ、結果として大規模なデプロイメントをより迅速に実施することができます。
検証フレームワーク
  • Red Hat OpenStack Platform に含まれる検証フレームワークは、アンダークラウドおよびオーバークラウドの要件と機能を検証するのに役立ちます。フレームワークには、以下に示す 2 つの検証種別が含まれます。
  • openstack tripleo validator コマンドセットを使用して実行する、Ansible ベースの手動検証
  • デプロイメントプロセス中に実行される、自動検証
  • director の提供する新たなコマンドセットを使用して、検証を一覧表示し、アンダークラウドおよびオーバークラウドに対して検証を実行します。

    それらのコマンドを以下に示します。

    • openstack tripleo validator list
    • openstack tripleo validator run

      これらのコマンドは、openstack-tripleo-validations パッケージから提供される Ansible ベースのテストセットと共に機能します。この機能を有効にするには、undercloud.conf ファイルの enable_validations パラメーターを true に設定し、openstack undercloud install を実行します。

Block Storage サービスにアクティブ/アクティブ設定を作成する新たな director 機能

Red Hat OpenStack Platform director を使用して、Ceph RADOS Block Device (RBD) バックエンド上でのみ、アクティブ/アクティブ設定の Block Storage サービス (cinder) をデプロイできるようになりました。

新たな cinder-volume-active-active.yaml ファイルの CinderVolumeCluster パラメーターに値を割り当てて、アクティブ/アクティブ設定のクラスターの名前を定義します。CinderVolumeCluster はグローバル Block Storage パラメーターなので、クラスター化されたバックエンド (アクティブ/アクティブ) およびクラスター化されていないバックエンドを同じデプロイメントに含めることはできません。

cinder-volume-active-active.yaml ファイルにより、director は Pacemaker 以外の cinder-volume Orchestration サービステンプレートを使用し、etcd サービスが分散ロックマネージャー (DLM) として Red Hat OpenStack Platform デプロイメントに追加されます。

Block Storage サービスのアベイラビリティーゾーンを設定するための新たな director パラメーター
Red Hat OpenStack Platform director を使用して、Block Storage サービス (cinder) ボリュームバックエンドに、異なるアベイラビリティーゾーンを設定できるようになりました。director に新たなパラメーター CinderXXXAvailabilityZone が追加されました。なお、XXX はそれぞれのバックエンドに対応する値です。
Bare Metal サービス向けの新たな Redfish BIOS 管理インターフェース

Red Hat OpenStack Platform の Bare Metal サービス (ironic) に BIOS 管理インターフェースが追加され、デバイスの BIOS 設定を検査および変更できるようになりました。

Red Hat OpenStack Platform 16.0 の Bare Metal サービスは、Redfish API に準拠するデータセンターデバイスの BIOS 管理機能をサポートします。Bare Metal サービスは、Python ライブラリー Sushy を使用して Redfish の呼び出しを実装します。

複数 Ceph クラスターのデプロイ
クラスターごとに個別の heat スタックを使用して、director により (Ceph 実行専用のノードまたはハイパーコンバージドノードに) 複数の Ceph クラスターをデプロイすることができます。エッジサイトの場合には、同じノード上の Compute 機能および Ceph ストレージを使用するハイパーコンバージドインフラストラクチャー (HCI) スタックをデプロイすることができます。たとえば、専用のアベイラビリティーゾーンに、それぞれ HCI-01 および HCI-02 という名前の 2 つのエッジスタックをデプロイする場合があります。この場合には、それぞれのエッジスタックには専用の Ceph クラスターおよび Compute サービスが含まれます。
ソース種別をファイルに、アクセスモードを共有に設定した memoryBacking 要素を有効にする新たな Compute (nova) 設定の追加

新たな Compute (nova) パラメーター QemuMemoryBackingDir が利用できるようになりました。libvirt の memoryBacking 要素が source type="file" および access mode="shared" と設定された場合に、このパラメーターによりメモリーバッキングファイルを保存するディレクトリーが指定されます。

注記: memoryBacking 要素は、libvirt 4.0.0 および QEMU 2.6.0 以降でのみ利用可能です。

redfish API 用フェンシング
Pacemaker により、RedFish API 用のフェンシングが利用可能になりました。
director を使用した IPv6 へのベアメタルのデプロイ
IPv6 ノードおよびインフラストラクチャーがある場合には、IPv4 ではなく IPv6 を使用するようにアンダークラウドおよびプロビジョニングネットワークを設定することができます。これにより、director は IPv6 ノードに Red Hat OpenStack Platform をプロビジョニングおよびデプロイすることができます。
Compute (nova) サービスを使用しないベアメタルノードのプロビジョニング

Red Hat OpenStack Platform 16.0 では、デプロイメントのプロビジョニングおよびデプロイメントステージを、別個のステップに分離することができます。

  1. ベアメタルノードをプロビジョニングする。

    1. yaml 形式のノード定義ファイルを作成する。
    2. ノード定義ファイルを指定して、プロビジョニングコマンドを実行する。
  2. オーバークラウドをデプロイする。

    1. プロビジョニングコマンドにより生成される heat 環境ファイルを指定して、デプロイメントコマンドを実行する。

プロビジョニングプロセスにより、ノードがプロビジョニングされ、ノード数、予測可能なノード配置、カスタムイメージ、カスタム NIC 等のさまざまなノード仕様が含まれる heat 環境ファイルが生成されます。オーバークラウドをデプロイする際に、このファイルをデプロイメントコマンドに追加します。

networking-ansible のトランクポートのサポート
Red Hat OpenStack Platform 16.0 では、アクセスモードに加えてトランクモードでスイッチポートを使用して、複数の VLAN をスイッチポートに割り当てることができます。
networking-ansible の Arista のサポート
Red Hat OpenStack Platform 16.0 では、Arista Extensible Operating System (Arista EOS) スイッチと共に、ML2 networking-ansible 機能を設定することができます。
Redfish 仮想メディアブート
Redfish 仮想メディアブートを使用して、ノードの Baseboard Management Controller (BMC) にブートイメージを提供することができます。これにより、BMC はイメージを仮想ドライブのいずれかに挿入することができます。その後、ノードは仮想ドライブからイメージに存在するオペレーティングシステムにブートすることができます。

第3章 リリースの情報

本リリースノートには主に、今回リリースされた Red Hat OpenStack Platform のデプロイメント時に考慮すべきテクノロジープレビューの項目、推奨事項、既知の問題、非推奨になった機能について記載します。Red Hat OpenStack Platform の本リリースのサポートライフサイクル中にリリースされる更新についての情報は、各更新に対応したアドバイザリーの説明に記載されます。

3.1. Red Hat OpenStack Platform 16.0 一般提供

本リリースノートには主に、今回リリースされた Red Hat OpenStack Platform のデプロイメント時に考慮すべきテクノロジープレビューの項目、推奨事項、既知の問題、非推奨になった機能について記載します。

3.1.1. バグ修正

以下のバグは、Red Hat OpenStack Platform の本リリースで修正されています。

BZ#1716335

フラグ live_migration_wait_for_vif_plug がデフォルトで有効なので、Red Hat OpenStack Platform 16.0 では、OVN を有効にした状態でライブマイグレーションが成功するようになりました。

以前のリリースでは、OpenStack Networking (neutron) が vif_plugged の通知を送信するのをシステムが待機するため、ライブマイグレーションに失敗していました。

BZ#1758302
以前のリリースでは、oslo.util ライブラリーの正規表現が更新されておらず、より新しいバージョンのエミュレーター (qemu バージョン 4.1.0) からの出力フォーマットを認識できませんでした。Red Hat OpenStack 16.0 の今回のフィックスにより、正規表現が更新され、oslo.util.imageutils ライブラリーが正しく機能するようになりました。
BZ#1769868
以前のリリースでは、メッシュネットワークインフラストラクチャーがメッセージルーター QDR 用に誤って設定されていて、これにより、Service Telemetry Framework (STF) クライアント上の AMQP-1.0 メッセージバスが機能しませんでした。今回のフィックスにより、すべてのオーバークラウドノードの qdrouterd デーモンの設定が修正され、STF クライアントが正しく機能するようになりました。
BZ#1775246
インスタンスの再ビルド時に NUMATopologyFilter が無効になるようになりました。以前のリリースではこのフィルターが常に実行され、新たなイメージおよび既存フレーバーを使用する第 2 のインスタンス用にホストに十分な追加容量がある場合に限り、再ビルドは成功していました。これは適切ではない不必要な動作でした。

3.1.2. 機能拡張

Red Hat OpenStack Platform の今回のリリースでは、以下の機能拡張が提供されています。

BZ#1222414
今回の機能拡張により、NUMA トポロジーが設定されたインスタンスのライブマイグレーションがサポートされるようになりました。以前のリリースでは、この操作はデフォルトで無効でした。この操作は、回避措置として enable_numa_live_migration 設定オプションを使用して有効にすることができましたが、この設定オプションはデフォルトでは False に設定されていました。このようなインスタンスのライブマイグレーションを実施すると、ベースとなる NUMA ゲスト/ホスト間のマッピングやリソース使用状況をまったく更新せずに、インスタンスが移行先ホストに移動されるためです。新たな NUMA 対応ライブマイグレーション機能により、移行先ホストがインスタンスに適さない場合には、別の移行先ホストでライブマイグレーションが試みられます (要求に代替ホストが設定されている場合)。移行先ホストがインスタンスに適する場合には、新たなホストを反映するために NUMA ゲスト/ホスト間のマッピングが再計算され、そのリソース使用状況が更新されます。
BZ#1328124
Red Hat OpenStack Platform 16.0 director は、マルチコンピュートセルのデプロイメントをサポートするようになりました。今回の機能拡張により、お使いのクラウドのスケールアウトがより容易になります。それぞれの個々のセルはセルコントローラー上に専用のデータベースおよびメッセージキューを持ち、中央のコントロールプレーンの負荷を減らすためです。詳しい情報は、『Instances and Images』の「Scaling deployments with Compute cells」を参照してください。
BZ#1360970

今回の機能拡張により、SR-IOV ベースの neutron インターフェースが設定されたインスタンスのライブマイグレーションがサポートされるようになりました。neutron SR-IOV インターフェースは、直接モードと間接モードという 2 つのカテゴリーにグループ分けすることができます。直接モードの SR-IOV インターフェースは、ゲストに直接接続され、ゲスト OS に公開されます。間接モードの SR-IOV インターフェースは、ゲストと SR-IOV デバイス間に macvtap 等のソフトウェアインターフェースを持ちます。この機能により、間接モードの SR-IOV デバイスを持つインスタンスの透過的なライブマイグレーションが可能になります。ライブマイグレーション中にハードウェアの状態をコピーする一般的な方法がないため、直接モードの移行はゲストに対して透過的ではありません。直接モードのインターフェースの場合には、既存の休止/再開のワークフローを模擬します。たとえば、SR-IOV デバイスを使用する場合には、移行前に直接モードのインターフェースの接続を解除し、移行後に再度接続します。その結果、ライブマイグレーションの可能なインターフェースとのボンディングをゲスト内に作成しない限り、直接モードの SR-IOV ポートを持つインスタンスでは、移行中にネットワーク接続が失われます。

以前のリリースでは、SR-IOV ベースのネットワークインターフェースが設定されたインスタンスのライブマイグレーションを行うことはできませんでした。ホストのメンテナンス等にライブマイグレーションが頻繁に使用されているため、このことが問題となっていました。以前のリリースでは、コールドマイグレーションでインスタンスを移行する必要がありましたが、ゲストにダウンタイムが発生していました。

今回の機能拡張により、SR-IOV ベースのネットワークインターフェースが設定されたインスタンスのライブマイグレーションが可能になりました。

BZ#1463838
Red Hat OpenStack Platform 16.0 では、ネットワークインターフェースの作成時に、QoS の最小帯域幅ルールを指定できるようになりました。今回の機能拡張により、利用可能なネットワーク帯域幅として指定した値が、インスタンスに対して保証されるようになりました。現在、サポートされている操作は、サイズ変更およびコールドマイグレーションだけです。
BZ#1545700
Red Hat OpenStack Platform Block Storage サービス (cinder) は、ボリュームのクローン時に暗号鍵を自動的に変更するようになりました。Red Hat Ceph Storage を cinder バックエンドとして使用している場合には、現在、この機能はサポートされない点に注意してください。
BZ#1545855

Red Hat OpenStack Platform 16.0 では、ローカルレジストリーのイメージをプッシュ、一覧表示、削除、および表示 (メタデータの表示) できるようになりました。

  • イメージをリモートリポジトリーからメインのリポジトリーにプッシュするには、以下のコマンドを実行します。

    $ sudo openstack tripleo container image push docker.io/library/centos
  • リポジトリーの内容を一覧表示するには、以下のコマンドを実行します。

    $ openstack tripleo container image list
  • イメージを削除するには、以下のコマンドを実行します。

    $ sudo openstack tripleo container image delete
  • イメージのメタデータを表示するには、以下のコマンドを実行します。

    $ openstack tripleo container image show
BZ#1593057
アクションが意図せず実行されてしまう可能性を低減するために、今回の機能拡張により、オーバークラウドノードの削除には、アクションを実行する前にユーザーの確認が必要になりました。openstack overcloud node delete <node> コマンドには、アクションを実行する前に y/n の確認が必要です。この確認を省略するには、コマンドラインに --yes を追加します。
BZ#1601926
今回の更新で、OVSDB サーバーへの接続が完全に暗号化されたことから、全 OVN サービス間の通信が完全に暗号化されるようになりました。すべての OVN クライアント (ovn-controller、neutron-server、および ovn-metadata-agent) が、Mutual TLS 暗号化を使用して OVSDB サーバーに接続するようになりました。
BZ#1625244
Placement サービスが、Compute (nova) サービスから抽出されるようになりました。このサービスは director によってデプロイおよび管理され、アンダークラウド上およびオーバークラウドのコントローラーノード上で追加コンテナーとして動作します。
BZ#1628541
Red Hat OpenStack Platform 16.0 の Dashboard (horizon) に、ユーザーパスワードの変更用に新たなフォームが追加されました。ユーザーが期限切れのパスワードでサインオンしようとすると、このフォームが自動的に表示されます。
BZ#1649264
Red Hat OpenStack Platform Orchestration サービス (heat) に、新たなリソースタイプ OS::Glance::WebImage が追加されました。このリソースタイプは、Glance v2 API を使用して URL から Image サービス (glance) のイメージを作成するのに使用します。この新しいリソースタイプは、以前の OS::Glance::Image に置き換わるものです。
BZ#1653834
今回の機能拡張により、ブール値パラメーター NovaComputeEnableKsm が追加されました。このパラメーターにより、コンピュートノードの ksm サービスおよび ksmtuned サービスが有効になります。それぞれの Compute ロールに NovaComputeEnableKsm を設定することができます。デフォルトは False です。
BZ#1666973
Red Hat OpenStack Platform 16.0 では、ceph.conf の任意のセクションにカスタム Red Hat Ceph Storage 構成設定を追加できるようになりました。以前のリリースでは、カスタム設定は ceph.conf の [global] セクションにしか追加することができませんでした。
BZ#1689816

Red Hat OpenStack Platform 16.0 では、Orchestration サービス (heat) の新たなデプロイメントパラメーターを利用することができ、管理者はセルコントローラーで nova メタデータサービスを有効にすることができます。

parameter_defaults:
   NovaLocalMetadataPerCell: True

この新たなパラメーターにより、セルコンピュートの OVN メタデータエージェントからセルコントローラーがホストする nova メタデータ API サービスに、トラフィックが自動的に転送されます。

RHOSP トポロジーによっては、セルコントローラーでメタデータサービスを実行する機能により、中央のコントロールプレーンのトラフィックを減らすことができます。

BZ#1691025
Octavia API を使用して VIP アクセス制御リスト (ACL) を作成し、リスナーへの着信トラフィックを、許可されたソース IP アドレス (CIDR) のセットに制限できるようになりました。その他の着信トラフィックは、すべて拒否されます。詳細は、『ネットワークガイド』の「アクセス制御リストを使用したロードバランサーの保護」を参照してください。
BZ#1693372

今回の機能拡張により、以下のパラメーターを使用して、同じコンピュートノードで専用の (ピニングされた) インスタンスと共有の (ピニングされていない) インスタンスをスケジューリングできるようになりました。

  • NovaComputeCpuDedicatedSet: ピニングされたインスタンス CPU のプロセスをスケジューリングすることができる物理ホスト CPU 番号のコンマ区切りリストまたは範囲。非推奨となった NovaVcpuPinSet パラメーターに置き換わるものです。
  • NovaComputeCpuSharedSet: vCPU インベントリーを提供するのに使用される物理ホスト CPU 番号のコンマ区切りリストまたは範囲。ピニングされていないインスタンスをスケジューリングすることができるホスト CPU を定義し、共有エミュレータースレッドポリシー hw:emulator_threads_policy=share が設定されたインスタンスのエミュレータースレッドをオフロードするホスト CPU を定義します。注記: このオプションは従来から存在していましたが、その用途がこの機能により拡張されています。

    ホストアグリゲートを使用して、これらのインスタンス種別が別個のホスト上で実行されるようにする必要がなくなりました。また、[DEFAULT] reserved_host_cpus 設定オプションは不要になり、未設定にすることができます。

    アップグレードするには、以下を実行します。

    • これまでピニングされたインスタンス用に使用されていたホストの場合には、NovaVcpuPinSet の値を NovaComputeCpuDedicatedSet に変更する必要があります。
    • これまでピニングされていないインスタンス用に使用されていたホストの場合には、NovaVcpuPinSet の値を NovaComputeCpuSharedSet に変更する必要があります。
    • NovaVcpuPinSet に値が設定されていない場合には、実行中のインスタンスの種別に応じて、すべてのホストコアを NovaComputeCpuDedicatedSet または NovaComputeCpuSharedSet のどちらかに割り当てる必要があります。

      アップグレードが完了したら、同一のホストで両方のオプションの設定を始めることができます。ただし、そのためには、すべてのインスタンスをホストから移行する必要があります。ピニングされていないインスタンスのコアが NovaComputeCpuSharedSet の一覧に含まれていない場合、またはピニングされたインスタンスのコアが NovaComputeCpuDedicatedSet の一覧に含まれていない場合には、Compute サービスは起動することができないためです。

BZ#1696663
今回の更新で、ほとんどの neutron ネットワークに NUMA アフィニティーを設定できるようになりました。これは、vSwitch への外部接続を提供する NIC と同じホスト NUMA ノードにインスタンスが配置されるようにするのに役立ちます。--'provider:network_type' ('flat' または 'vlan') および 'provider:physical_network' (L2 ネットワーク) または --'provider:network_type' ('vxlan''gre'、または 'geneve' (L3 ネットワーク) を使用するネットワークに NUMA アフィニティーを設定することができます。
BZ#1700396
Red Hat OpenStack Platform 16.0 では、director を使用して Block Storage サービス (cinder) バックエンドタイプのアベイラビリティーゾーンを指定できるようになりました。
BZ#1767481
以前のリリースでは、Novajoin が IPA サーバーへの接続を失うと、直ちに再接続を試みていました。そのため、タイミングの問題が発生し、接続の再確立が妨げられる場合がありました。今回の更新により、retry_delay を使用して、IPA サーバーへの接続をリトライするのを待機する秒数を設定できるようになりました。これにより、タイミングの問題が発生する可能性が低減されると期待されます。
BZ#1775575
インスタンスレベルで PCI NUMA アフィニティーを設定できるようになりました。この機能は、SR-IOV ベースのネットワークインターフェースを持つインスタンスに NUMA アフィニティーを設定する際に必要です。以前のリリースでは、NUMA アフィニティーは PCI パススルーデバイスに対してホストレベルでしか設定することができませんでした。
BZ#1784806
Red Hat Openstack Platform 16.0 では、デプロイメント機能の拡張 (OVS-DPDK がデプロイされるコンピュートノードに必要な Orchestration サービス (heat) パラメーターを自動的に抽出する) により、OVS-DPDK の設定が容易になりました。Workflow サービス (mistral) の機能が拡張され、heat テンプレートおよびイントロスペクションデータを読み込み、heat パラメーター NovaComputeCpuDedicatedSet および NovaComputeCpuSharedSet に必要な値を自動的に抽出するようになりました。

3.1.3. テクノロジープレビュー

本項に記載する項目は、テクノロジープレビューとして提供しています。テクノロジープレビューステータスのスコープに関する詳細情報およびそれに伴うサポートへの影響については、「テクノロジプレビュー機能のサポート範囲」を参照してください。

BZ#1228474
Red Hat OpenStack Platform 16.0 では、Red Hat OpenStack Platform director のデプロイ後にシステムに存在する新規デフォルトロール reader に関して、テクノロジープレビュー機能が Identity サービス (keystone) に追加されています。reader ロールを持つユーザーは、ボリュームの作成など、読み取り専用ではない追加のタスクを実施することができます。このロールは、cinder、neutron、nova 等の他のサービスには実装されていません。テクノロジープレビューであるこの機能は、まだ開発段階にあり、実稼働環境で使用すべきではありません。
BZ#1288155

複数のルーティングテーブルを定義し、ルートを特定のテーブルに割り当てる機能は、Red Hat OpenStack Platform 16.0 のテクノロジープレビューです。

複数のリンクを持つホストでは、ポリシーベースのルーティングはルーティングテーブルを使用し、送信元のアドレスに応じて特定のインターフェース経由でトラフィックを送信することができます。

また、以下の例に示すように、インターフェースごとにルーティングルールを定義することもできます。

network_config:
  -
    type: route_table
    name: custom
    table_id: 200
  -
    type: interface
    name: em1
    use_dhcp: false
    addresses:
    -
      ip_netmask: 192.0.2.1/24
    routes:
      -
        ip_netmask: 10.1.3.0/24
        next_hop: 192.0.2.5
        table: 200  # Use table ID or table name
    rules:
      - rule: "iif em1 table 200"
        comment: "Route incoming traffic to em1 with table 200"
      - rule: "from 192.0.2.0/24 table 200"
        comment: "Route all traffic from 192.0.2.0/24 with table 200"
      - rule: "add blackhole from 172.19.40.0/24 table 200"
      - rule: "add unreachable iif em1 from 192.168.1.0/24"
BZ#1375207
以前のリリースでは、Red Hat Ceph Storage を Block Storage サービス (cinder) ボリュームとバックアップ両方のバックエンドとして使用している場合には、初回のフルバックアップを実行した後は、フルバックアップを試みても警告が表示されることなく差分バックアップが実行されていました。Red Hat OpenStack Platform 16.0 のテクノロジープレビュー機能により、この問題が修正されました。
BZ#1459187
Red Hat OpenStack Platform 16.0 では、IPv6 プロビジョニングネットワークを通じてオーバークラウドをデプロイすることができるように、Bare Metal Provisioning サービス (ironic) にテクノロジープレビュー機能が追加されています。詳しくは、『ベアメタルプロビジョニング』の「カスタムの IPv6 プロビジョニングネットワークの設定」を参照してください。
BZ#1474394
Red Hat OpenStack Platform 16.0 では、BMaaS (Bare Metal as-a-Service) テナント向けに IPv6 プロビジョニングネットワークを通じたデプロイをサポートするために、Bare Metal Provisioning サービス (ironic) にテクノロジープレビュー機能が追加されています。
BZ#1575079
Red Hat OpenStack Platform 16.0 では、IPv6 が CephFS NFS ドライバーで機能するように、Shared File Systems サービス (manila) にテクノロジープレビュー機能が追加されています。
BZ#1593828

Red Hat OpenStack Platform 16.0 では、Bare Metal Provisioning サービス (ironic) を使用して仮想メディアからベアメタルマシンを起動することができるように、テクノロジープレビュー機能が追加されています。

マシンのベースボード管理コントローラー (BMC) が Redfish ハードウェア管理プロトコルおよび仮想メディアサービスをサポートする場合には、ブート可能イメージをプルしてそれをノード上の仮想ドライブに「挿入」するように、ironic は BMC に指示することができます。次に、ノードはその仮想ドライブからイメージ上のオペレーティングシステムにブートすることができます。Redfish API に基づく Ironic ハードウェア種別は、(ユーザー) イメージのデプロイ、レスキュー (制限あり)、および仮想メディアを通じたブートをサポートします。

仮想メディアを通じたブートの主要なメリットは、PXE ブートプロトコルスイートのセキュアではない信頼性に欠ける TFTP イメージ転送フェーズが、セキュアな HTTP トランスポートに置き換えられることです。

BZ#1600967

Red Hat OpenStack Platform 16.0 では、テクノロジープレビュー機能の Workflow サービス (mistral) タスクにより、以下の手順に従ってパスワードのローテーションを実装することができます。

rotate-password ワークフローを実行し、新しいパスワードを生成してそれをプラン環境に保管する。

オーバークラウドを再デプロイする。

パスワードの変更後にパスワードを取得することもできます。

パスワードのローテーションを実装するには、以下の手順に従います。

注記

ワークフロータスクにより、デフォルトのパスワードが変更されます。このタスクは、ユーザー定義の環境ファイルで指定されたパスワードを変更しません。

  1. 新しいワークフロータスクを実行してパスワードを再生成します。

    $ source ./stackrc
    $ openstack workflow execution create tripleo.plan_management.v1.rotate_passwords '{"container": "overcloud"}'

    このコマンドにより、すべてのパスワードに対する新規パスワードが生成されます。ただし、BarbicanSimpleCryptoKek、KeystoneFernet*、および KeystoneCredential* は除きます。これらのパスワードをローテーションするための、特別な手順があります。

    ローテーションする特定のパスワードを指定することもできます。以下のコマンドでは、指定したパスワードだけがローテーションされます。

    $ openstack workflow execution create tripleo.plan_management.v1.rotate_passwords '{"container": "overcloud", "password_list": ["BarbicanPassword", "SaharaPassword", "ManilaPassword"]}'
  2. オーバークラウドを再デプロイします。

    $ ./overcloud-deploy.sh

    パスワード (新たに生成したパスワードを含む) を取得するには、以下の手順に従います。

  3. 次のコマンドを実行します。

    $ openstack workflow execution create tripleo.plan_management.v1.get_passwords '{"container": "overcloud"}'

    以下のようなコマンド出力が表示されるはずです。

    +--------------------+---------------------------------------------+
    | Field              | Value                                       |
    +--------------------+---------------------------------------------+
    | ID                 | edcf9103-e1a8-42f9-85c1-e505c055e0ed        |
    | Workflow ID        | 8aa2ac9b-22ee-4e7d-8240-877237ef0d0a        |
    | Workflow name      | tripleo.plan_management.v1.rotate_passwords |
    | Workflow namespace |                                             |
    | Description        |                                             |
    | Task Execution ID  | <none>                                      |
    | Root Execution ID  | <none>                                      |
    | State              | RUNNING                                     |
    | State info         | None                                        |
    | Created at         | 2020-01-22 15:47:57                         |
    | Updated at         | 2020-01-22 15:47:57                         |
    +--------------------+---------------------------------------------+

    上記の出力例では、State の値は RUNNING です。最終的には、State には SUCCESS と表示されるはずです。

  4. State の値を再度確認します。

    $ openstack workflow execution show edcf9103-e1a8-42f9-85c1-e505c055e0ed
    +--------------------+---------------------------------------------+
    | Field              | Value                                       |
    +--------------------+---------------------------------------------+
    | ID                 | edcf9103-e1a8-42f9-85c1-e505c055e0ed        |
    | Workflow ID        | 8aa2ac9b-22ee-4e7d-8240-877237ef0d0a        |
    | Workflow name      | tripleo.plan_management.v1.rotate_passwords |
    | Workflow namespace |                                             |
    | Description        |                                             |
    | Task Execution ID  | <none>                                      |
    | Root Execution ID  | <none>                                      |
    | State              | SUCCESS                                     |
    | State info         | None                                        |
    | Created at         | 2020-01-22 15:47:57                         |
    | Updated at         | 2020-01-22 15:48:39                         |
    +--------------------+---------------------------------------------+
  5. State の値が SUCCESS であれば、パスワードを取得することができます。

    $ openstack workflow execution output show edcf9103-e1a8-42f9-85c1-e505c055e0ed

    以下のような出力が表示されるはずです。

    {
        "status": "SUCCESS",
        "message": {
            "AdminPassword": "FSn0sS1aAHp8YK2fU5niM3rxu",
            "AdminToken": "dTP0Wdy7DtblG80M54r4a2yoC",
            "AodhPassword": "fB5NQdRe37BaBVEWDHVuj4etk",
            "BarbicanPassword": "rn7yk7KPafKw2PWN71MvXpnBt",
            "BarbicanSimpleCryptoKek": "lrC3sGlV7-D7-V_PI4vbDfF1Ujm5OjnAVFcnihOpbCg=",
            "CeilometerMeteringSecret": "DQ69HdlJobhnGWoBC0jM3drPF",
            "CeilometerPassword": "qI6xOpofuiXZnG95iUe8Oxv5d",
            "CephAdminKey": "AQDGVPpdAAAAABAAZMP56/VY+zCVcDT81+TOjg==",
            "CephClientKey": "AQDGVPpdAAAAABAAanYtA0ggpcoCbS1nLeDN7w==",
            "CephClusterFSID": "141a5ede-21b4-11ea-8132-52540031f76b",
            "CephDashboardAdminPassword": "AQDGVPpdAAAAABAAKhsx630YKDhQrocS4o4KzA==",
            "CephGrafanaAdminPassword": "AQDGVPpdAAAAABAAKBojG+CO72B0TdBRR0paEg==",
            "CephManilaClientKey": "AQDGVPpdAAAAABAAA1TVHrTVCC8xQ4skG4+d5A=="
        }
    }
BZ#1621701
Red Hat OpenStack Platform 16.0 では、Arista Extensible Operating System (Arista EOS) スイッチと共に ML2 networking-ansible 機能を設定することができるように、OpenStack Bare Metal サービス (ironic) にテクノロジープレビュー機能が追加されています。詳しくは、『ベアメタルプロビジョニング』の「networking-ansible ML2 機能の有効化」を参照してください。
BZ#1622233
Red Hat OpenStack Platform 16.0 では、スイッチポートを変更してトランクモードに設定し、複数の VLAN をポートに割り当てることができるように、テクノロジープレビュー機能が追加されています。
BZ#1623152

Red Hat OpenStack Platform 16.0 では、rsyslog の変更に対応することができるように、Orchestration サービス (heat) にテクノロジープレビュー機能が追加されています。

  • rsyslog は、fluentd インストールと機能的に等価となるように、コンテナーログを収集して転送するよう設定されます。
  • 管理者は、fluentd と同じように rsyslog のログ転送を設定することができます。
BZ#1628061

Red Hat OpenStack Platform 16.0 では、director を使用してサービステンプレートにインフライトの自動検証を含めることができます。この機能は RHOSP 16.0 ではテクノロジープレビューです。追加設定は、確認するステップの最後、または次のステップの最初に挿入することができます。

以下の例では、デプロイメント後の rabbitmq サービスが動作していることを確認する検証が実行されます。

deploy_steps_tasks:
  # rabbitmq container is supposed to be started during step 1
  # so we want to ensure it's running during step 2
  - name: validate rabbitmq state
    when: step|int == 2
    tags:
      - opendev-validation
      - opendev-validation-rabbitmq
    wait_for_connection:
      host: {get_param: [ServiceNetMap, RabbitmqNetwork]}
      port: 5672
      delay: 10

heat では、openstack-tripleo-validations ロールの既存の検証を含めることができます。

deploy_steps_tasks:
  - name: some validation
    when: step|int == 2
    tags:
      - opendev-validation
      - opendev-validation-rabbitmq
    include_role:
      role: rabbitmq-limits
    # We can pass vars to included role, in this example
    # we override the default min_fd_limit value:
    vars:
      min_fd_limit: 32768

rabbitmq-limits role ロールの定義は、ここ で確認することができます。

既存のサービスヘルスチェックを使用する例を以下に示します。

deploy_steps_tasks:
  # rabbitmq container is supposed to be started during step 1
  # so we want to ensure it's running during step 2
  - name: validate rabbitmq state
    when: step|int == 2
    tags:
      - opendev-validation
      - opendev-validation-rabbitmq
    command: >
      podman exec rabbitmq /openstack/healthcheck
BZ#1699449
Red Hat OpenStack Platform director により、テクノロジープレビュー機能として Redfish API のフェンスエージェントである fence_redfish を利用できるようになりました。
BZ#1700083
Red Hat OpenStack Platform 16.0 では、Intel Speed Select プロセッサーと連携することができるように、Bare Metal Provisioning サービス (ironic) にテクノロジープレビュー機能が追加されています。
BZ#1703956
Red Hat OpenStack Platform 16.0 では、テクノロジープレビューとして Load-balancing サービス (octavia) が UDP プロトコルをサポートするようになりました。
BZ#1706896
Red Hat OpenStack Platform 16.0 では、イメージを事前にキャッシュするテクノロジープレビューが Image サービス (glance) に追加されています。これにより、オペレーターはインスタンスをブートする前にキャッシュを温めることができます。
BZ#1710089
director に overcloud undercloud minion install コマンドが追加されました。このコマンドを使用すると、追加のホストを設定してアンダークラウドサービスを強化することができます。
BZ#1710092
director により、追加のホストをデプロイできるようになりました。このホストを使用して、デプロイメントに関する操作用にさらに heat-engine リソースを追加することができます。
BZ#1710093
Red Hat OpenStack Platform director により、追加のノードをデプロイできるようになりました。このノードを使用して、デプロイメント中のシステムプロビジョニング用に、さらに Bare Metal Provisioning コンダクターサービスリソースを追加することができます。
BZ#1710634

Red Hat OpenStack Platform 16.0 では、Orchestration サービス (heat) にテクノロジープレビュー機能が追加されています。新たに追加されたパラメーター NovaSchedulerQueryImageType により、イメージの種別に応じて Compute サービス (nova) の配置およびスケジューラーコンポーネントクエリーの配置が制御されます (scheduler/query_placement_for_image_type_support)。

true に設定すると (デフォルト)、NovaSchedulerQueryImageType はブート要求で使用されるイメージのディスク形式をサポートしないコンピュートノードを除外します。

たとえば、libvirt ドライバーはエフェメラルバックエンドに Red Hat Ceph Storage を使用し、qcow2 イメージをサポートしません (非常にコストのかかる変換ステップを経ない場合)。この場合には、NovaSchedulerQueryImageType を有効にすると、スケジューラーは Red Hat Ceph Storage を使用するコンピュートノードには qcow2 イメージをブートする要求を送信しません。

BZ#1749483

TCP、UDP、または Floating IP アドレスのその他のプロトコルポートから、TCP、UDP、または neutron ポートの Fixed IP アドレスのいずれかに関連付けられたその他のプロトコルポートに、トラフィックを転送できるようになりました。転送されたトラフィックは、neutron API に対する機能拡張および OpenStack Networking プラグインにより管理されます。Floating IP アドレスには、複数の転送定義を設定することができます。ただし、すでに OpenStack Networking ポートと関連のある IP アドレスのトラフィックを転送することはできません。転送することができるのは、ネットワーク上の集中ルーター (レガシー、HA、および DVR+HA) によって管理される Floating IP アドレスのトラフィックだけです。

Floating IP アドレスのポートのトラフィックを転送するには、以下の OpenStack Networking プラグインコマンドを使用します。

openstack floating ip port forwarding create
--internal-ip-address <internal-ip-address>
--port <port>
--internal-protocol-port <port-number>
--external-protocol-port <port-number>
--protocol <protocol>
<floating-ip>

--internal-ip-address <internal-ip-address>: 転送されたトラフィックを受信する neutron ポートの内部 Fixed IP アドレス (IPv4)。

--port <port>: 転送されたトラフィックを受信する neutron ポートの名前または ID。

--internal-protocol-port <port-number>: 転送されたトラフィックを受信する neutron ポート Fixed IP アドレスのプロトコルポート番号。

--external-protocol-port <port-number> トラフィックの転送元である Floating IP アドレスのポートのプロトコルポート番号。

--protocol <protocol>: Floating IP アドレスのポートが使用するプロトコル (例: TCP、UDP)。

<floating-ip>: トラフィックの転送元であるポートの Floating IP (IP アドレスまたは ID)。

以下に例を示します。

openstack floating ip port forwarding create \
    --internal-ip-address 192.168.1.2 \
    --port f7a08fe4-e79e-4b67-bbb8-a5002455a493 \
    --internal-protocol-port 18343 \
    --external-protocol-port 8343 \
    --protocol tcp \
    10.0.0.100

3.1.4. リリースノート

本項では、Red Hat OpenStack Platform の注目すべき変更点や推奨プラクティスなど、今回のリリースに関する重要な情報を記載しています。お使いのデプロイメントに最大限の効果をもたらすために、以下の情報を考慮する必要があります。

BZ#1481814
以前のリリースでは、暗号化された Block Storage サービス (cinder) ボリュームイメージが削除されても、対応する鍵は削除されませんでした。

Red Hat OpenStack Platform 16.0 では、この問題が解決されています。Image サービスが cinder ボリュームイメージを削除すると、そのイメージの鍵も削除されます。

BZ#1783044
Red Hat Ceph Storage バージョン 4 の一般提供により、rhceph-4-tools-for-rhel-8-x86_64-rpms リポジトリーから ceph-ansible をインストールできるようになりました。

3.1.5. 既知の問題

現時点における Red Hat OpenStack Platform の既知の問題は以下のとおりです。

BZ#1574431
Block Storage service (cinder) には、クォータコマンドが予想通りに機能しないという既知の問題があります。cinder CLI は、有効なプロジェクト ID かどうかを確認せずに、ユーザーがクォータエントリーを作成するのを許可します。有効なプロジェクト ID を指定せずに CLI により作成されるクォータエントリーは、無効なデータが含まれるダミーレコードです。この問題が修正されるまで、CLI ユーザーはクォータエントリーの作成時に必ず有効なプロジェクト ID を指定し、cinder にダミーレコードがないか監視する必要があります。
BZ#1647005

nova-compute ironic ドライバーは、BM ノードのクリーンアップ中にノードの更新を試みます。クリーンアップには約 5 分間かかりますが、nova-compute は約 2 分間しかノードの更新を試みません。タイムアウト後、nova-compute は停止し、nova インスタンスを ERROR 状態にします。

回避策は、nova-compute サービスに以下の設定オプションを定義することです。

[ironic]
api_max_retries = 180

その結果、nova-compute はより長時間 BM ノードの更新を試み続け、最終的に成功します。

BZ#1734301
現時点では、メンバーからデータを取得する際に、OVN ロードバランサーは新しい接続を開始しません。ロードバランサーは送信先アドレスおよびポートを変更し、リクエストのパケットをメンバーに送信します。そのため、IPv4 ロードバランサーアドレスを使用している間、IPv6 メンバーを定義することができません (その逆も同様です)。現在、この問題に対する回避策はありません。
BZ#1769880

ML2/OVS から OVN への移行に失敗するという既知の問題があります。この失敗は、Red Hat OpenStack Platform director の新たな保護メカニズム (メカニズムドライバーを変更している間はアップグレードを拒否する) によるものです。

回避策は、『Networking with Open Virtual Network』の「Preparing for the migration」を参照してください。

BZ#1779221

Linux ブリッジ ML2 ドライバーおよびエージェントを使用する Red Hat OpenStack Platform デプロイメントは、アドレス解決プロトコル (ARP) スプーフィングに対して保護されません。Red Hat Enterprise Linux 8 に含まれる Ethernet bridge frame table 管理 (ebtables) のバージョンは、Linux ブリッジ ML2 ドライバーと互換性がありません。

Linux ブリッジ ML2 ドライバーおよびエージェントは Red Hat OpenStack Platform 11 で非推奨になりました。したがって、使用すべきではありません。

Red Hat では、その代わりに ML2 Open Virtual Network (OVN) ドライバーおよびサービス (Red Hat OpenStack Platform director によりデプロイされるデフォルト) の使用を推奨します。

BZ#1789822

オーバークラウドコントローラーを置き換えると、swift のリングがノード間で一貫性を失う可能性があります。これにより、Object Storage サービスの可用性が低下する場合があります。その場合には、SSH を使用して既存していたコントローラーノードにログインして更新されたリングをデプロイし、Object Storage コンテナーを再起動します。

(undercloud) [stack@undercloud-0 ~]$ source stackrc
(undercloud) [stack@undercloud-0 ~]$ nova list
...
| 3fab687e-99c2-4e66-805f-3106fb41d868 | controller-1 | ACTIVE | -          | Running     | ctlplane=192.168.24.17 |
| a87276ea-8682-4f27-9426-6b272955b486 | controller-2 | ACTIVE | -          | Running     | ctlplane=192.168.24.38 |
| a000b156-9adc-4d37-8169-c1af7800788b | controller-3 | ACTIVE | -          | Running     | ctlplane=192.168.24.35 |
...

(undercloud) [stack@undercloud-0 ~]$ for ip in 192.168.24.17 192.168.24.38 192.168.24.35; do ssh $ip 'sudo podman restart swift_copy_rings ; sudo podman restart $(sudo podman ps -a --format="{{.Names}}" --filter="name=swift_*")'; done
BZ#1790467

Red Hat OpenStack Platform 16.0 には、OpenStack インスタンスの設定に必要なメタデータ情報が利用できず、ネットワークに接続されていない状態でインスタンスが起動するという既知の問題があります。

順序付けの問題が原因で、ovn_metadata_agent の haproxy ラッパーが更新されません。

クラウドオペレーターが実施することのできる回避策は、更新後に以下の Ansible コマンドを実行して、選択したノードの ovn_metadata_agent を再起動することです。これにより、ovn_metadata_agent は更新バージョンの haproxy ラッパースクリプトを使用するようになります。

`ansible -b <nodes> -i /usr/bin/tripleo-ansible-inventory -m shell -a "status=`sudo systemctl is-active tripleo_ovn_metadata_agent`; if test \"$status\" == \"active\"; then sudo systemctl restart tripleo_ovn_metadata_agent; echo restarted; fi"`

上記の Ansible コマンドで、nodes を単一のノード (例: compute-0)、すべてのコンピュート (例: compute*)、または「all」に設定します。

ovn_metadata_agent はコンピュートノードで最も一般的に使用されているので、以下の Ansible コマンドにより、クラウド内のすべてのコンピュートノードのエージェントが再起動されます。

`ansible -b compute* -i /usr/bin/tripleo-ansible-inventory -m shell -a "status=`sudo systemctl is-active tripleo_ovn_metadata_agent`; if test \"$status\" == \"active\"; then sudo systemctl restart tripleo_ovn_metadata_agent; echo restarted; fi"`

ovn_metadata_agent サービスを再起動すると、更新された haproxy ラッパースクリプトが使用され、仮想マシンの起動時にメタデータを提供することができます。すでに実行中の問題のある仮想マシンは、回避策の適用後に再起動すると、通常どおりに動作するはずです。

BZ#1793166

Red Hat OpenStack 16.0 には、同時マルチスレッド (SMT) 制御が無効でない限り、IBM POWER8 システム上では KVM ゲストが起動しないという既知の問題があります。SMT は自動的に無効になりません。

回避策は、オーバークラウドのデプロイおよびそれ以降の再起動後に、いずれかの IBM POWER8 コンピュートノードで sudo ppc64_cpu --smt=off を実行することです。

BZ#1793440

Red Hat OpenStack 16.0 には、実際には OVN エージェントが正常でクラウドが動作状態にあるにもかかわらず、コマンド「openstack network agent list」により、エージェントがダウンしていることを示す出力が断続的に表示されるという既知の問題があります。

該当するエージェントは、OVN Controller エージェント、OVN Metadata エージェント、および OVN Controller Gateway エージェントです。

現在、この問題に対する回避策はありません。「openstack network agent list」コマンドの出力を無視する必要があります。

BZ#1794328
Load-balancing サービス (octavia) にコンポーザブルロールが設定されている場合に、Red Hat OpenStack Platform 16.0 オーバークラウドのインストールに失敗するという既知の問題があります。現在、この問題には確認された回避策はありません。詳細は、BZ#1794328 を参照してください。
BZ#1795165

OpenStack Networking (neutron) には、作成されたすべてのインスタンスが、内部 DNS に設定された dns_domain の値ではなく、ネットワークに関連付けられた dns_domain の値を継承するという既知の問題があります。

この問題の原因は、ネットワークの dns_domain 属性が neutron の dns_domain 設定オプションを上書きすることです。

この問題を回避するには、内部 DNS 機能を使用する際に、ネットワークの dns_domain 属性を設定しないでください。

BZ#1795688

neutron_api サービスがコントローラーノードにデプロイされた Placement サービスにアクセスできるようにするには (Novacontrol ロールを使用する際に必要)、以下の hieradata 設定をコントローラー環境ファイルに追加します。

service_config_settings:
     placement:
         neutron::server::placement::password: <Nova password>
  neutron::server::placement::www_authenticate_uri: <Keystone Internal API URL>
  neutron::server::placement::project_domain_name: 'Default'
  neutron::server::placement::project_name: 'service'
  neutron::server::placement::user_domain_name: 'Default'
  neutron::server::placement::username: nova
  neutron::server::placement::auth_url: <Keystone Internal API URL>
  neutron::server::placement::auth_type: 'password'
  neutron::server::placement::region_name: <Keystone Region>

Puppet を使用したロール用 hieradata カスタマイズの詳細は、『オーバークラウドの高度なカスタマイズ』の「Puppet: ロール用 hieradata のカスタマイズ」を参照してください。

注記

この設定は、Placement サービスが neutron_api と同じノード上で動作していない場合に、カスタムロールを設定してオーバークラウドをデプロイする際に必要です。

BZ#1795956

Red Hat OpenStack Platform Load-balancing サービスには、ノードのリブート時にコンテナー octavia_api および octavia_driver_agent が起動に失敗するという既知の問題があります

この問題の原因は、ノードのリブート時にディレクトリー /var/run/octavia が存在しないことです。

この問題を修正するには、以下の行をファイル /etc/tmpfiles.d/var-run-octavia.conf に追加します。

d /var/run/octavia 0755 root root - -
BZ#1796215

Red Hat OpenStack Platform 16.0 には、オーバークラウドノードの設定中に ansible-playbook が正常に動作しない場合があるという既知の問題があります。この問題の原因は、tripleo-admin ユーザーの ssh 使用が許可されないことです。さらに、openstack overcloud deploy コマンドの引数 --stack-only が、tripleo-admin ユーザーを許可するための enable ssh admin ワークフローを実行しなくなりました。

回避策は、--stack-only を使用する場合には、openstack overcloud admin authorize コマンドを使用して enable ssh admin ワークフローを独自に実行すると共に、手動の config- download コマンドを実行することです。詳細は、『director のインストールと使用方法』の「プロビジョニングプロセスと設定プロセスの分離」を参照してください。

BZ#1797047
Red Hat Ceph Storage 4.0 のパッケージングには問題があります。詳細は、BZ#1797075 を参照してください。そのため、manila access-list を使用することができません。ファイル共有の作成は機能しますが、manila access-list を使用しないとファイル共有を使用することができません。したがって、NFS バックエンドに CephFS を使用した Shared File System サービスを使用することができません。
BZ#1797892

Red Hat OpenStack Platform 16.0 には、ハードな (強制的な) シャットダウンを受けたノードが動作状態に復帰すると、それまで実行中だったコンテナーが podman で「Created」の状態となる、という既知の問題があります。

この問題の原因は、コンテナーがすでに「Created」の状態で存在しているので、メタデータエージェントが新しいコンテナーを提供できないことです。haproxy side-car コンテナーラッパースクリプトは、コンテナーが「Exited」の状態であることしか想定せず、「Created」の状態にあるコンテナーをクリーンアップしません。

クラウドオペレーターが実施することのできる回避策は、以下の Ansible ad-hoc コマンドを実行して「Created」の状態にあるすべての haproxy コンテナーをクリーンアップすることです。この Ansible ad-hoc コマンドは、アンダークラウドの特定ノード、ノードのグループ、またはクラスター全体から実行する必要があります。

`ansible -b <nodes> -i /usr/bin/tripleo-ansible-inventory -m shell -a "podman ps -a --format {{'{{'}}.ID{{'}}'}} -f name=haproxy,status=created | xargs podman rm -f || :"`

上記の Ansible ad-hoc コマンドで、nodes をインベントリーからの単一のホスト、ホストのグループ、または「all」に設定します。

以下は、compute-0 でコマンドを実行する例です。

`ansible -b compute-0 -i /usr/bin/tripleo-ansible-inventory -m shell -a "podman ps -a --format {{'{{'}}.ID{{'}}'}} -f name=haproxy,status=created | xargs podman rm -f || :"`

Ansible ad-hoc コマンドを実行すると、metadata-agent は指定されたネットワーク用に新しいコンテナーを提供するはずです。

3.1.6. 廃止された機能

BZ#1518222
Red Hat OpenStack Platform 16.0 では、Telemetry サービスの一部である ceilometer クライアント (RHOSP の以前のリリースで非推奨となっていた) はサポートされなくなり、廃止されています。ceilometer は、エージェントのみのサービスとして引き続き RHOSP の一部である点に注意してください (クライアントおよび API は非対応)。
BZ#1631508

Red Hat OpenStack Platform 16.0 では、controller-v6.yaml ファイルが廃止されました。controller-v6.yaml で定義されていたルートは、controller.yaml で定義されるようになりました。(controller.yaml ファイルは、roles_data.yaml で設定される値からレンダリングされる NIC 設定ファイルです。)

以前のバージョンの Red Hat OpenStack Platform director には、2 つのデフォルトルートが含まれていました (外部ネットワーク上の IPv6 用ルートおよびコントロールプレーン上の IPv4 用ルート)。

両方のデフォルトルートを使用するには、roles_data.yaml のコントローラー定義の default_route_networks に、両方のネットワークが含まれるようにしてください (例: default_route_networks: ['External', 'ControlPlane'])。

BZ#1712981
Data Processing サービス (sahara) は Red Hat OpenStack Platform (RHOSP) 15 で 非推奨になり、RHOSP 16.0 で廃止されました。Red Hat では、RHOSP バージョン 13 および 15 で Data Processing サービスのサポートを継続して提供します。
BZ#1754560
Red Hat OpenStack Platform 16.0 では、Elastic Compute Cloud (EC2) API はサポートされなくなりました。director では EC2 API のサポートは非推奨になり、今後の RHOSP リリースで廃止される計画です。
BZ#1764894

Red Hat OpenStack Platform 16.0 では、環境ファイル /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-bootstrap-environment-rhel.yaml が廃止されています。

従来、この環境ファイルは、事前にプロビジョニングされたノードを使用する場合に使用されていました。このファイルは RHOSP の以前のリリースで非推奨となり、今回廃止されました。

第4章 テクニカルノート

本章には、コンテンツ配信ネットワークからリリースされる Red Hat OpenStack Platform「Train」のエラータアドバイザリーの補足情報を記載します。

4.1. RHEA-2020:0283: Red Hat OpenStack Platform 16.0 の一般提供アドバイザリー

本項に記載するバグは、アドバイザリー RHEA-2020:0283 で対応しています。このアドバイザリーについての詳しい情報は、「RHEA-2020:0283 - Product Enhancement Advisory」を参照してください。

ディストリビューションコンポーネントに対する変更:

  • Red Hat OpenStack Platform 16.0 では、Telemetry サービスの一部である ceilometer クライアント (RHOSP の以前のリリースで非推奨となっていた) はサポートされなくなり、廃止されています。ceilometer は、エージェントのみのサービスとして引き続き RHOSP の一部である点に注意してください (クライアントおよび API は非対応)。(BZ#1518222)

openstack-cinder コンポーネントに対する変更:

  • 以前のリリースでは、Red Hat Ceph Storage を Block Storage サービス (cinder) ボリュームとバックアップ両方のバックエンドとして使用している場合には、初回のフルバックアップを実行した後は、フルバックアップを試みても警告が表示されることなく差分バックアップが実行されていました。Red Hat OpenStack Platform 16.0 のテクノロジープレビュー機能により、この問題が修正されました。(BZ#1375207)
  • Red Hat OpenStack Platform Block Storage サービス (cinder) は、ボリュームのクローン時に暗号鍵を自動的に変更するようになりました。Red Hat Ceph Storage を cinder バックエンドとして使用している場合には、現在、この機能はサポートされない点に注意してください。(BZ#1545700)

openstack-glance コンポーネントに対する変更:

  • 以前のリリースでは、暗号化された Block Storage サービス (cinder) ボリュームイメージが削除されても、対応する鍵は削除されませんでした。

    Red Hat OpenStack Platform 16.0 では、この問題が解決されています。Image サービスが cinder ボリュームイメージを削除すると、そのイメージの鍵も削除されます。(BZ#1481814)

  • Red Hat OpenStack Platform 16.0 では、イメージを事前にキャッシュするテクノロジープレビューが Image サービス (glance) に追加されています。これにより、オペレーターはインスタンスをブートする前にキャッシュを温めることができます。(BZ#1706896)

openstack-heat コンポーネントに対する変更:

  • Red Hat OpenStack Platform Orchestration サービス (heat) に、新たなリソースタイプ OS::Glance::WebImage が追加されました。このリソースタイプは、Glance v2 API を使用して URL から Image サービス (glance) のイメージを作成するのに使用します。この新しいリソースタイプは、以前の OS::Glance::Image に置き換わるものです。(BZ#1649264)

openstack-keystone コンポーネントに対する変更:

  • keystone において、Red Hat OpenStack Platform director のデプロイメント後にシステムに存在するデフォルトロールの基本セット (例: admin、member、および reader) がサポートされるようになりました。これらのデフォルトロールは、すべての認可ターゲット (例: システム、ドメイン、およびプロジェクト) について、デフォルトの director ポリシーに組み込まれています。(BZ#1228474)

openstack-manila コンポーネントに対する変更:

  • Red Hat OpenStack Platform 16.0 では、IPv6 が CephFS NFS ドライバーで機能するように、Shared File Systems サービス (manila) にテクノロジープレビュー機能が追加されています。(BZ#1575079)

openstack-neutron コンポーネントに対する変更:

  • Linux ブリッジ ML2 ドライバーおよびエージェントを使用する Red Hat OpenStack Platform デプロイメントは、アドレス解決プロトコル (ARP) スプーフィングに対して保護されません。Red Hat Enterprise Linux 8 に含まれる Ethernet bridge frame table 管理 (ebtables) のバージョンは、Linux ブリッジ ML2 ドライバーと互換性がありません。

    Linux ブリッジ ML2 ドライバーおよびエージェントは Red Hat OpenStack Platform 11 で非推奨になりました。したがって、使用すべきではありません。

    Red Hat では、その代わりに ML2 Open Virtual Network (OVN) ドライバーおよびサービス (Red Hat OpenStack Platform director によりデプロイされるデフォルト) の使用を推奨します。(BZ#1779221)

  • TCP、UDP、または Floating IP アドレスのその他のプロトコルポートから、TCP、UDP、または neutron ポートの Fixed IP アドレスのいずれかに関連付けられたその他のプロトコルポートに、トラフィックを転送できるようになりました。転送されたトラフィックは、neutron API に対する機能拡張および OpenStack Networking プラグインにより管理されます。Floating IP アドレスには、複数の転送定義を設定することができます。ただし、すでに OpenStack Networking ポートと関連のある IP アドレスのトラフィックを転送することはできません。転送することができるのは、ネットワーク上の集中ルーター (レガシー、HA、および DVR+HA) によって管理される Floating IP アドレスのトラフィックだけです。

    Floating IP アドレスのポートのトラフィックを転送するには、以下の OpenStack Networking プラグインコマンドを使用します。

    openstack floating ip port forwarding create
    --internal-ip-address <internal-ip-address>
    --port <port>
    --internal-protocol-port <port-number>
    --external-protocol-port <port-number>
    --protocol <protocol>
    <floating-ip>

    --internal-ip-address <internal-ip-address>: 転送されたトラフィックを受信する neutron ポートの内部 Fixed IP アドレス (IPv4)。

    --port <port>: 転送されたトラフィックを受信する neutron ポートの名前または ID。

    --internal-protocol-port <port-number>: 転送されたトラフィックを受信する neutron ポート Fixed IP アドレスのプロトコルポート番号。

    --external-protocol-port <port-number> トラフィックの転送元である Floating IP アドレスのポートのプロトコルポート番号。

    --protocol <protocol>: Floating IP アドレスのポートが使用するプロトコル (例: TCP、UDP)。

    <floating-ip>: トラフィックの転送元であるポートの Floating IP (IP アドレスまたは ID)。

    以下に例を示します。

    openstack floating ip port forwarding create \ --internal-ip-address 192.168.1.2 \ --port f7a08fe4-e79e-4b67-bbb8-a5002455a493 \ --internal-protocol-port 18343 \ --external-protocol-port 8343 \ --protocol tcp \ 10.0.0.100 (BZ#1749483)

openstack-nova コンポーネントに対する変更:

  • 今回の機能拡張により、NUMA トポロジーが設定されたインスタンスのライブマイグレーションがサポートされるようになりました。以前のリリースでは、この操作はデフォルトで無効でした。この操作は、回避措置として enable_numa_live_migration 設定オプションを使用して有効にすることができましたが、この設定オプションはデフォルトでは False に設定されていました。このようなインスタンスのライブマイグレーションを実施すると、ベースとなる NUMA ゲスト/ホスト間のマッピングやリソース使用状況をまったく更新せずに、インスタンスが移行先ホストに移動されるためです。新たな NUMA 対応ライブマイグレーション機能により、移行先ホストがインスタンスに適さない場合には、別の移行先ホストでライブマイグレーションが試みられます (要求に代替ホストが設定されている場合)。移行先ホストがインスタンスに適する場合には、新たなホストを反映するために NUMA ゲスト/ホスト間のマッピングが再計算され、そのリソース使用状況が更新されます。(BZ#1222414)
  • 今回の機能拡張により、SR-IOV ベースの neutron インターフェースが設定されたインスタンスのライブマイグレーションがサポートされるようになりました。neutron SR-IOV インターフェースは、直接モードと間接モードという 2 つのカテゴリーにグループ分けすることができます。直接モードの SR-IOV インターフェースは、ゲストに直接接続され、ゲスト OS に公開されます。間接モードの SR-IOV インターフェースは、ゲストと SR-IOV デバイス間に macvtap 等のソフトウェアインターフェースを持ちます。この機能により、間接モードの SR-IOV デバイスを持つインスタンスの透過的なライブマイグレーションが可能になります。ライブマイグレーション中にハードウェアの状態をコピーする一般的な方法がないため、直接モードの移行はゲストに対して透過的ではありません。直接モードのインターフェースの場合には、既存の休止/再開のワークフローを模擬します。たとえば、SR-IOV デバイスを使用する場合には、移行前に直接モードのインターフェースの接続を解除し、移行後に再度接続します。その結果、ライブマイグレーションの可能なインターフェースとのボンディングをゲスト内に作成しない限り、直接モードの SR-IOV ポートを持つインスタンスでは、移行中にネットワーク接続が失われます。

    以前のリリースでは、SR-IOV ベースのネットワークインターフェースが設定されたインスタンスのライブマイグレーションを行うことはできませんでした。ホストのメンテナンス等にライブマイグレーションが頻繁に使用されているため、このことが問題となっていました。以前のリリースでは、コールドマイグレーションでインスタンスを移行する必要がありましたが、ゲストにダウンタイムが発生していました。

    今回の機能拡張により、SR-IOV ベースのネットワークインターフェースが設定されたインスタンスのライブマイグレーションが可能になりました。(BZ#1360970)

  • Red Hat OpenStack Platform 16.0 では、ネットワークインターフェースの作成時に、QoS の最小帯域幅ルールを指定できるようになりました。今回の機能拡張により、利用可能なネットワーク帯域幅として指定した値が、インスタンスに対して保証されるようになりました。現在、サポートされている操作は、サイズ変更およびコールドマイグレーションだけです。(BZ#1463838)
  • インスタンスの再ビルド時に NUMATopologyFilter が無効になるようになりました。以前のリリースではこのフィルターが常に実行され、新たなイメージおよび既存フレーバーを使用する第 2 のインスタンス用にホストに十分な追加容量がある場合に限り、再ビルドは成功していました。これは適切ではない不必要な動作でした。(BZ#1775246)
  • インスタンスレベルで PCI NUMA アフィニティーを設定できるようになりました。この機能は、SR-IOV ベースのネットワークインターフェースを持つインスタンスに NUMA アフィニティーを設定する際に必要です。以前のリリースでは、NUMA アフィニティーは PCI パススルーデバイスに対してホストレベルでしか設定することができませんでした。(BZ#1775575)
  • 今回の機能拡張により、以下のパラメーターを使用して、同じコンピュートノードで専用の (ピニングされた) インスタンスと共有の (ピニングされていない) インスタンスをスケジューリングできるようになりました。

    • NovaComputeCpuDedicatedSet: ピニングされたインスタンス CPU のプロセスをスケジューリングすることができる物理ホスト CPU 番号のコンマ区切りリストまたは範囲。非推奨となった NovaVcpuPinSet パラメーターに置き換わるものです。
    • NovaComputeCpuSharedSet: vCPU インベントリーを提供するのに使用される物理ホスト CPU 番号のコンマ区切りリストまたは範囲。ピニングされていないインスタンスをスケジューリングすることができるホスト CPU を定義し、共有エミュレータースレッドポリシー hw:emulator_threads_policy=share が設定されたインスタンスのエミュレータースレッドをオフロードするホスト CPU を定義します。注記: このオプションは従来から存在していましたが、その用途がこの機能により拡張されています。

      ホストアグリゲートを使用して、これらのインスタンス種別が別個のホスト上で実行されるようにする必要がなくなりました。また、[DEFAULT] reserved_host_cpus 設定オプションは不要になり、未設定にすることができます。

      アップグレードするには、以下を実行します。

    • これまでピニングされたインスタンス用に使用されていたホストの場合には、NovaVcpuPinSet の値を NovaComputeCpuDedicatedSet に変更する必要があります。
    • これまでピニングされていないインスタンス用に使用されていたホストの場合には、NovaVcpuPinSet の値を NovaComputeCpuSharedSet に変更する必要があります。
    • NovaVcpuPinSet に値が設定されていない場合には、実行中のインスタンスの種別に応じて、すべてのホストコアを NovaComputeCpuDedicatedSet または NovaComputeCpuSharedSet のどちらかに割り当てる必要があります。

      アップグレードが完了したら、同一のホストで両方のオプションの設定を始めることができます。ただし、そのためには、すべてのインスタンスをホストから移行する必要があります。ピニングされていないインスタンスのコアが NovaComputeCpuSharedSet の一覧に含まれていない場合、またはピニングされたインスタンスのコアが NovaComputeCpuDedicatedSet の一覧に含まれていない場合には、Compute サービスは起動することができないためです。(BZ#1693372)

openstack-octavia コンポーネントに対する変更:

  • Octavia API を使用して VIP アクセス制御リスト (ACL) を作成し、リスナーへの着信トラフィックを、許可されたソース IP アドレス (CIDR) のセットに制限できるようになりました。その他の着信トラフィックは、すべて拒否されます。詳細は、『ネットワークガイド』の「アクセス制御リストを使用したロードバランサーの保護」を参照してください。(BZ#1691025)
  • Red Hat OpenStack Platform 16.0 では、テクノロジープレビューとして Load-balancing サービス (octavia) が UDP プロトコルをサポートするようになりました。(BZ#1703956)

openstack-placement コンポーネントに対する変更:

  • Placement サービスが、Compute (nova) サービスから抽出されるようになりました。このサービスは director によってデプロイおよび管理され、アンダークラウド上およびオーバークラウドのコントローラーノード上で追加コンテナーとして動作します。(BZ#1625244)

openstack-tripleo-common コンポーネントに対する変更:

  • Red Hat OpenStack Platform 16.0 では、テクノロジープレビュー機能の Workflow サービス (mistral) タスクにより、以下の手順に従ってパスワードのローテーションを実装することができます。

    • rotate-password ワークフローを実行し、新しいパスワードを生成してそれをプラン環境に保管する。
    • オーバークラウドを再デプロイする。

      パスワードの変更後にパスワードを取得することもできます。

      パスワードのローテーションを実装するには、以下の手順に従います。

      注記

      ワークフロータスクにより、デフォルトのパスワードが変更されます。このタスクは、ユーザー定義の環境ファイルで指定されたパスワードを変更しません。

      1. 新しいワークフロータスクを実行してパスワードを再生成します。

        $ source ./stackrc
        $ openstack workflow execution create tripleo.plan_management.v1.rotate_passwords '{"container": "overcloud"}'
        This command generates new passwords for all passwords except for BarbicanSimpleCryptoKek and KeystoneFernet* and KeystoneCredential*. There are special procedures to rotate these passwords.
        It is also possible to specify specific passwords to be rotated. The following command rotates only the specified passwords.
        $ openstack workflow execution create tripleo.plan_management.v1.rotate_passwords '{"container": "overcloud", "password_list": ["BarbicanPassword", "SaharaPassword", "ManilaPassword"]}'
      2. オーバークラウドを再デプロイします。

        $ ./overcloud-deploy.sh

        パスワード (新たに生成したパスワードを含む) を取得するには、以下の手順に従います。

      3. 次のコマンドを実行します。

        $ openstack workflow execution create tripleo.plan_management.v1.get_passwords '{"container": "overcloud"}'
        You should see output from the command, similar to the following:
        +--------------------+---------------------------------------------+
        | Field              | Value                                       |
        +--------------------+---------------------------------------------+
        | ID                 | edcf9103-e1a8-42f9-85c1-e505c055e0ed        |
        | Workflow ID        | 8aa2ac9b-22ee-4e7d-8240-877237ef0d0a        |
        | Workflow name      | tripleo.plan_management.v1.rotate_passwords |
        | Workflow namespace |                                             |
        | Description        |                                             |
        | Task Execution ID  | <none>                                      |
        | Root Execution ID  | <none>                                      |
        | State              | RUNNING                                     |
        | State info         | None                                        |
        | Created at         | 2020-01-22 15:47:57                         |
        | Updated at         | 2020-01-22 15:47:57                         |
        +--------------------+---------------------------------------------+
        In the earlier example output, the value of State is RUNNING. State should eventually read SUCCESS.
      4. State の値を再度確認します。

        $ openstack workflow execution show edcf9103-e1a8-42f9-85c1-e505c055e0ed
        +--------------------+---------------------------------------------+
        | Field              | Value                                       |
        +--------------------+---------------------------------------------+
        | ID                 | edcf9103-e1a8-42f9-85c1-e505c055e0ed        |
        | Workflow ID        | 8aa2ac9b-22ee-4e7d-8240-877237ef0d0a        |
        | Workflow name      | tripleo.plan_management.v1.rotate_passwords |
        | Workflow namespace |                                             |
        | Description        |                                             |
        | Task Execution ID  | <none>                                      |
        | Root Execution ID  | <none>                                      |
        | State              | SUCCESS                                     |
        | State info         | None                                        |
        | Created at         | 2020-01-22 15:47:57                         |
        | Updated at         | 2020-01-22 15:48:39                         |
        +--------------------+---------------------------------------------+
      5. State の値が SUCCESS であれば、パスワードを取得することができます。

        $ openstack workflow execution output show edcf9103-e1a8-42f9-85c1-e505c055e0ed
        You should see output similar to the following:
           {
               "status": "SUCCESS",
               "message": {
                   "AdminPassword": "FSn0sS1aAHp8YK2fU5niM3rxu",
                   "AdminToken": "dTP0Wdy7DtblG80M54r4a2yoC",
                   "AodhPassword": "fB5NQdRe37BaBVEWDHVuj4etk",
                   "BarbicanPassword": "rn7yk7KPafKw2PWN71MvXpnBt",
                   "BarbicanSimpleCryptoKek": "lrC3sGlV7-D7-V_PI4vbDfF1Ujm5OjnAVFcnihOpbCg=",
                   "CeilometerMeteringSecret": "DQ69HdlJobhnGWoBC0jM3drPF",
                   "CeilometerPassword": "qI6xOpofuiXZnG95iUe8Oxv5d",
                   "CephAdminKey": "AQDGVPpdAAAAABAAZMP56/VY+zCVcDT81+TOjg==",
                   "CephClientKey": "AQDGVPpdAAAAABAAanYtA0ggpcoCbS1nLeDN7w==",
                   "CephClusterFSID": "141a5ede-21b4-11ea-8132-52540031f76b",
                   "CephDashboardAdminPassword": "AQDGVPpdAAAAABAAKhsx630YKDhQrocS4o4KzA==",
                   "CephGrafanaAdminPassword": "AQDGVPpdAAAAABAAKBojG+CO72B0TdBRR0paEg==",
                   "CephManilaClientKey": "AQDGVPpdAAAAABAAA1TVHrTVCC8xQ4skG4+d5A=="
               }
           }
        (BZ#1600967)

openstack-tripleo-heat-templates コンポーネントに対する変更:

  • nova-compute ironic ドライバーは、BM ノードのクリーンアップ中にノードの更新を試みます。クリーンアップには約 5 分間かかりますが、nova-compute は約 2 分間しかノードの更新を試みません。タイムアウト後、nova-compute は停止し、nova インスタンスを ERROR 状態にします。

    回避策は、nova-compute サービスに以下の設定オプションを定義することです。

    [ironic]
    api_max_retries = 180

    その結果、nova-compute はより長時間 BM ノードの更新を試み続け、最終的に成功します。(BZ#1647005)

  • Red Hat OpenStack Platform 16.0 には、OpenStack インスタンスの設定に必要なメタデータ情報が利用できず、ネットワークに接続されていない状態でインスタンスが起動するという既知の問題があります。

    順序付けの問題が原因で、ovn_metadata_agent の haproxy ラッパーが更新されません。

    クラウドオペレーターが実施することのできる回避策は、更新後に以下の Ansible コマンドを実行して、選択したノードの ovn_metadata_agent を再起動することです。これにより、ovn_metadata_agent は更新バージョンの haproxy ラッパースクリプトを使用するようになります。

    ansible -b <nodes> -i /usr/bin/tripleo-ansible-inventory -m shell -a "status=`sudo systemctl is-active tripleo_ovn_metadata_agent; if test \"$status\" == \"active\"; then sudo systemctl restart tripleo_ovn_metadata_agent; echo restarted; fi"`

    上記の Ansible コマンドで、nodes を単一のノード (例: compute-0)、すべてのコンピュート (例: compute*)、または「all」に設定します。

    ovn_metadata_agent はコンピュートノードで最も一般的に使用されているので、以下の Ansible コマンドにより、クラウド内のすべてのコンピュートノードのエージェントが再起動されます。

    ansible -b compute* -i /usr/bin/tripleo-ansible-inventory -m shell -a "status=`sudo systemctl is-active tripleo_ovn_metadata_agent; if test \"$status\" == \"active\"; then sudo systemctl restart tripleo_ovn_metadata_agent; echo restarted; fi"`

    ovn_metadata_agent サービスを再起動すると、更新された haproxy ラッパースクリプトが使用され、仮想マシンの起動時にメタデータを提供することができます。すでに実行中の問題のある仮想マシンは、回避策の適用後に再起動すると、通常どおりに動作するはずです。(BZ#1790467)

  • Red Hat OpenStack Platform 16.0 director は、マルチコンピュートセルのデプロイメントをサポートするようになりました。今回の機能拡張により、お使いのクラウドのスケールアウトがより容易になります。それぞれの個々のセルはセルコントローラー上に専用のデータベースおよびメッセージキューを持ち、中央のコントロールプレーンの負荷を減らすためです。詳しい情報は、『Instances and Images』の「Scaling deployments with Compute cells」を参照してください。(BZ#1328124)
  • 今回の更新で、OVSDB サーバーへの接続が完全に暗号化されたことから、全 OVN サービス間の通信が完全に暗号化されるようになりました。すべての OVN クライアント (ovn-controller、neutron-server、および ovn-metadata-agent) が、Mutual TLS 暗号化を使用して OVSDB サーバーに接続するようになりました。(BZ#1601926)
  • Red Hat OpenStack Platform 16.0 では、rsyslog の変更に対応することができるように、Orchestration サービス (heat) にテクノロジープレビュー機能が追加されています。

    • rsyslog は、fluentd インストールと機能的に等価となるように、コンテナーログを収集して転送するよう設定されます。
    • 管理者は、fluentd と同じように rsyslog のログ転送を設定することができます。(BZ#1623152)
  • Red Hat OpenStack Platform 16.0 では、director を使用して Block Storage サービス (cinder) バックエンドタイプのアベイラビリティーゾーンを指定できるようになりました。(BZ#1700396)
  • Red Hat OpenStack Platform director により、追加のノードをデプロイできるようになりました。このノードを使用して、デプロイメント中のシステムプロビジョニング用に、さらに Bare Metal Provisioning コンダクターサービスリソースを追加することができます。(BZ#1710093)
  • Red Hat OpenStack Platform 16.0 では、Elastic Compute Cloud (EC2) API はサポートされなくなりました。director では EC2 API のサポートは非推奨になり、今後の RHOSP リリースで廃止される計画です。(BZ#1754560)
  • Red Hat OpenStack Platform 16.0 では、controller-v6.yaml ファイルが廃止されました。controller-v6.yaml で定義されていたルートは、controller.yaml で定義されるようになりました。(controller.yaml ファイルは、roles_data.yaml で設定される値からレンダリングされる NIC 設定ファイルです。)

    以前のバージョンの Red Hat OpenStack Platform director には、2 つのデフォルトルートが含まれていました (外部ネットワーク上の IPv6 用ルートおよびコントロールプレーン上の IPv4 用ルート)。

    両方のデフォルトルートを使用するには、roles_data.yaml のコントローラー定義の default_route_networks に、両方のネットワークが含まれるようにしてください (例: default_route_networks: ['External', 'ControlPlane'])。(BZ#1631508)

  • Red Hat OpenStack Platform 16.0 では、ceph.conf の任意のセクションにカスタム Red Hat Ceph Storage 構成設定を追加できるようになりました。以前のリリースでは、カスタム設定は ceph.conf の [global] セクションにしか追加することができませんでした。(BZ#1666973)
  • Red Hat OpenStack Platform 16.0 では、Orchestration サービス (heat) の新たなデプロイメントパラメーターを利用することができ、管理者はセルコントローラーで nova メタデータサービスを有効にすることができます。

    parameter_defaults:
       NovaLocalMetadataPerCell: True

    この新たなパラメーターにより、セルコンピュートの OVN メタデータエージェントからセルコントローラーがホストする nova メタデータ API サービスに、トラフィックが自動的に転送されます。

    RHOSP トポロジーによっては、セルコントローラーでメタデータサービスを実行する機能により、中央のコントロールプレーンのトラフィックを減らすことができます。(BZ#1689816)

  • Red Hat OpenStack Platform 16.0 では、Orchestration サービス (heat) にテクノロジープレビュー機能が追加されています。新たに追加されたパラメーター NovaSchedulerQueryImageType により、イメージの種別に応じて Compute サービス (nova) の配置およびスケジューラーコンポーネントクエリーの配置が制御されます (scheduler/query_placement_for_image_type_support)。

    true に設定すると (デフォルト)、NovaSchedulerQueryImageType はブート要求で使用されるイメージのディスク形式をサポートしないコンピュートノードを除外します。

    たとえば、libvirt ドライバーはエフェメラルバックエンドに Red Hat Ceph Storage を使用し、qcow2 イメージをサポートしません (非常にコストのかかる変換ステップを経ない場合)。この場合には、NovaSchedulerQueryImageType を有効にすると、スケジューラーは Red Hat Ceph Storage を使用するコンピュートノードには qcow2 イメージをブートする要求を送信しません。(BZ#1710634)

puppet-tripleo コンポーネントに対する変更:

  • Red Hat OpenStack Platform director により、テクノロジープレビュー機能として Redfish API のフェンスエージェントである fence_redfish を利用できるようになりました。(BZ#1699449)

python-django-horizon コンポーネントに対する変更:

  • Red Hat OpenStack Platform 16.0 の Dashboard (horizon) に、ユーザーパスワードの変更用に新たなフォームが追加されました。ユーザーが期限切れのパスワードでサインオンしようとすると、このフォームが自動的に表示されます。(BZ#1628541)

python-networking-ansible コンポーネントに対する変更:

  • Red Hat OpenStack Platform 16.0 では、Arista Extensible Operating System (Arista EOS) スイッチと共に ML2 networking-ansible 機能を設定することができるように、OpenStack Bare Metal サービス (ironic) にテクノロジープレビュー機能が追加されています。詳しくは、『ベアメタルプロビジョニング』の「networking-ansible ML2 機能の有効化」を参照してください。(BZ#1621701)
  • Red Hat OpenStack Platform 16.0 では、スイッチポートを変更してトランクモードに設定し、複数の VLAN をポートに割り当てることができるように、テクノロジープレビュー機能が追加されています。(BZ#1622233)

python-networking-ovn コンポーネントに対する変更:

  • フラグ live_migration_wait_for_vif_plug がデフォルトで有効なので、Red Hat OpenStack Platform 16.0 では、OVN を有効にした状態でライブマイグレーションが成功するようになりました。

    以前のリリースでは、OpenStack Networking (neutron) が vif_plugged の通知を送信するのをシステムが待機するため、ライブマイグレーションに失敗していました。(BZ#1716335)

  • 現時点では、メンバーからデータを取得する際に、OVN ロードバランサーは新しい接続を開始しません。ロードバランサーは送信先アドレスおよびポートを変更し、リクエストのパケットをメンバーに送信します。そのため、IPv4 ロードバランサーアドレスを使用している間、IPv6 メンバーを定義することができません (その逆も同様です)。現在、この問題に対する回避策はありません。(BZ#1734301)

python-novajoin コンポーネントに対する変更:

  • 以前のリリースでは、Novajoin が IPA サーバーへの接続を失うと、直ちに再接続を試みていました。そのため、タイミングの問題が発生し、接続の再確立が妨げられる場合がありました。今回の更新により、retry_delay を使用して、IPA サーバーへの接続をリトライするのを待機する秒数を設定できるようになりました。これにより、タイミングの問題が発生する可能性が低減されると期待されます。(BZ#1767481)

python-oslo-utils コンポーネントに対する変更:

  • 以前のリリースでは、oslo.util ライブラリーの正規表現が更新されておらず、より新しいバージョンのエミュレーター (qemu バージョン 4.1.0) からの出力フォーマットを認識できませんでした。Red Hat OpenStack 16.0 の今回のフィックスにより、正規表現が更新され、oslo.util.imageutils ライブラリーが正しく機能するようになりました。(BZ#1758302)

python-tripleoclient コンポーネントに対する変更:

  • director に overcloud undercloud minion install コマンドが追加されました。このコマンドを使用すると、追加のホストを設定してアンダークラウドサービスを強化することができます。(BZ#1710089)
  • director により、追加のホストをデプロイできるようになりました。このホストを使用して、デプロイメントに関する操作用にさらに heat-engine リソースを追加することができます。(BZ#1710092)
  • Red Hat OpenStack Platform 16.0 では、ローカルレジストリーのイメージをプッシュ、一覧表示、削除、および表示 (メタデータの表示) できるようになりました。

    • イメージをリモートリポジトリーからメインのリポジトリーにプッシュするには、以下のコマンドを実行します。

      $ sudo openstack tripleo container image push docker.io/library/centos
    • リポジトリーの内容を一覧表示するには、以下のコマンドを実行します。

      $ openstack tripleo container image list
    • イメージを削除するには、以下のコマンドを実行します。

      $ sudo openstack tripleo container image delete
    • イメージのメタデータを表示するには、以下のコマンドを実行します。

      $ openstack tripleo container image show (BZ#1545855)
  • アクションが意図せず実行されてしまう可能性を低減するために、今回の機能拡張により、オーバークラウドノードの削除には、アクションを実行する前にユーザーの確認が必要になりました。openstack overcloud node delete <node> コマンドには、アクションを実行する前に y/n の確認が必要です。この確認を省略するには、コマンドラインに --yes を追加します。(BZ#1593057)