3.4. Red Hat OpenStack Platform 17.1 GA - 2023 年 8 月 17 日

この更新までは、ベアメタルのオーバークラウドノードは削除後も metalsmith ツールによってアクティブとしてリストされていました。これは、ノードの命名スキームがオーバークラウドのロール命名スキームと重複している環境で発生し、アンデプロイ時に間違ったノードのプロビジョニングが解除される可能性がありました。metalsmith ツールは最初に割り当て名 (ホスト名) を使用してベアメタルノードのステータスを検索するため、削除済みノードがアクティブとして検出されることがありました。

今回の更新により、プロビジョニングが解除されるノードは割り当て名 (ホスト名) で参照されるようになり、常に正しいノードのプロビジョニングが解除されるようになります。つまりノードは、ホスト名が存在しない場合に限りノード名で参照されます。

この更新までは、データベースが宛先ホストの詳細で更新されなかったため、ライブマイグレーションが失敗する可能性がありました。

今回の更新により、ライブマイグレーション中に、データベース内のインスタンスホストの値が宛先ホストに設定されます。

この更新までは、ロードバランサー仮想 IP (VIP) に関連付けられた Floating IP (FIP) を使用している場合、Open Virtual Network (OVN) ロードバランサーのヘルスチェックは実行されず、FIP を使用している場合はトラフィックがエラー状態のメンバーにリダイレクトされていました。

この更新により、Load Balancer Virtual IP (VIP) に関連付けられた Floating IP (FIP) を使用する場合、FIP 用に新しいロードバランサーヘルスチェックが作成され、トラフィックはエラー状態のメンバーにリダイレクトされなくなります。

この更新までは、/home/stack/config-download/overcloud/cephadm の cephadm-ansible ログはローテーションされませんでした。cephadm_command.log はオーバークラウドデプロイメントごとに追加され、サイズが増加しました。また、openstack overcloud ceph spec 操作ごとに、ログ /home/stack/ansible.log はローテーションされませんでした。

現在、すべてのオーバークラウドデプロイメントとすべての Ceph spec 操作に対して、日付ありのログが次の形式で生成されます。

この更新までは、Compute サービス (nova) は、仮想マシンディスク (VMDK) イメージファイルの内容の信頼性チェックを行いませんでした。特別に作成された VMDK イメージを使用すると、ホストファイルシステム上の機密ファイルが、その VMDK イメージで起動されたゲストに公開される可能性がありました。今回の更新により、Compute サービスが VMDK ファイルの信頼性をチェックし、リーク動作が依存する VMDK 機能が禁止されます。つまり、悪用目的で作成された VMDK ファイルを使用して、ホストファイルシステムの機密性の高いコンテンツをリークすることは不可能になります。このバグ修正は、CVE-2022-47951 に対処するものです。

この更新までは、rgw_max_attr_size のデフォルト値は 256 で、大きなイメージをアップロードするときに OpenStack 上の OpenShift で問題が発生していました。今回の更新により、rgw_max_attr_size のデフォルト値は 1024 になりました。

値を変更するには、オーバークラウドデプロイメントに含める環境ファイルに次の設定を追加します。

parameters_default:
  CephConfigOverrides:
    rgw_max_attr_size: <new value>

この更新までは、OVS インターフェイスのネットワーク設定のリグレッションがネットワークパフォーマンスに悪影響を及ぼしていました。今回の更新により、os-vif OVS プラグインが強化され、非 Windows インスタンスの OVS インターフェイスにおけるネットワークパフォーマンスが向上しました。

この更新までは、RHOSP 動的ルーティングを使用する RHOSP 17.1 環境では、OVN BGP エージェントが使用する Autonomous System Number (ASN) のデフォルト値が FRRouting (FRR) が使用する ASN と異なるという既知の問題がありました。

17.1 GA では、この問題は解決されています。FrrOvnBgpAgentAsn および FrrBgpAsn のデフォルト値は有効であり、変更せずに使用できます。

このリリースより前は、hw_machine_type イメージプロパティーを持たないインスタンスのマシンタイプは、ハードリブートまたは移行後に新しく設定されたマシンタイプを使用するため、RHOSP デプロイメントの有効期間中に NovaHWMachineType を変更できませんでした。インスタンスの基盤となるマシンタイプを変更すると、インスタンスの内部 ABI が破損する可能性があります。

今回のリリースでは、インスタンスの起動時に、Compute サービスがインスタンスのシステムメタデータ内にインスタンスのマシンタイプを記録します。そのため、既存インスタンスのマシンタイプに影響を及ぼすことなく、RHOSP デプロイメントの有効期間中に NovaHWMachineType を変更できるようになりました。

今回の更新では、セキュリティーグループのロギングが導入されます。インスタンスに出入りするトラフィックフローと試行を監視するには、セキュリティーグループのネットワーキングサービスパケットログを設定できます。

インスタンスポートを 1 つ以上のセキュリティーグループに関連付け、各セキュリティーグループに 1 つ以上のルールを定義できます。たとえば、ファイナンスセキュリティーグループ内の任意のインスタンスにインバウンド SSH トラフィックをドロップするルールを作成できます。さらに、そのグループ内のインスタンスが ICMP (ping) メッセージを送信および応答できるようにするために、別のルールを作成できます。

次に、パケットロギングを設定して、受け入れられたパケットフローとドロップされたパケットフローの組み合わせを記録できます。

セキュリティーグループのロギングは、ステートフルセキュリティーグループとステートレスセキュリティーグループの両方に使用できます。

ログに記録されたイベントは、インスタンスをホストする Compute ノードの /var/log/containers/stdouts/ovn_controller.log ファイルに保存されます。

この機能拡張は、クラウドユーザーが "アクティブ" なインスタンスにアクセスできない理由が、インスタンスをホストする Compute ノードに到達できないためかどうかを判断するのに役立ちます。RHOSP 管理者は、次のパラメーターを設定できるようになりました。これにより、クラウドユーザーが openstack show server details コマンドを実行する際にホストの Compute ノードに到達できない場合は host_status フィールドにステータスを入力するカスタムポリシーを有効にできます。

今回の更新により、個別のセルデータベースからリソースをカウントする代わりに、API データベースのインスタンスマッピングからリソース使用量とインスタンスの配置をクエリーすることで、コアと RAM のクォータ使用量をカウントするように、RHOSP デプロイメントを設定できます。これにより、一時的なセルの停止やマルチセル環境でのセルのパフォーマンス低下に対して、割り当て使用量のカウントが回復します。

次の設定オプションを設定して、配置から割り当て使用量をカウントします。

parameter_defaults:
  ControllerExtraConfig:
    nova::config::nova_config:
      quota/count_usage_from_placement:
        value: 'True'

今回の更新により、バックアップおよび復元手順のワークフローで検証フレームワークを使用して、復元されたシステムのステータスを検証できるようになります。これには、次の検証が含まれています。

この機能拡張により、クラウド管理者は、Shared File Systems サービス (manila) バックエンドストレージを設定するときに、director を介してストレージバックエンドごとにアベイラビリティゾーン (AZ) を指定できるようになります。

今回の更新により、管理者は AZ アノテーションを使用してストレージプロビジョニング要求を論理的に分離し、障害ドメインを示すことができます。管理者によって設定された AZ は、Shared File Systems サービスによってエンドユーザーに公開されます。エンドユーザーは、必要に応じてワークロードを特定の AZ にスケジュールするように要求できます。複数のストレージバックエンドを設定する場合、管理者は、すべてのバックエンドに対して単一の AZ を示すのではなく、各バックエンドに対して異なる AZ をタグ付けする場合もあります。

director には、ストレージ AZ を示す新しいオプションがあります。各オプションは、サポートされているストレージバックエンドドライバーに対応します。AZ の詳細は、永続ストレージの設定 を参照してください。

今回の更新により、それぞれのフェンシングリソースを定義することで、tripleo を介した他のフェンシングデバイスと同様に、sbd を使用する fence_watchdog を設定できるようになります。

parameter_defaults:
  EnableFencing: true
  FencingConfig:
    devices:
    - agent: fence_watchdog
      host_mac: "52:54:00:74:f7:51"

operator は、sbd を有効にし、ウォッチドッグタイムアウトを設定する必要があります。

parameter_defaults:
  ExtraConfig:
    pacemaker::corosync::enable_sbd: true
    tripleo::fencing::watchdog_timeout: 20

この機能拡張により、ディスク全体のオーバークラウドイメージである overcloud-hardened-uefi-full.qcow2 によりインストールされた LVM ボリュームが、シンプールによってバックアップされるようになりました。ボリュームは、引き続き利用可能な物理ストレージを消費するために拡張されますが、デフォルトではオーバープロビジョニングされません。

シンプロビジョニングされた論理ボリュームの利点は次のとおりです。

この更新では、失敗したライブマイグレーションへの対処に影響を及ぼす可能性のある問題を修正するスクリプト neutron-remove-duplicated-port-bindings が導入されています。

ライブマイグレーションが失敗すると、Compute サービス (Nova) はマイグレーションを元に戻します。移行を元に戻すと、データベースまたは送信先コンピュートノードで作成されたオブジェクトが削除されます。

ただし、場合によっては、失敗したライブマイグレーションを元に戻した後もポートに重複したポートバインドが残ることがありました。

neutron-remove-duplicated-port-bindings スクリプトは、重複したポートバインディングを検出し、非アクティブのバインディングを削除します。ライブマイグレーションの失敗によりポートバインドが重複する場合は、スクリプトを実行できます。

この機能拡張により、operator は Pacemaker が管理する仮想 IP (VIP) の run_arping 機能を有効にして、クラスターが重複 IP を事前にチェックできます。

これを行うには、次の設定を環境ファイルに追加する必要があります。

  ExtraConfig:
    pacemaker::resource::ip::run_arping: true

重複が見つかった場合、次のエラーが /var/log/pacemaker/pacemaker.log ファイルに記録されます。

Sep 07 05:54:54  IPaddr2(ip-172.17.3.115)[209771]:    ERROR: IPv4 address collision 172.17.3.115 [DAD]
Sep 07 05:54:54  IPaddr2(ip-172.17.3.115)[209771]:    ERROR: Failed to add 172.17.3.115

今回の更新により、出力データ収集サービス (ceilometer) メトリクスにプロジェクト名フィールドとユーザー名フィールドを追加できるようになりました。これまでは、クラウド管理者はプロジェクトとユーザーの UUID に依存してテナントを識別する必要がありました。現在は、UUID ではなく、プロジェクトとユーザーの名前リストをを表示できるようになりました。

この機能拡張により、ユーザーは RHOSP 16.2 から RHOSP 17.1 にアップグレードし、RHEL 9 を実行しているノードと Red Hat Enterprise Linux (RHEL) 8 ベースのオペレーティングシステムの組み合わせを、Compute ノード上で維持できるようになります。

コントロールプレーンノードとストレージノードをアップグレードする必要があります。デフォルトの動作では、明示的に設定されていない限り、すべてのノードが RHEL 9 にアップグレードされます。

RHOSP のネットワーク環境では、仮想マシンインスタンスを作成する際に、インスタンスを仮想ポート (vport) にバインドしないでください。代わりに、IP アドレスが別のポートの許可するアドレスペアのメンバーではないポートを使用します。

vport をインスタンスにバインドすると、インスタンスが生成されなくなり、次のようなエラーメッセージが表示されます。

WARNING nova.virt.libvirt.driver [req-XXXX - - - default default] [instance: XXXXXXXXX] Timeout waiting for [('network-vif-plugged', 'XXXXXXXXXX')] for instance with vm_state building and task_state spawning.: eventlet.timeout.Timeout: 300 seconds

OVN メカニズムドライバーへの移行中に IPv6 を使用してインスタンスに接続する場合、ML2/OVS サービスが停止すると、インスタンスへの接続が最大数分間中断される可能性があります。これを回避するには、代わりに IPv4 を使用してください。

IPv6 のルーターアドバタイズメントデーモン radvd は、OVN メカニズムドライバーへの移行中に停止します。radvd が停止している間、ルーターアドバタイズメントはブロードキャストされません。このブロードキャストの中断により、IPv6 経由のインスタンス接続が失われます。新しい ML2/OVN サービスが開始されると、IPv6 通信は自動的に復元されます。

中断の可能性を回避するには、代わりに IPv4 を使用してください。

現時点において、ML2/OVS デプロイメントにおける Open vSwitch (OVS) は、skb_priority、skb_mark、または出力キューフィールドが設定されている OpenFlow ルールのオフロードをサポートしていません。これらのフィールドは、virtio ポートの Quality of Service (QoS) サポートに必要です。

virtio ポートに最小帯域幅ルールを設定すると、Networking サービス (neutron) OVS エージェントは、Packet Mark フィールドを使用してこのポートのトラフィックをマークします。その場合、このトラフィックはオフロードできず、他のポートのトラフィックに影響します。帯域幅制限ルールを設定すると、すべてのトラフィックがデフォルトの 0 キューでマークされます。これは、トラフィックをオフロードできないことを意味します。

回避策として、環境に OVS ハードウェアオフロードポートが含まれている場合は、ハードウェアオフロードが必要なノードでパケットマーキングを無効にします。パケットマーキングを無効にすると、virtio ポートのレート制限ルールは設定できなくなります。ただし、Differentiated Services Code Point (DSCP) のマーキングルールは引き続き使用できます。

設定ファイルで、disable_packet_marking フラグを true に設定します。設定ファイルを編集する場合、neutron_ovs_agent コンテナーを再起動する必要があります。以下に例を示します。

$ cat `/var/lib/config-data/puppet-generated/neutron/etc/neutron/plugins/ml2/openvswitch_agent.ini`
  [ovs]
  disable_packet_marking=True

RHOSP 17.1 では、DNS サービス (designate) がデプロイされている場合、オーバークラウドが削除されても、アンダークラウド上に作成された Networking サービス (neutron) ポートは削除されません。これらのポートは、DNS サービスの有無にかかわらず、オーバークラウドの再作成時に動作上の問題を引き起こしません。

回避策: オーバークラウドを削除した後、openstack port delete コマンドを使用してポートを手動で削除します。

BGP 動的ルーティングを使用する RHOSP 17.1 環境では、現在、Floating IP (FIP) ポート転送が失敗するという既知の問題があります。

FIP ポート転送が設定されている場合、FIP と同じ宛先 IP を持つ特定の宛先ポートに送信されたパケットは、RHOSP Networking サービス (neutron) ポートから内部 IP にリダイレクトされます。これは、使用されているプロトコル (TCP、UDP など) に関係なく発生します。

BGP 動的ルーティングが設定されている場合、FIP ポート転送の実行に使用される FIP へのルートは公開されず、これらのパケットは最終的な宛先に到達できません。

現在、回避策はありません。

Pacemaker によって制御される ceph-nfs リソースには、一部のプロセスデータを保存するためのランタイムディレクトリーが必要です。このディレクトリーは、RHOSP をインストールまたはアップグレードするときに作成されます。現在、コントローラーノードを再起動するとディレクトリーが削除され、コントローラーノードを再起動しても ceph-nfs サービスは回復しません。すべてのコントローラーノードが再起動されると、ceph-nfs サービスは永続的に失敗します。

回避策: コントローラーノードを再起動する場合は、コントローラーノードにログインして /var/run/ceph ディレクトリーを作成します。

$ mkdir -p /var/run/ceph

再起動されたすべてのコントローラーノードでこの手順を繰り返します。ceph-nfs-pacemaker サービスが失敗としてマークされている場合は、ディレクトリーを作成した後、いずれかのコントローラーノードから以下のコマンドを実行します。

$ pcs resource cleanup

現在、Logrotate はすべてのログファイルを 1 日に 1 回アーカイブし、Rsyslog は Elasticsearch へのログ送信を停止します。回避策: デプロイするときに環境ファイルに "RsyslogReopenOnTruncate: true" を追加して、Rsyslog がログローテーション時にすべてのログファイルを再度開くようにします。

現在、RHOSP 17.1 は、Rsyslog が正しく設定されていない古い puppet-rsyslog モジュールを使用しています。回避策: デプロイする前に、/usr/share/openstack-tripleo-heat-templates/deployment/logging/rsyslog-container-puppet.yaml のパッチ [1] を手動で適用して Rsyslog を正しく設定します。

現在、オフロード (switchdev) ポートを備えた Mellanox ConnectX-5、ConnectX-6、および Bluefield-2 NIC を使用するゲストインスタンスには既知の問題があります。たとえば、コマンド sudo systemctl reboot --reboot-arg=now を使用して、ゲストからオペレーティングシステムを直接再起動すると、システムの初期化に時間がかかります。インスタンスが同じ物理機能 (PF) の 2 つの仮想機能 (VF) で設定されている場合、VF の 1 つの初期化が失敗し、初期化時間が長くなる可能性があります。

回避策: ゲストインスタンスを直接再起動するのではなく、OpenStack API を使用してゲストインスタンスを適時に再起動します。

RHOSP 17.1 では、次の BIOS 設定を使用している場合、UEFI ブートモードを使用する一部の AMD プラットフォーム上での NFV デプロイメントで、オーバークラウドノードのプロビジョニングが失敗する場合があります。

DVR が有効で VLAN テナントネットワークを使用する ML2/OVN または ML2/OVS を備えた RHOSP 環境では、異なるテナントネットワークに接続されたインスタンス間の East/West トラフィックがファブリックにフラッディングされます。

その結果、それらのインスタンス間のパケットは、それらのインスタンスが実行されている Compute ノードだけでなく、他のオーバークラウドノードにも到達します。

これはネットワークに影響を与える可能性があり、ファブリックがトラフィックをあらゆる場所に送信するため、セキュリティー上のリスクとなる可能性があります。

このバグは、今後の FDP リリースで修正される予定です。FDP 修正を入手するために RHOSP 更新を実行する必要はありません。

現在、Dashboard サービス (horizon) はデフォルトでクライアント TLS 証明書を検証するように設定されているため、すべての TLS everywhere (TLS-e) デプロイメントでダッシュボードサービスが機能しません。

回避策:

現在、RHEL 9.2 の Retbleed 脆弱性軽減策により、Intel Skylake CPU 上の Data Plane Development Kit (OVS-DPDK) を使用した Open vSwitch のパフォーマンスが低下する可能性があります。

パフォーマンスの低下は、BIOS で C-states が無効、およびハイパースレッディングが有効になっており、さらに OVS-DPDK が特定のコアのハイパースレッドを 1 つだけ使用している場合にのみ発生します。

回避策: NFV 設定ガイドで推奨されているように、コアの両方のハイパースレッドを OVS-DPDK または DPDK が実行されている SRIOV ゲストに割り当てます。

セキュリティーグループの過剰なログエントリーをバッファーするロギングキューは、指定された制限に達する前にエントリーの受け入れを停止することがあります。回避策として、キューの長さを保持したいエントリー数よりも長く設定できます。

NeutronOVNLoggingRateLimit パラメーターを使用して、1 秒あたりのログエントリーの最大数を設定できます。ログエントリーの作成がそのレートを超える場合、超過分は NeutronOVNLoggingBurstLimit で指定したログエントリー数までキューにバッファーされます。

この問題は、バーストの最初の 1 秒で特に顕著です。60 秒などの長いバーストでは、レート制限の影響が大きくなり、バースト制限の不正確さを補填します。したがって、この問題は短いバーストに最大の比例負荷をもたらします。

回避策: NeutronOVNLoggingBurstLimit をターゲット値よりも高い値に設定します。経過を観察し、必要に応じて調整します。

OVN メカニズムドライバーを備えた RHOSP 17.1 は、ポートごとのフローイベントのロギングや、network log create コマンドの --target オプションの使用をサポートしていません。

RHOSP 17.1 は、network log create コマンドの --resource オプションを使用して、セキュリティーグループごとのフローイベントのロギングをサポートします。Red Hat OpenStack Platform ネットワークの設定 の「セキュリティーグループアクションのロギング」を参照してください。

RHOSP 17.1 GA では、セキュアなロールベースのアクセス制御 (sRBAC) が有効になっている場合、DNS サービス (designate) が誤って設定されます。現在の sRBAC ポリシーには、designate に関する誤ったルールが含まれているため、designate が正しく機能するには修正する必要があります。

回避策: アンダークラウドサーバーに次のパッチを適用し、オーバークラウドを再デプロイします。

https://review.opendev.org/c/openstack/tripleo-heat-templates/+/888159

RHOSP 17.1 には一時的なパケット損失の既知の問題があり、ハードウェア割り込み要求 (IRQ) が原因で OVS-DPDK PMD スレッドまたは DPDK アプリケーションを実行しているゲストで非自発的なコンテキストスイッチが発生します。

この問題は、デプロイメント中に多数の VF をプロビジョニングすると発生します。VF には IRQ が必要で、それぞれが物理 CPU にバインドされている必要があります。IRQ の容量を処理するのに十分なハウスキーピング CPU がない場合、irqbalance はすべての IRQ のバインドに失敗し、分離された CPU で IRQ がオーバーフローします。

回避策: 次のアクションを 1 つ以上試してください。

現在、ブートストラップコントローラーノードが交換されると、OVN データベースクラスターはパーティション化され、2 つのデータベースクラスターがノースバウンドデータベースとサウスバウンドデータベース用に作成されます。この状況ではインスタンスが使用できなくなります。

ブートストラップコントローラーノードの名前を確認するには、次のコマンドを実行します。

ssh tripleo-admin@CONTROLLER_IP "sudo hiera -c /etc/puppet/hiera.yaml pacemaker_short_bootstrap_node_name"

回避策: Red Hat KCS ソリューション 7024434: Recover from partitioned clustered OVN database で説明されている手順を実行します。

現在、以下のデプロイメントアーキテクチャーでは Multi-RHEL はサポートされていません。

RHOSP 16.2 から 17.1 GA へのインプレースアップグレードを実行する際の既知の問題があります。収集エージェント collectd-sensubility は、RHEL 8 Compute ノードで実行できません。

回避策: 影響を受けるノードでファイル /var/lib/container-config-scripts/collectd_check_health.py を編集し、26 行目の "healthy: .State.Health.Status}" を "healthy: .State.Healthcheck.Status}"/ に置き換えます。

ML2/OVN メカニズムドライバーを使用する RHOSP 17.1 GA 環境では、Floating IP ポート転送が正しく機能しないという既知の問題があります。この問題は、FIP 使用時に VLAN およびフラットネットワークが north-south ネットワークトラフィックを分散させ、代わりに FIP ポート転送をコントローラーノードまたはネットワーカーノードに集中させる必要があるために発生します。

回避策: この問題を解決し、集中型ゲートウェイノード経由で FIP ポート転送を強制するには、RHOSP オーケストレーションサービス (heat) パラメーター NeutronEnableDVR を false に設定するか、VLAN またはフラットプロジェクトネットワークの代わりに Geneve を使用します。

この RHOSP リリースには、iavf ドライバーで Intel X710 および E810 シリーズのコントローラー仮想機能 (VF) を使用する SR-IOV インターフェイスで、リンクステータスのフラッピングを伴うネットワーク接続の問題が発生する可能性があるという既知の問題があります。影響を受けるゲストカーネルのバージョンは次のとおりです。

現在、ボリュームに Red Hat Ceph Storage (RHCS) バックエンドを使用すると、インスタンスの再起動が妨げられ、データ破損につながる可能性があるという既知の問題があります。これは、次の条件がすべて満たされる場合に発生します。

回避策: 上記の条件をすべて満たす in-use ボリュームの種別は変更しないでください。

メタデータエージェントが誤動作している HAProxy 子コンテナーを起動しようとして複数回失敗すると、メタデータサービスが利用できなくなることがあります。メタデータエージェントは、`ProcessExecutionError: Exit code: 125; Stdin: ; Stdout: Starting a new child container neutron-haproxy-ovnmeta-<uuid>” のようなエラーメッセージをログに記録します。

回避策: podman kill <_container name_> を実行して、問題のある haproxy 子コンテナーを停止します。

RHOSP 17.1.0 GA を入手可能になった時点から数日以内にダウンロードすると、次の例に示すように、/etc/rhosp/release ファイル内のバージョン説明に誤ってベータ指定が含まれている場合があります。

(overcloud) [stack@undercloud-0 ~]$ cat /etc/rhosp-release
Red Hat OpenStack Platform release
17.1.0 Beta (Wallaby)

回避策: 使用している GA デプロイメントが影響を受ける場合は、# dnf -y update rhosp-release コマンドを実行します。

RHOSP 17.1.0 GA を入手可能になった時点から数日以内にダウンロードすると、次の例に示すように、/etc/rhosp/release ファイル内のバージョン説明に誤ってベータ指定が含まれている場合があります。

(overcloud) [stack@undercloud-0 ~]$ cat /etc/rhosp-release
Red Hat OpenStack Platform release
17.1.0 Beta (Ussri)

回避策: 使用している GA デプロイメントが影響を受ける場合は、# dnf -y update rhosp-release コマンドを実行します。

ML2/OVS メカニズムドライバーは、RHOSP 17.0 以降で非推奨になりました。

いくつかのリリースで、Red Hat は ML2/OVS を ML2/OVN に置き換えています。たとえば、RHOSP 15 以降では、ML2/OVN がデフォルトのメカニズムドライバーになりました。

非推奨の ML2/OVS メカニズムドライバーは、RHOSP 17 リリースでサポートされます。この間、ML2/OVS ドライバーはメンテナンスモードのままで、バグ修正と通常のサポートを受け、ほとんどの新機能開発は ML2/OVN メカニズムドライバーで行われます。

RHOSP 18.0 では、Red Hat は ML2/OVS メカニズムドライバーを完全に削除し、サポートを停止する予定です。

既存の RHOSP デプロイメントで ML2/OVS メカニズムドライバーを使用している場合は、今すぐメカニズムドライバーの移行計画の評価を開始してください。移行は、RHOSP 16.2 および RHOSP 17.1 でサポートされています。

ML2/OVS から ML2/OVN への移行を試みる前に、プロアクティブケースを作成する必要があります。プロアクティブケースを作成しない場合、Red Hat では移行をサポートしません。How to open a proactive case for a planned activity on Red Hat OpenStack Platform? を参照してください。

sensubility を使用して Podman 経由で行う API ヘルスステータスのモニタリングは、RHOSP 17.1 で非推奨になりました。

sensubility レイヤーのみが非推奨になりました。API ヘルスチェックは引き続きサポートされます。sensubility レイヤーは、サポート対象外となった Sensu とのインターフェイスとして存在しています。