リリースノート

OpenStackControlPlane カスタムリソース (CR) の nova セクションで notificationsBusInstance が RabbitMqCluster CR を指すように設定されている場合、そのクラスター内の Pod が再起動されると、nova-operator のバグにより、nova-operator はすべての Compute サービスを 2 回再設定します。これにより、不必要なサービス停止時間が発生します。

回避策:

Jira:OSPRH-17569

os_version プロパティーまたは os_admin_user プロパティーが設定に含まれていても、イメージプロパティーの重み付け関数は生の重みの計算時にそれらのプロパティーを考慮しません。

回避策: 現時点では回避策はありません。

Jira:OSPRH-17569

Compute サービス (nova) の電源管理機能は、デフォルトでは無効になっています。

回避策: この機能は、以下の nova-compute 設定で有効にできます。

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

デフォルトの cpu_power_management_strategy cpu_state は現在サポートされていません。nova-compute を再起動すると、そのホスト上のすべての専用 PCPU (インスタンスが使用しているものも含む) の電源がオフになります。cpu_state ストラテジーを使用すると、それらのインスタンスの CPU は固定が解除されます。

Jira:OSPRH-10772

今回のアップデート以前は、サブネットを最初に作成した後、データプレーンノードのゲートウェイ IP アドレスを変更することはできませんでした。今回のアップデートにより、初期サブネット作成後、必要に応じてデータプレーンノードのゲートウェイ IP アドレスを変更できるようになりました。詳細は、デプロイ済みデータプレーンノードのネットワーク設定の更新 参照してください。

Jira:OSPRH-17569

今回のアップデート以前は、OVN データベース同期ツールである neutron-ovn-db-sync-util が、常に `ValueError: driver cannot be None` という警告を報告していました。この警告は、RHOSO 18.0.17 で導入されたリグレッションにより、OVN データベース同期ツールが OVN サウスバウンドデータベース (SB DB) を同期できないことが原因でした。

今回のアップデートにより、リグレッションの不具合が修正され、neutron-ovn-db-sync-util が OVN SB DB と正しく同期するようになりました。

Jira:OSPRH-17569

今回のアップデート以前は、OVN データベース同期ツールである neutron-ovn-db-sync-util が、No providers specified for 'FIREWALL_V2' service, exiting というエラーを報告してクラッシュするという既知の問題がありました。

今回のアップデートにより、neutron-fwaas がサービスプロバイダーを正しく設定するようになりました。その結果、neutron-ovn-db-sync-util ツールが firewall_v2 サービスプラグインを有効にした状態で実行され、クラッシュすることなく OVN データベースと neutron データベースを同期するようになりました。

Jira:OSPRH-17569

RHOSO 18.0 では、BGP を使用する動的ルーティング環境で RHOSO DNS サービス (designate) がサポートされていません。designate-worker Pod が designate-backendbind9 Pod を設定できないため、結果として DNS サービスが正常に動作しません。この原因は、ワーカー Pod が共通のネットワークアタッチメント定義と共通のサブネット範囲を使用してバックエンドの BIND 9 Pod に接続しようとすることにあります。これは BGP が設定されている場合は正常に機能しません。BGP 環境では、Pod 同士が接続する際に異なるサブネット範囲を使用する必要があるためです。回避策: 既知の回避策はありません。

Jira:OSPRH-17569

ファイアウォールルールが 1 つしか設定されていない場合、ネットワークトラフィックが誤って送受信されるという既知の問題があります。この問題は、Firewall as a service (FWaaS) を使用し、セキュリティーグループを有効にした場合に発生する可能性があります。FWaaS は、2 つのルールが設定されている場合にのみ、受信トラフィックまたは送信トラフィックを許可する必要があります。

回避策: 現時点では回避策はありません。

Jira:OSPRH-17569

mac_binding_age_threshold のデフォルト値は 300 です。コア OVN のバグ [1] が修正されるまで、mac_binding_age_threshold を 0 に設定する必要があります。コア OVN のパッチがリリースされ、パッチを RHOSO 18.0 に組み込んだ後、mac_binding_age_threshold を 300 にリセットする必要があります。

このバグにより、OVN はローカルネットワークに接続されているすべてのポートに対して、Address Resolution Protocol (ARP) メッセージと近隣探索プロトコル (ND) メッセージを送信してしまいます。別のシャーシにある Logical_Router ポートがゲートウェイ IP を検出すると、MAC_Binding レジスターが作成され、誤った MAC アドレスを含む ARP/ND が返信されます。これにより、外部のスイッチやルーターで混乱が発生します。

[1] https://github.com/ovn-org/ovn/commit/215b0a1e314e941b309e9b84c7679cc3e8b28a48

Jira:OSPRH-28764

RHOSO 18.0.17 では、Ceilometer のコンピュートエージェントである ceilometer_agent_compute が起動に失敗します。これは、データプレーンが Ceilometer prometheus_exporter 用の TLS 証明書をプロビジョニングしないために発生します。その結果、Prometheus がデータプレーンノード上の Ceilometer コンピュートエージェントからメトリクスを収集できなくなります。

回避策: OpenStackControlPlane CR で、不足しているプロパティーを customServiceConfig として設定します。

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack-control-plane
spec:
  telemetry:
    template:
      ceilometer:
        customServiceConfig: |
          [service_credentials]
          cafile = /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

Jira:OSPRH-17569

今回のアップデート以前は、node_exporter のボリュームメトリクスが node_exporter コンテナーのディスクのみを報告していました。これは、node_exporter がローカルのルートディスクをマウントしないことが原因でした。

今回のアップデートにより、node_exporter がコンテナーに rootfs をマウントするようになり、ディスクのメトリクスがコンテナーではなくノードのデータを正しく反映するようになりました。

Jira:OSPRH-17569

OpenStack Optimize サービスは、マルチ RHEL (Red Hat Enterprise Linux) モードではサポートされていません。Optimize サービスをマルチ RHEL モードで実行すると、特に RHEL 9.2 および RHEL 9.4 で稼働しているコンピュートノードでサービス障害が発生します。

回避策: 現時点では回避策はありません。

Jira:OSPRH-17569

RHOSO 18.0.18 では、barbican-operator が、namespace 内で Secret イベントが発生するたびに、ERROR レベルのログメッセージを継続的に生成します。このログメッセージは、フィールド .spec.pkcs11.clientDataSecret のインデックスが不足していることを示しています。この問題は表示上の問題にすぎず、機能には影響しません。すべての Barbican サービス (API、Worker、KeystoneListener) は正常に動作しており、すべての子コントローラーもシークレットの変更を正しく検出します。

回避策: 現時点では回避策はありません。

Jira:OSPRH-17569

RHCS 8.x から RHCS 9.0.1 にアップグレードすると、アップグレード完了後に CephFS-NFS サービスが起動せず、すべてのクライアントから利用できなくなります。RHOSO デプロイメントで CephFS-NFS と RHCS 8.x を使用している場合は、修正が利用可能になるまで RHCS のアップグレードを延期してください。

回避策: 現時点では回避策はありません。

Jira:OSPRH-17569

設定されたイメージサイズの制限 (image_size_total) より大きいイメージを Image サービス (glance) にアップロードすると、Image サービスはアップロード前にイメージサイズを検証しないため、アップロードは成功します。イメージがアップロードされ保存されると、Image サービスはイメージサイズを把握しますが、場合によってはクォータを超過しています。クォータを超過していれば、Image サービスは後続のアップロードを拒否します。

回避策: 現時点では回避策はありません。

Jira:OSPRH-17569

デフォルトでは、ライブマイグレーションは 1 つのネットワーク接続を使用してインスタンスを宛先のコンピュートノードに転送します。シングルスレッドの TLS 処理速度などの要因により、パフォーマンスが制限される可能性があります。移行の速度を向上させるには、ライブマイグレーションごとに複数の接続を有効にしてください。

Jira:RHOSSTRAT-89

PCI パススルーを使用する NVMe デバイスを、実行中のインスタンスを中断したり、データプレーンホストに影響を与えたりすることなく、物理的に交換できます。

Jira:RHOSSTRAT-89

OpenStackControlPlane カスタムリソース (CR) の nova セクションで notificationsBusInstance が RabbitMqCluster CR を指すように設定されている場合、そのクラスター内の Pod が再起動されると、nova-operator のバグにより、nova-operator はすべての Compute サービスを 2 回再設定します。これにより、不必要なサービス停止時間が発生します。

一時的な回避策:

Jira:OSPRH-17569

os_version プロパティーまたは os_admin_user プロパティーが設定に含まれていても、イメージプロパティーの重み付け関数は生の重みの計算時にそれらのプロパティーを考慮しません。

Jira:OSPRH-17569

Compute サービス (nova) の電源管理機能は、デフォルトでは無効になっています。次の nova-compute 設定でこれを有効にできます。

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

デフォルトの cpu_power_management_strategy cpu_state は現在サポートされていません。nova-compute を再起動すると、そのホスト上のすべての専用 PCPU (インスタンスが使用しているものも含む) の電源がオフになります。cpu_state ストラテジーを使用すると、それらのインスタンスの CPU は固定が解除されます。

Jira:OSPRH-10772

今回のアップデート以前は、ノードセットが空の場合、マイナーアップデートのプロセスが完了しないという問題が発生していました。今回のアップデートにより、ノードセットが空であっても、マイナーアップデートのプロセスが正常に完了するようになりました。

Jira:OSPRH-17569

今回のアップデート以前は、コントロールプレーンのルートが失敗した場合、そのルートが OpenStackControlPlane CR の conditions リストに含まれていなかったため、根本原因の特定が困難でした。今回のアップデートにより、OpenStackControlPlane CR の conditions リストにルートのステータスが追加されました。

Jira:OSPRH-17569

Red Hat OpenStack Services on Openshift (RHOSO) は、プロビジョニングされていないデータプレーンノードのプロビジョニングに metal3 を使用します。bootMacAddress を更新できないノードを置き換える必要がある場合、エラー状態が発生します。その結果、ノードは、デプロイメントから完全に削除され、新しいノードと同じようにプロビジョニングされなければならない状態に陥ります。automatedCleaningMode 属性が automatedCleaningMode: disabled に設定されている場合、このエラー状態は発生しません。

回避策: プロビジョニングされていないデータプレーンノードをプロビジョニングする場合は、必ず automatedCleaningMode 属性を automatedCleaningMode:disabled に設定します。

Jira:OSPRH-17569

デフォルトでは、RabbitMQ クラスターは、若干のレイテンシー増加と引き換えにデータの安全性と可用性を向上させるために、新しい RHOSO デプロイメントに Quorum キューを使用します。

Jira:OSPRH-17569

RHOSO 18.0.17 (機能リリース 5) 以降では、各 RabbitMQ Pod と個別に通信することで、一時的な RabbitMQ の問題に適切に対処できるようにサービスを設定することにより、サービスの可用性を向上できます。

そのためには、次の例に示すように podOverride セクションを追加して、各 Pod を専用の IP アドレスを使用して個別に公開するように RabbitMQ クラスターを設定できます。

rabbitmq:
  delayStartSeconds: 30
  override:
    service:
      metadata:
        annotations:
          metallb.universe.tf/address-pool: internalapi
          metallb.universe.tf/loadBalancerIPs: 172.17.0.80
      spec:
        type: LoadBalancer
  podOverride:
    services:
    - metadata:
        annotations:
          metallb.universe.tf/address-pool: internalapi
          metallb.universe.tf/loadBalancerIPs: 172.17.0.81
      spec:
        type: LoadBalancer
    - metadata:
        annotations:
          metallb.universe.tf/address-pool: internalapi
          metallb.universe.tf/loadBalancerIPs: 172.17.0.82
      spec:
        type: LoadBalancer
    - metadata:
        annotations:
          metallb.universe.tf/address-pool: internalapi
          metallb.universe.tf/loadBalancerIPs: 172.17.0.83
      spec:
        type: LoadBalancer
  persistence:     storage: 10Gi

コントロールプレーンにこの変更を適用した後、すべてのコンピュートノードを更新するためにデータプレーンを再デプロイする必要があります。

Jira:OSPRH-17569

RHOSO 18.0.17 (機能リリース 5) 以降では、RHOSO ネットワーク操作の特定の状況を通知するアラートを作成および管理できます。

詳細は、オブザーバビリティーの設定 の ネットワークアラート を参照してください。

Jira:RHOSSTRAT-89

switchdev モードが有効な場合、os-net-config の ifcfg プロバイダーから Nmstate プロバイダーに移行することはできません。

回避策: Nmstate プロバイダーに移行する前に、switchdev モードを無効にします。

Jira:OSPRH-17569

RHOSO 18 をベースにした並列コントロールプレーンをデプロイし、コンピュートノードを新しいコントロールプレーンに接続することで、OpenStack デプロイメントの RHOSP 17.1 から RHOSO 18 へのインプレースアップグレードを実行できるようになりました。詳細は、Red Hat OpenStack Platform 17.1 デプロイメントの導入 を参照してください。

Jira:RHOSSTRAT-89

director によってデプロイされた Load-balancing サービス (Octavia) のコントロールプレーンサービスを、Red Hat OpenStack Platform 17.1 から Red Hat OpenStack Services on OpenShift (RHOSO) 18.0 へ導入できるようになりました。この機能により、既存の設定を維持し、新しい RHOSO 環境でシームレスな動作を確保できます。

Load-balancing サービスの導入に関する詳細は、Red Hat OpenStack Platform 17.1 デプロイメントの導入 の Load-balancing サービスの導入 を参照してください。

Jira:RHOSSTRAT-89

今回のアップデート以前は、neutron-fwaas ドライバーとログ API プラグインの両方を使用して RHOSO をデプロイすると、ログ作成の失敗がエンドユーザーに発生していました。この問題は修正され、neutron-fwaas ドライバーとログ API プラグインの両方を同じ neutron デプロイメントでデプロイできるようになりました。RHOSO 18.0.17 機能リリース 5 では、Firewall as a Service はテクノロジープレビューであることにご注意ください。

Jira:OSPRH-17569

RHOSO 18.0.17 (機能リリース 5) では、テクノロジープレビューとして、DNS サービス (designate) のデータプレーン導入をテストできます。テクノロジープレビュー機能は実稼働環境で使用しないでください。

Jira:RHOSSTRAT-89

OVN データベース同期ツール neutron-ovn-db-sync-util が常に ValueError: driver cannot be None という警告を報告する既知の問題があります。この警告は、RHOSO 18.0.17 で導入されたリグレッションにより、OVN データベース同期ツールが OVN サウスバウンドデータベース (SB DB) を同期できないことが原因でした。

回避策: 引数 --sync_plugin neutron_nb_sync を使用して、OVN ノースバウンドデータベースでのみ同期ツールを実行します。

例

$ oc rsh -n openstack -c neutron-api deploy/neutron \
neutron-ovn-db-sync-util --config-file \
/usr/share/neutron/neutron-dist.conf --config-file \
/etc/neutron/neutron.conf --config-dir /etc/neutron/neutron.conf.d \
--ovn-neutron_sync_mode=log --debug --sync_plugin neutron_nb_sync

この回避策では、SB DB に対して同期ツールは実行されません。したがって、以下のチェックは実行されません。

Jira:OSPRH-17569

OVN データベース同期ツールである neutron-ovn-db-sync-util が、No providers specified for 'FIREWALL_V2' service, exiting というエラーを報告してクラッシュするという既知の問題があります。この警告は、RHOSO 18.0.17 で導入されたリグレッションが原因です。

回避策: この問題は、service_providers 設定変数に FIREWALL_V2 という値を指定するか、必要なプラグインを個別に実行することで回避できます。

例

$ oc rsh -n openstack -c neutron-api deploy/neutron \
neutron-ovn-db-sync-util --config-file \
/usr/share/neutron/neutron-dist.conf --config-file \
/etc/neutron/neutron.conf --config-dir /etc/neutron/neutron.conf.d \
--ovn-neutron_sync_mode=log --sync_plugin neutron_nb_sync --debug

この回避策では、SB DB に対して同期ツールは実行されません。したがって、以下のチェックは実行されません。

Jira:OSPRH-17569

RHOSO 18.0 では、BGP を使用する動的ルーティング環境で RHOSO DNS サービス (designate) がサポートされていません。designate-worker Pod が designate-backendbind9 Pod を設定できないため、結果として DNS サービスが正常に動作しません。この原因は、ワーカー Pod が共通のネットワークアタッチメント定義と共通のサブネット範囲を使用してバックエンドの BIND 9 Pod に接続しようとすることにあります。これは BGP が設定されている場合は正常に機能しません。BGP 環境では、Pod 同士が接続する際に異なるサブネット範囲を使用する必要があるためです。回避策: 既知の回避策はありません。

Jira:OSPRH-17569

ファイアウォールルールが 1 つしか設定されていない場合、ネットワークトラフィックが誤って送受信されるという既知の問題があります。この問題は、Firewall as a service (FWaaS) を使用し、セキュリティーグループを有効にした場合に発生する可能性があります。FWaaS は、2 つのルールが設定されている場合にのみ、受信トラフィックまたは送信トラフィックを許可する必要があります。

回避策: 現時点では回避策はありません。

Jira:OSPRH-17569

RHOSO 管理者は、Telemetry Operator で Rating サービス (cloudkitty) を有効にすることで、RHOSO クラウドにチャージバックおよび料金計算機能を提供できます。

Rating サービスは、RHOSO Telemetry サービスからデータを収集し、料金計算レポートを通じてクラウドのリソース使用状況を生成します。このレポートは、外部の財務業務システムや請求システムで利用できます。Rating サービスは請求用のインターフェイスは備えていません。

Jira:RHOSSTRAT-89

metrics.yaml 設定ファイルは、RHOSO クラウドで収集する料金計算メトリクスを定義するもので。今回のアップデート以前は、Rating サービスが機能していませんでした。これは、デフォルトの metrics.yaml 設定ファイルが、サポートされていない Gnocchi コレクター用に設定されていたためです。今回のアップデートにより、サポートされているコレクターである Prometheus によって収集されるメトリクスを定義するように、デフォルトの metrics.yaml ファイルが更新されました。

Jira:OSPRH-17569

今回のアップデート以前は、サマリー API からクラウド管理者に空のサマリーが送信されていました。これは、Summary API で使用されるキーが "project_id" という文字列にハードコーディングされており、デフォルトのキー "project" と一致してなかったためです。今回のアップデートにより、キーが設定可能になり、クラウド管理者はサマリー生成に使用するキーを指定できるようになりました。

Jira:OSPRH-17569

今回のアップデート以前は、autoscaling コントローラーが、パスワードの変更や TLS 証明書の変更など、Alarming サービス (aodh) リソースへの変更に反応していませんでした。これにより、変更を適用するために aodh Pod が再起動されず、aodh Pod は古い設定またはデータを使用し続けていました。今回のアップデートにより、autoscaling コントローラーは、Alarming サービスの変更を監視し、その変更に反応して、必要に応じて aodh Pod を再起動してリソースを更新し、最新のデータを利用するようになりました。

Jira:OSPRH-17569

今回のアップデート以前は、Ceilometer サービス用に設定されたトポロジーが、mysqld-exporter または kube-state-metrics エージェントに適用されていませんでした。今回のアップデートにより、Ceilometer サービス用にトポロジーを設定すると、それが mysqld-exporter および kube-state-metrics エージェントに適用されるようになりました。

Jira:OSPRH-17569

今回のアップデート以前は、Ceilometer サービス用に設定されたトポロジーが適用されていませんでした。これは、service ラベルに "metricStorage" という誤った値が割り当てられていたためです。今回のアップデートにより、Ceilometer リソースの service ラベルが正しい値に設定されるようになりました。

Jira:OSPRH-17569

今回のアップデート以前は、Prometheus が期待どおりにすべての RabbitMQ ノードからメトリクスを収集していませんでした。その代わりに、一度に 1 つのノードからしかメトリクスを収集していませんでした。そのノードの選択は予測不能なものでした。

現在、Prometheus は期待どおりにすべての RabbitMQ ノードからメトリクスを収集します。

Jira:OSPRH-17569

RHOSO 18.0.17 では、Ceilometer のコンピュートエージェントである ceilometer_agent_compute が起動に失敗します。これは、データプレーンが Ceilometer prometheus_exporter 用の TLS 証明書をプロビジョニングしないために発生します。その結果、Prometheus がデータプレーンノード上の Ceilometer コンピュートエージェントからメトリクスを収集できなくなります。

回避策: OpenStackControlPlane CR で、不足しているプロパティーを customServiceConfig として設定します。

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack-control-plane
spec:
  telemetry:
    template:
      ceilometer:
        customServiceConfig: |
          [service_credentials]
          cafile = /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

Jira:OSPRH-17569

OpenStack Optimize サービスは、マルチ RHEL (Red Hat Enterprise Linux) モードではサポートされていません。Optimize サービスをマルチ RHEL モードで実行すると、特に RHEL 9.2 および RHEL 9.4 で稼働しているコンピュートノードでサービス障害が発生します。

Jira:OSPRH-17569

RHOSO 18 では、watcher_applier.rollback_when_actionplan_failed 設定オプションを有効にして、Action Plan が失敗した際に (失敗したアクションを) 自動的に元に戻すよう設定した場合でも、Optimize サービス (watcher) の Engine は、失敗したアクションを自動的に元に戻しません。

回避策: Action Plan で失敗した各アクションを手動で元に戻します。ロールバックを回避するには、失敗の根本原因を診断して修正し、監査を再度実行して新しい解決策を提案します。

Jira:OSPRH-19735

RHOSO の Single Keystone Multiple OpenStacks (SKMO) マルチリージョンデプロイメントは、複数のリージョンのユーザー管理と設定を簡素化します。

標準的なマルチリージョン RHOSO デプロイメントでは、各リージョンが独自の Identity (keystone) サービスと Dashboard (horizon) サービスを持ち、それぞれ分離されています。そのため、リージョンごとに個別のユーザーアカウントが必要となり、認証情報の管理やローテーションが困難になります。

Single Keystone Multiple OpenStacks (SKMO) マルチリージョンデプロイメントにより、管理者は一元的な Dashboard (horizon) と Identity (keystone) サービスを作成し、ユーザーの設定と管理を簡素化するための単一の管理画面 (single pane of glass) を提供できます。各エンドユーザーは単一の認証情報セットを持ち、全 workload リージョンへのエンドユーザーのアクセス権を、central リージョンで有効または無効にできます。

SKMO のデプロイメントに関する詳細は、セキュリティーサービスの設定 の Single Keystone Multiple OpenStacks デプロイメント を参照してください。

Jira:RHOSSTRAT-89

RHOSO 18.0.17 (機能リリース 5) では、テクノロジープレビューとして、Proteccio のハードウェアセキュリティーモジュール (HSM) との統合による Key Manager サービス (barbican) のデータプレーン導入をテストできます。テクノロジープレビュー機能は実稼働環境で使用しないでください。

Jira:RHOSSTRAT-89

RHOSO 18.0.17(機能リリース 5) では、テクノロジープレビューとして、near Zero Downtime Password Rotation (nZDPR) をテストできます。nZDPR は、RHOSO における認証情報の更新によって通常発生するサービスの中断を解消します。標準的なユーザー認証情報による認証は、伝播中に失敗することがよくあります。一方、nZDPR は設定可能な猶予期間を提供するアプリケーション認証情報を使用します。移行期間中は、旧認証情報と新認証情報の両方が同時に有効な状態が維持されます。これにより、厳格なセキュリティーコンプライアンスを遵守しつつ、コントロールプレーンとデータプレーン全体で継続的なサービス可用性を確保できます。詳細は、OpenStack サービスのアプリケーション認証情報について を参照してください。

Jira:RHOSSTRAT-89

この機能拡張により、外部の Red Hat Ceph Storage 9 との統合のサポートが追加されます。

アクティブ/アクティブ (A/A) 構成の CephFS-NFS デプロイメントでは、フェイルオーバーを正常に実行するために、Ceph Storage クラスター内に少なくとも 1 つのスタンバイノードを確保してください。CephFS-NFS の自動リカバリーが必要な環境であっても、追加のスタンバイ容量がない場合は、アクティブ/パッシブ (A/P) モードを使用してください。A/A のフェイルオーバーリカバリーは、Red Hat Ceph Storage 9.1 で強化される予定です。

CephFS-NFS を使用しており、Red Hat Ceph Storage 8.x から 9.0.1 へのアップグレードを予定している場合は、「既知の問題」セクションを参照してください。

Jira:RHOSSTRAT-89

iSCSI デーモン (iscsid) とマルチパスデーモン (multipathd) が、コンテナー内ではなく、データプレーンホストシステム上で直接実行されるようになりました。この変更により、iSCSI ディスクからの起動などの追加機能が利用可能になります。iSCSI マルチパス機能は、新規および既存のデプロイメントの両方で従来どおり動作します。

Jira:RHOSSTRAT-89

Red Hat OpenStack Services on OpenShift への導入において、FC を使用した Block Storage サービスをバックエンドとして使用するように設定されたサービスがサポートされるようになりました。Block Storage サービスの導入に関する詳細は、Red Hat OpenStack Platform 17.1 デプロイメントの導入 の Block Storage サービスの導入に向けた RHOCP の準備 を参照してください。

Jira:RHOSSTRAT-89

Red Hat OpenStack Platform (RHOSP) 17.1 分散コンピュートノード (DCN) デプロイメントを、RHOSO 18 に導入できるようになりました。導入手順では、TripleO スタックをサイト固有のネットワーク設定を持つデータプレーンのノードセットにマッピングします。今回のアップデートにより、Red Hat Ceph Storage を備えたエッジサイトを含む DCN デプロイメントと、ストレージを備えていないエッジサイトを含むデプロイメントがサポートされるようになりました。

Jira:RHOSSTRAT-89

今回のアップデートにより、管理者は、Shared File Systems サービス (manila) で、共有用サーバー管理機能 (driver_handles_share_servers を True に設定) とともに NetApp ONTAP ドライバーを使用する場合に、共有のデフォルトの保持期間を設定できるようになります。

ONTAP ファームウェアバージョン 9.11 以降では、ボリューム保持がデフォルトで有効になっています。しかし、これはすべてのクラウドユースケースに適しているとは限りません。netapp_delete_retention_hours 設定オプションを使用して、削除された共有がストレージシステム上で完全に削除されるまでの時間を時間単位で指定してください。保持を無効にするには、設定オプションを 0 に設定します。このオプションは、Shared File Systems サービスが共有用サーバーのライフサイクルを管理する場合にのみ適用されます。

Jira:OSPRH-17569

今回のアップデート以前は、クォータ制限を -1 (無制限) に設定して大容量ボリュームを作成しようとすると、データベースの整数制限が原因でクォータ予約のオーバーフローが発生していました。これにより、データベースエラーが原因でユーザーが新しいボリュームを作成できなくなる事態が発生していました。今回のアップデートにより、データベースエラーを防止し、ボリューム操作を正常に完了できるように、Block Storage サービス (cinder) にクォータオーバーフロー検出機能が追加されました。

Jira:OSPRH-17569

今回のアップデート以前は、スナップショットを含む NFS ボリュームのサイズを変更すると、アクティブなイメージファイルの仮想サイズが更新されず、Block Storage サービス (cinder) データベースと実際のイメージサイズとの間に不一致が生じていました。今回のアップデートにより、NFS ドライバーがスナップショットを伴うサイズ変更操作中に、Block Storage サービスデータベースとアクティブイメージの仮想サイズの両方が更新されるようになりました。

Jira:OSPRH-17569

今回のアップデート以前は、openstack image set --project <project_id> --accept <image_id> を使用して共有イメージを受け入れると、イメージの所有権が誤って受け入れ側のプロジェクトに移転されていました。元のイメージ所有者は、イメージへのアクセス権を失っていました。今回のアップデートにより、共有イメージを受け入れたときに、メンバーシップのステータスのみが更新され、元のイメージの所有権は保持されるようになりました。

Jira:OSPRH-17569

今回のアップデート以前は、AWS シークレットアクセスキーにスラッシュ (/) が含まれている場合、認証情報のローテーションによってデータベース内の URL が破損する可能性がありました。URL パーサーがスラッシュをパス区切り文字として誤って解釈していたため、S3 イメージのダウンロードが認証エラーで失敗する問題が発生していました。今回のアップデートにより、Image サービス (glance) がこのような URL を正しく解析するようになりました。

Jira:OSPRH-17569

今回のアップデート以前は、iSCSI マルチパスストレージを備えたデータプレーンノード上でインスタンスを繰り返し停止および起動すると、インスタンスの起動が頻繁に失敗していました。この問題は、ボリュームの接続解除と再接続操作の間で競合状態が発生するために発生していました。今回のアップデートにより、これらの操作におけるマルチパスデバイスの管理が改善され、iSCSI マルチパスが有効なストレージを使用している場合でも、インスタンスの起動が正常に完了するようになりました。

Jira:OSPRH-17569

今回のアップデート以前は、/dev/ でブロックデバイスが利用できない場合、ディスクイメージ変換ユーティリティー (qemu-img convert) は、宛先デバイスが存在するかどうかを確認せずにデータを作成して書き込んでいました。その結果、利用できないデバイスにファイルが書き込まれ、データ損失が発生していました。今回のアップデートにより、qemu-img convert を実行する前に宛先デバイスの存在を確認する機能が追加されました。これにより、ブロックデバイスが利用できない場合に /dev/ にファイルが作成されることが防止されます。

Jira:OSPRH-17569

今回のアップデート以前は、RHOSO 18 データプレーンの論理ボリューム管理 (LVM) デバイス管理に使用される RHEL system.devices ファイルが常に存在するとは限りませんでした。LVM フィルタリングによって Block Storage サービス (cinder) ボリュームをマスクするには、このファイルが存在している必要があります。今回のアップデートにより、system.devices ファイルが存在しない場合は作成されるようになりました。

Jira:OSPRH-17569

今回のアップデート以前は、project-id 引数が指定されていない場合、cinder-manage quota check および cinder-manage quota sync コマンドが失敗し、Block Storage サービス (cinder) での正確なクォータ管理が妨げられていました。今回のアップデートにより、クォータ管理コマンドのエラーが修正されました。これにより、project-id 引数が指定されていない場合でも、クォータ使用量が正確に管理されるようになりました。

Jira:OSPRH-17569

RHCS 8.x から RHCS 9.0.1 にアップグレードすると、アップグレード完了後に CephFS-NFS サービスが起動せず、すべてのクライアントから利用できなくなります。RHOSO デプロイメントで CephFS-NFS と RHCS 8.x を使用している場合は、修正が利用可能になるまで RHCS のアップグレードを延期してください。

Jira:OSPRH-17569

設定されたイメージサイズの制限 (image_size_total) より大きいイメージを Image サービス (glance) にアップロードすると、Image サービスはアップロード前にイメージサイズを検証しないため、アップロードは成功します。イメージがアップロードされ保存されると、Image サービスはイメージサイズを把握しますが、場合によってはクォータを超過しています。クォータを超過していれば、Image サービスは後続のアップロードを拒否します。

Jira:OSPRH-17569

OpenStack サービスコンテナーと Red Hat Enterprise Linux (RHEL) パッケージを個別に更新することで、更新プロセスをより詳細に制御できます。問題を特定のパッケージに絞り込むことで、問題の特定とトラブルシューティングが容易になり、更新中のダウンタイムを短縮できます。

RHEL 9.2、9.4、または 9.6 を実行している Red Hat OpenStack Services on OpenShift (RHOSO) コンピュートノードは、以下のフェーズで更新できます。

Jira:RHOSSTRAT-89

RHOSO 環境向けのカーネルライブパッチ適用 (kpatch) が一般提供開始となりました。以前は、kpatch の手順はテクノロジープレビューとして提供されていました。

この機能を使用すると、システムを再起動せずに、重要なセキュリティー更新とバグ修正をカーネルに適用できます。この機能を使用して、カスタムライブパッチまたはサードパーティーのライブパッチソリューションを適用することはできません。

kpatch を有効にする方法の詳細は、最新メンテナンスリリースへの環境の更新 の コンピュートノードでのカーネルライブパッチの有効化 を参照してください。

Jira:RHOSSTRAT-89

今回のアップデートにより、OVN を使用しないネットワークコントローラーとの統合に対応できるようになりました。OVN が無効な場合、OVN がデータプレーンにデプロイされるのを待たずに、マイナーアップデートプロセスが続行されます。

Jira:OSPRH-17569

OpenStackControlPlane カスタムリソース (CR) の nova セクションで notificationsBusInstance が RabbitMqCluster CR を指すように設定されている場合、そのクラスター内の Pod が再起動されると、nova-operator のバグにより、nova-operator はすべての Compute サービスを 2 回再設定します。これにより、不必要なサービス停止時間が発生します。

一時的な回避策: 1. OpenStackControlPlane CR から notificationsBusInstance の設定を削除します。OpenStackControlPlane CR から通知用の RabbitMqCluster の定義を削除しないでください。2. RabbitMqCluster から transport_url を取得します。

+

$ oc get secret <name-rabbitmq-notifications>-default-user -o json | jq '.data | map_values(@base64d) | "rabbit://\(.username):\(.password)@\(.host):\(.port)/?ssl=1"'

+

Jira:OSPRH-17569

os_version プロパティーまたは os_admin_user プロパティーが設定に含まれていても、イメージプロパティーの重み付け関数は生の重みの計算時にそれらのプロパティーを考慮しません。

Jira:OSPRH-17569

Compute サービス (nova) の電源管理機能は、デフォルトでは無効になっています。次の nova-compute 設定でこれを有効にできます。

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

デフォルトの cpu_power_management_strategy cpu_state は現在サポートされていません。nova-compute を再起動すると、そのホスト上のすべての専用 PCPU (インスタンスが使用しているものも含む) の電源がオフになります。cpu_state ストラテジーを使用すると、それらのインスタンスの CPU は固定が解除されます。

Jira:OSPRH-10772

Red Hat OpenStack Services on Openshift (RHOSO) は、プロビジョニングされていないデータプレーンノードのプロビジョニングに metal3 を使用します。bootMacAddress を更新できないノードを置き換える必要がある場合、エラー状態が発生します。その結果、ノードは、デプロイメントから完全に削除され、新しいノードと同じようにプロビジョニングされなければならない状態に陥ります。automatedCleaningMode 属性が automatedCleaningMode: disabled に設定されている場合、このエラー状態は発生しません。

回避策: プロビジョニングされていないデータプレーンノードをプロビジョニングする場合は、必ず automatedCleaningMode 属性を automatedCleaningMode:disabled に設定します。

Jira:OSPRH-17569

マイナー更新中、RHOSO コントロールプレーンは一時的に利用できなくなります。API リクエストは、エラー 500 などの HTTP エラーコードで失敗する可能性があります。または、API リクエストは成功しても、基礎となるライフサイクル操作が失敗する可能性があります。たとえば、マイナー更新中に openstack server create コマンドで作成された仮想マシンインスタンスは、ACTIVE 状態に到達しません。コントロールプレーンの停止は一時的なものであり、マイナー更新が完了すると自動的に回復します。コントロールプレーンの停止は、すでに実行中のワークロードには影響しません。

回避策: この中断を防ぐには、Red Hat ナレッジベースの記事 How to enable mirrored queues in Red Hat Openstack Services on OpenShift を参照してください。

Jira:OSPRH-10790

設定されたイメージサイズの制限 (image_size_total) より大きいイメージを Image サービス (glance) にアップロードすると、Image サービスはアップロード前にイメージサイズを検証しないため、アップロードは成功します。イメージがアップロードされ保存されると、Image サービスはイメージサイズを把握しますが、場合によってはクォータを超過しています。クォータを超過していれば、Image サービスは後続のアップロードを拒否します。

Jira:OSPRH-17569

RHOSO 18 では、watcher_applier.rollback_when_actionplan_failed 設定オプションを有効にして、Action Plan が失敗した際に (失敗したアクションを) 自動的に元に戻すよう設定した場合でも、Optimize サービス (watcher) の Engine は、失敗したアクションを自動的に元に戻しません。

回避策: Action Plan で失敗した各アクションを手動で元に戻します。ロールバックを回避するには、失敗の根本原因を診断して修正し、監査を再度実行して新しい解決策を提案します。

Jira:OSPRH-19735

OpenStack Optimize サービスは、マルチ RHEL (Red Hat Enterprise Linux) モードではサポートされていません。Optimize サービスをマルチ RHEL モードで実行すると、特に RHEL 9.2 および RHEL 9.4 で稼働しているコンピュートノードでサービス障害が発生します。

Jira:OSPRH-17569

RHOSO 管理者は、Telemetry Operator で Rating サービス (cloudkitty) を有効にすることで、RHOSO クラウドのチャージバックおよび料金計算機能を評価できます。

Rating サービスは、RHOSO Telemetry サービスからデータを収集し、料金計算レポートを通じてクラウドのリソース使用状況を生成します。このレポートは、外部の財務業務システムや請求システムで利用できます。Rating サービスは請求用のインターフェイスは備えていません。

Jira:RHOSSTRAT-89

この問題は、スクレイピングの設定で、クラスター全体ではなく、単一の RabbitMQ ノードが明示的に選択されているために発生します。このため、複数のノードを持つクラスターの場合、RabbitMQ クラスターの表示が不完全になり、ユーザーへの情報提供が制限されます。回避策はありません。

Jira:OSPRH-17569

同じルートプロバイダー配下に類似した子プロバイダーが多数定義されている場合、Placement のデフォルト設定では、Placement サービスの割り当て候補生成アルゴリズムのスケーラビリティーが低下します。

たとえば、コンピュートノードに 8 個以上の子リソースプロバイダーがあり、それぞれが 1 つのリソースを提供している場合に、インスタンスが独立したリクエストグループで 8 個以上のリソースを要求すると、さらなる最適化が有効になっていない場合、GET allocation_candidates クエリーの計算に時間がかかりすぎて、インスタンスのスケジューリングが失敗します。

このような状況では、OpenStackControlPlane CR で以下の設定変更を行ってください。

spec:
placement:
    template:
      customServiceConfig: |
         [workarounds]
         optimize_for_wide_provider_trees = True
         [placement]
         max_allocation_candidates = 1000
         allocation_candidates_generation_strategy = breadth-first

Jira:OSPRH-17569

Compute サービス (nova) の電源管理機能は、デフォルトでは無効になっています。次の nova-compute 設定でこれを有効にできます。

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

デフォルトの cpu_power_management_strategy cpu_state は現在サポートされていません。nova-compute を再起動すると、そのホスト上のすべての専用 PCPU (インスタンスが使用しているものも含む) の電源がオフになります。cpu_state ストラテジーを使用すると、それらのインスタンスの CPU は固定が解除されます。

Jira:OSPRH-10772

os_version プロパティーまたは os_admin_user プロパティーが設定に含まれていても、イメージプロパティーの重み付け関数は生の重みの計算時にそれらのプロパティーを考慮しません。

Jira:OSPRH-17569

データプレーンノードが再起動されたとき、edpm_bootstrap サービスが The conditional check 'not boot_file_entry_present' failed. というエラーで失敗しなくなりました。

Jira:OSPRH-17569

Red Hat OpenStack Services on Openshift (RHOSO) は、プロビジョニングされていないデータプレーンノードのプロビジョニングに metal3 を使用します。bootMacAddress を更新できないノードを置き換える必要がある場合、エラー状態が発生します。その結果、ノードは、デプロイメントから完全に削除され、新しいノードと同じようにプロビジョニングされなければならない状態に陥ります。automatedCleaningMode 属性が automatedCleaningMode: disabled に設定されている場合、このエラー状態は発生しません。

回避策: プロビジョニングされていないデータプレーンノードをプロビジョニングする場合は、必ず automatedCleaningMode 属性を automatedCleaningMode:disabled に設定します。

Jira:OSPRH-17569

今回のアップデート以前は、OVN ゲートウェイ用の OpenStackControlPlane カスタムリソース (CR) で設定されたボンディングインターフェイスが機能していませんでした。ovn-operator が以下のようなエラーを出力していました。

…
Path:"" ERRORED: error configuring pod [openstack/ovn-controller-ovs-5rjnm] networking: [openstack/ovn-controller-ovs-5rjnm/68204fb3-394d-4990-80d3-fc2e388c2ee3:datacentre]: error adding container to network "datacentre": failed to move link invalid argument
': StdinData:
…

今回のアップデートにより、この問題は解決され、ovn-operator は ovn-controller および ovn-controller-ovs Pod 上に正しくボンディングインターフェイスを作成するようになりました。

Jira:OSPRH-17569

RHOSO を neutron-fwaas ドライバーとログ API プラグインとともにデプロイする場合、エンドユーザーにログ作成失敗の問題が発生する可能性があります。この問題を回避するには、同じ neutron デプロイメント内で neutron-fwaas ドライバーとログ API プラグインの両方を使用しないでください。

Jira:OSPRH-17569

マイナー更新中、RHOSO コントロールプレーンは一時的に利用できなくなります。API リクエストは、エラー 500 などの HTTP エラーコードで失敗する可能性があります。または、API リクエストは成功しても、基礎となるライフサイクル操作が失敗する可能性があります。たとえば、マイナー更新中に openstack server create コマンドで作成された仮想マシンインスタンスは、ACTIVE 状態に到達しません。コントロールプレーンの停止は一時的なものであり、マイナー更新が完了すると自動的に回復します。コントロールプレーンの停止は、すでに実行中のワークロードには影響しません。

回避策: この中断を防ぐには、Red Hat ナレッジベースの記事 How to enable mirrored queues in Red Hat Openstack Services on OpenShift を参照してください。

Jira:OSPRH-10790

設定されたイメージサイズの制限 (image_size_total) より大きいイメージを Image サービス (glance) にアップロードすると、Image サービスはアップロード前にイメージサイズを検証しないため、アップロードは成功します。イメージがアップロードされ保存されると、Image サービスはイメージサイズを把握しますが、場合によってはクォータを超過しています。クォータを超過していれば、Image サービスは後続のアップロードを拒否します。

Jira:OSPRH-17569

RHOSO 18 では、project-id 引数が指定されていない場合、cinder-manage quota check および cinder-manage quota sync コマンドが失敗し、Block Storage サービス (cinder) でのクォータ使用量を正確に管理できません。

回避策: 現在、この問題に対する回避策はありません。

Jira:OSPRH-17569

現在、ボリュームタイプの volume_backend_name パラメーター値が宛先プールの volume_backend_name パラメーター値と一致しない場合、ボリュームを移行しようとするとエラーが発生します。

回避策: ボリューム移行に参加するすべてのボリュームタイプと cinder プールの volume_backend_name を共通する値に設定します。

Jira:OSPRH-17569

RHOSO 18 では、watcher_applier.rollback_when_actionplan_failed 設定オプションを有効にして、Action Plan が失敗した際に (失敗したアクションを) 自動的に元に戻すよう設定した場合でも、Optimize サービス (watcher) の Engine は、失敗したアクションを自動的に元に戻しません。

回避策: Action Plan で失敗した各アクションを手動で元に戻します。ロールバックを回避するには、失敗の根本原因を診断して修正し、監査を再度実行して新しい解決策を提案します。

Jira:OSPRH-19735

以前は、この機能はテクノロジープレビューとして利用可能でした。このリリースでは、RHOSP 17.1 デプロイメントの導入の一環として、NFS 上の /var/lib/nova/instances を持つコンピュートホストを移行できます。 

Jira:OSPRH-17569

以前は、OVS に行われたバグ修正により、OVS ポートへのカーネルのデフォルト QOS ポリシーの適用が変更されました。この修正は 17.1 には適用されましたが、18.0 には適用されませんでした。 その結果、OVS インターフェイスのネットワーク設定のリグレッションにより、カーネル OVS を使用する際の Openstack インスタンスのネットワークパフォーマンスに悪影響が生じました。この更新では、os-vif OVS プラグインが強化され、デフォルトで linux-noop QOS ポリシーを使用することで、OVS インターフェイス上のネットワークパフォーマンスが向上しました。これは、引き続き neutron QOS ポリシーによってオーバーライドされる可能性があります。更新を適用するには、インスタンスを再起動または移動してハードリブートでポートを再作成するか、デタッチ操作に続いてアタッチ操作を実行するか、ライブマイグレーション操作を実行します。

Jira:OSPRH-18532

Compute サービス (nova) の電源管理機能は、デフォルトでは無効になっています。次の nova-compute 設定でこれを有効にできます。

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

デフォルトの cpu_power_management_strategy cpu_state は現在サポートされていません。nova-compute を再起動すると、そのホスト上のすべての専用 PCPU (インスタンスが使用しているものも含む) の電源がオフになります。cpu_state ストラテジーを使用すると、それらのインスタンスの CPU は固定が解除されます。

Jira:OSPRH-10772

同じルートプロバイダー配下に類似した子プロバイダーが多数定義されている場合、Placement のデフォルト設定では、Placement サービスの割り当て候補生成アルゴリズムのスケーラビリティーが低下します。

たとえば、コンピュートノードに 8 個以上の子リソースプロバイダーがあり、それぞれが 1 つのリソースを提供している場合に、インスタンスが独立したリクエストグループで 8 個以上のリソースを要求すると、さらなる最適化が有効になっていない場合、GET allocation_candidates クエリーの計算に時間がかかりすぎて、インスタンスのスケジューリングが失敗します。

このような状況では、OpenStackControlPlane CR で以下の設定変更を行ってください。

spec:
placement:
    template:
      customServiceConfig: |
        [workarounds]
        optimize_for_wide_provider_trees = True
        [placement]
       max_allocation_candidates = 1000
        allocation_candidates_generation_strategy = breadth-first

Jira:OSPRH-17569

os_version プロパティーまたは os_admin_user プロパティーが設定に含まれていても、イメージプロパティーの重み付け関数は生の重みの計算時にそれらのプロパティーを考慮しません。

Jira:OSPRH-17569

RHOSO 18.0.14 では、DNS サービス (designate) が完全にサポートされるようになりました。詳細は、サービスとしての DNS の設定 を参照してください。

Jira:RHOSSTRAT-89

RHOSO 18.0.14 では、Load-balancing サービス (octavia) のフロー再開により、元のコントローラーが予期せずシャットダウンした場合に、フローが代替コントローラーに自動的に再割り当てされます。詳細は、フロー再開を使用してタスクフローの中断を回避する を参照してください。

Jira:RHOSSTRAT-89

RHOSO 18.0.14 では、アベイラビリティーゾーン (AZ) でのロードバランサーの作成が完全にサポートされるようになりました。詳細は、エッジにおけるネットワークトラフィックの負荷分散のためのアベイラビリティーゾーンの作成 を参照してください。

Jira:RHOSSTRAT-89

RHOSO 18.0.14 では、Load-balancing サービスの OVN プロバイダードライバーがテクノロジープレビューではなくなり、完全にサポートされるようになりました。詳細は、Load-balancing サービスプロバイダードライバー を参照してください。

Jira:RHOSSTRAT-775

この更新により、Prometheus OVS/OVN エクスポーターは、OCP ゲートウェイ、ovn-controller、ovs-vswitchd に関連する追加のメトリクスを収集します。さらに、コントロールプレーン Pod で OVS/OVN メトリクス収集が利用できるようになりました。以前は、収集はデータプレーンノードでのみ使用できました。

詳細は、ネットワークオブザーバビリティー を参照してください。

Jira:RHOSSTRAT-89

この更新により、Prometheus OVS/OVN エクスポーターは northd および RAFT に関連する追加のメトリクスを収集します。さらに、コントロールプレーン Pod で OVS/OVN メトリクス収集が利用できるようになりました。以前は、収集はデータプレーンノードでのみ使用できました。詳細は、ネットワークオブザーバビリティー を参照してください。

Jira:RHOSSTRAT-89

RHOSO 機能リリース 4 では、IPv6 ネットワークを使用して動的ルーティング環境を設定できます。詳細は、RHOSO 上での BGP ネットワーク用 RHOCP の準備 を参照してください。

Jira:RHOSSTRAT-89

この更新前は、無効なロードバランサーメンバーを再度有効にしても ERROR 状態のままとなり、ロードバランサーのステータスレポートが正確ではなくなり、さらにトラフィック分散の問題が発生する可能性もありました。この問題は、ヘルスモニターが無効なメンバーのステータスを OFFLINE ではなく ERROR と誤って報告したことが原因でした。この誤ったステータスにより、無効なメンバーを再度有効にしても ONLINE に戻りませんでした。この更新により、ヘルスモニターは無効なメンバーのステータスを正しく OFFLINE に設定し、問題は解決されました。無効化したメンバーは正しく OFFLINE としてマークされ、再度有効にすると自動的に ONLINE に戻ります。

Jira:OSPRH-17569

このリリースでは、TAPaaS のテクノロジープレビューをテストできます。

TAPaaS は、Openstack デプロイメントにおけるテナント分離境界を維持しながら、マルチテナント共有環境でスケーラブルなポートミラーリングを実現する Openstack 統合フレームワークを提供します。TAPaaS は、テナントまたは管理者の目的に応じてオンデマンドのトラフィックミラーリングを可能にする Neutron 拡張機能です。これによりユーザーは、1 つ以上の Neutron ポートからのトラフィックをミラーリングし、それを TAP の宛先 (多くの場合は仮想ネットワークパケットブローカー (NPB)、侵入検知システム (IDS)、またはトラフィックアナライザーインスタンス) にリダイレクトする TAP サービスを作成できます。

Jira:RHOSSTRAT-39

RHOSO 18.0.14 (機能リリース 4) では、Firewall-as-a-Service (FWaaS) のテクノロジープレビューをテストできます。テクノロジープレビュー機能は実稼働環境で使用しないでください。

マルチテナントアプリケーションへの OpenStack ベースのクラウドの導入が増加していますが、引き続きセキュリティーは最優先事項です。特にパブリッククラウド環境やハイブリッドクラウド環境では、ネットワークレベルの分離とトラフィック制御が重要になります。

セキュリティーグループは、仮想マシンインスタンスレベルまたは仮想マシンポートレベルでセキュリティーポリシーを指定するための十分な機能を提供しますが、ネットワークまたはルーターポートレベルでポリシーを指定する機能はサポートされていません。

FWaaS プロジェクトは、このルーターポートレベルでセキュリティーポリシーを指定するための追加機能を提供します。これにより、同じポリシーグループ内で複数のポリシールールを指定できるようになり、ルーターポートレベルでの L3 または L2 ポリシーの適用もサポートされます。

FWaaS は、NGFW ベンダーソリューションとの統合のための NGFW サードパーティープラグインのサポートも提供します。これにより、ACL レベルを超えたファイアウォール機能が可能になります。DPI、マルウェア保護、IPS、IDP などの機能。

FWaaS サービスプラグインを有効にするには、次の例に示すように、コントロールプレーンのカスタムリソース (CR) ファイルの service_plugins に firewall_v2 を追加します。この例には、わかりやすいように他のサンプルサービスも含まれています。これらのサービスは、FWaaS を有効にするために必要なわけではありません。

FWaaS のテクノロジープレビューを設定するには、コントロールプレーン CR に次の設定を追加します。

customServiceConfig: |
  [DEFAULT]
  service_plugins = qos,ovn-router,trunk,segments,port_forwarding,log,firewall_v2

  [service_providers]
  service_provider = FIREWALL_V2:fwaas_db:neutron_fwaas.services.firewall.service_drivers.ovn.firewall_l3_driver.OVNFwaasDriver:default

FWaaS の使用例については、Firewall-as-a-Service (FWaaS) v3 シナリオ [1] の「Firewall-as-a-Service v2 の設定」を参照してください。

[1] https://docs.openstack.org/neutron/latest/admin/fwaas-v2-scenario.html

Jira:RHOSSTRAT-499

このテクノロジープレビューを使用すると、RHOSO 18 に基づき並列コントロールプレーンをデプロイし、コンピュートノードを新しいコントロールプレーンにポイントすることで、OpenStack デプロイメントを RHOSP 17.1 から RHOSO 18 にインプレースアップグレードできます。

Jira:RHOSSTRAT-89

データプレーンノード上の NIC は、ベアメタルプロビジョニングやその他の初期設定タスクに使用できます。その後、os-net-config を使用して、デプロイメントで運用するために NIC を再設定できます。その場合、古い初期設定が残ることで IP アドレスの競合が発生する可能性があります。このような競合を回避するには、remove_config を使用して、初期設定から古い設定ファイルをクリーンアップできます。詳細は、古いホストネットワーク設定のクリーンアップ を参照してください。

Jira:RHOSSTRAT-89

以前の RHOSO リリースでは、Red Hat は NMstate を os-net-config provider としてサポートしていませんでした。現在はこれがサポートされ、デフォルト設定では os-net-config プロバイダーが nmstate に設定されます。

パラメーターは edpm_network_config_nmstate です。デフォルト値は true です。nmstate プロバイダーの特定の制限により ifcfg プロバイダーを使用する必要がある場合は、edpm_network_config_nmstate を false に変更します。

詳細は、デプロイメントのプランニング ガイドの「os-net-config の nmstate プロバイダー」を参照してください。

Jira:OSPRH-11309

この機能強化により、ターゲットバージョンの更新時にカスタムコンテナーイメージが更新されないことで生じる影響や不整合を防ぐことができ、マイナー更新時のバージョン追跡と検証が正しく確実に行われます。

この更新により、targetVersion を設定してマイナー更新を開始したときに、関連付けられているカスタムコンテナーイメージの customImages バージョンも更新されていない場合は、マイナー更新の実行が停止するようになりました。必要に応じて、ユーザーには強制的に更新を実行するオプションがあります。

Jira:OSPRH-17569

この機能強化により、RabbitMQ サービス Operator である rabbitmq-cluster-operator がバージョン 2.16.0 に更新されました。この更新により、RabbitMQ クラスターが再起動されます。RabbitMQ クラスターの更新タイミングを制御する必要がある場合は、更新を実行する前にリコンシリエーションを一時停止し、RabbitMQ クラスターを安全に更新できるタイミングでリコンシリエーションを再開できます。

Jira:RHOSSTRAT-89

OpenStack Operator 初期化リソースは、デフォルトの CPU およびメモリーリソース制限と、デフォルトの toleration を持つ各 {rhocp_long} サービス Operator を作成します。この機能強化により、各 {rhocp_long} サービス Operator のリソース制限と toleration の設定をカスタマイズできるようになりました。

Jira:RHOSSTRAT-89

マイナー更新中、RHOSO コントロールプレーンは一時的に利用できなくなります。API リクエストは、エラー 500 などの HTTP エラーコードで失敗する可能性があります。または、API リクエストは成功しても、基礎となるライフサイクル操作が失敗する可能性があります。たとえば、マイナー更新中に openstack server create コマンドで作成された仮想マシンインスタンスは、ACTIVE 状態に到達しません。コントロールプレーンの停止は一時的なものであり、マイナー更新が完了すると自動的に回復します。コントロールプレーンの停止は、すでに実行中のワークロードには影響しません。

回避策: この中断を防ぐには、Red Hat ナレッジベースの記事 How to enable mirrored queues in Red Hat Openstack Services on OpenShift を参照してください。

Jira:OSPRH-10790

RHOSO 18.0.14 (機能リリース 4) 以降では、クラウドのキャッシュされたデータへのアクセスを制限してクラウドのセキュリティーを強化するために、memcached サービスによって維持されるキャッシュを認証を要求するように設定できます。詳細は、「Red Hat OpenStack Services on OpenShift デプロイメントのカスタマイズ」の memcached サービスの認証の設定 を参照してください。

Jira:RHOSSTRAT-89

RHOSO 18.0.14 (機能リリース 4) 以降では、インスタンス HA が有効になっている Red Hat OpenStack Platform (RHOSP) 17.1 環境を RHOSO 18.0 に導入できます。インスタンス HA 環境の導入に関する詳細は、Red Hat OpenStack Platform 17.1 デプロイメントの導入 の インスタンス HA デプロイメントの導入準備 および ink:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/adopting_a_red_hat_openstack_platform_17.1_deployment/adopting-data-plane_adopt-control-plane#enabling-high-availability-for-instances_data-plane [コンピュートインスタンスサービスの高可用性を有効にする] を参照してください。

Jira:RHOSSTRAT-89

RHOSO 18.0.14 (機能リリース 4) 以降、RabbitMQ は新しい RHOSO デプロイメントでの Quorum キューの使用をサポートします。Quorum キューは、Raft コンセンサスアルゴリズムに基づく耐久性のある複製キューで、これによりデータの安全性と高可用性が向上します。詳細は、「Red Hat OpenStack Services on OpenShift のデプロイ」ガイドの コントロールプレーンの作成 でステップ 5 を参照してください。

Jira:RHOSSTRAT-89

RHOSO 18.0.14 (機能リリース 4) 以降では、ユーザーがシングルサインオン (SSO) を使用して OpenStack ダッシュボードにログインし、複数の外部アイデンティティープロバイダー (IdP) のいずれかを選択できるように RHOSO を設定できます。詳細は、「セキュリティーサービスの設定」の RHOSO でのマルチレルムフェデレーション認証の設定 を参照してください。

Jira:RHOSSTRAT-89

この更新により、Image サービス (glance) は HTTPd 設定ファイルのカスタマイズをサポートするようになりました。extraMounts パラメーターを使用して、カスタム httpd.conf ファイルの組み込みと読み込みを行えます。

Jira:OSPRH-17569

この更新により、Shared File Systems サービス (manila) は HTTPd 設定ファイルのカスタマイズをサポートするようになりました。extraMounts パラメーターを使用して、カスタム httpd.conf ファイルの組み込みと読み込みを行えます。

Jira:OSPRH-17569

この更新により、Image サービス (glance) はテナントごとのクォータをサポートし、プライベートクラウドでのリソース管理が改善されました。

Jira:RHOSSTRAT-89

NFS 経由で CephFS を使用する Shared File Systems サービス (manila) の導入が一般提供されました。以前は、この導入手順はテクノロジープレビューとして提供されていました。

この機能強化により、Shared File Systems Service のバックエンドとして NFS 経由で CephFS を使用する既存の Red Hat OpenStack Platform 17.1 デプロイメントを、フルサポート付きで RHOSO 18.0 に移行できるようになります。

導入プロセスには以下が含まれます。

RHOSO 18.0.14 (機能リリース 4) 以降で、Block Storage サービス (cinder) のバックエンドとして iSCSI を使用する Red Hat OpenStack Platform 17.1 環境では、RHOSO 18.0 を導入する手順が完全にサポートされます。詳細は、Red Hat OpenStack Platform 17.1 デプロイメントの導入 の Block Storage サービスの導入 を参照してください。

Jira:RHOSSTRAT-89

この更新では、Image サービス (glance) に Cache API のサポートが追加されました。Image サービスの Cache API を使用すると、キャッシュノードの集中管理が可能になり、個別の SSH 接続が不要になります。主な機能には、特定ノードのキャッシュされたイメージのリスト表示、キャッシュ待ちイメージのキューへの追加、キャッシュされたイメージまたはキャッシュ待ちキューのイメージの削除などがあります。この更新により、管理者は API を呼び出して、API 呼び出しをワークフローや自動タスクに統合できます。

Jira:RHOSSTRAT-89

RHOSO 18.0.14 (機能リリース 4) 以降で、Image サービス (glance) のバックエンドとして Block Storage サービス (cinder) を使用する Red Hat OpenStack Platform 17.1 環境で、RHOSO 18.0 の導入が完全にサポートされます。詳細は、Red Hat OpenStack Platform 17.1 デプロイメントの導入 の Block Storage サービスバックエンドを使用してデプロイされる Image サービスの導入 を参照してください。

Jira:RHOSSTRAT-89

この更新により、外部データプレーンノードに Object Storage サービス (swift) をデプロイできます。これにより、大規模ストレージクラスターのスケーラビリティーとパフォーマンスが向上します。DNS 転送を有効にし、ストレージ用ディスクなどの指定されたプロパティーを持つ OpenStackDataPlaneNodeSet CR を作成することで、OpenStackDataPlaneService CR 内の追加の ConfigMap または Secret CR を通じてサービス設定をカスタマイズできます。

Jira:RHOSSTRAT-89

Shared File Systems サービス (manila) は、プロジェクト間での共有の転送をサポートするようになりました。セキュリティーと否認防止を確保するために、転送を開始すると、1 回限りの転送シークレットキーが生成されます。受信側プロジェクトのユーザーが転送を完了できるように、キーは帯域外で伝達される必要があります。

Jira:RHOSSTRAT-89

Shared File Systems サービス (manila) に、Dell PowerScale ストレージシステム (旧 Dell Isilon) との統合が含まれるようになりました。このドライバーは、NFS および CIFS 共有ファイルシステムのライフサイクルのプロビジョニングと管理、それらへのクライアントアクセスの制御、それらのサイズ変更、スナップショットの作成、およびこれらのスナップショットの新しい共有ファイルシステムへの複製をサポートします。

Jira:RHOSSTRAT-89

この更新により、notificationsBusInstance パラメーターを使用して Block Storage サービス (cinder) および Shared File System サービス (manila) で通知を有効にできるようになりました。これにより、既存の RabbitMQ インスタンスまたは専用の RabbitMQ インスタンスとの統合が可能になります。

Jira:RHOSSTRAT-876

この更新前は、ONTAP FlexGroup プールで Block Storage サービス (cinder) ボリュームのスナップショットを作成しても成功しませんでした。この更新により、ボリュームスナップショットの作成が成功し、エンドユーザーのデータが確実にバックアップされます。

Jira:OSPRH-17569

この更新前は、イメージボリュームキャッシュ内の PowerFlex ボリュームがスナップショット制限に達すると、Block Storage サービス (cinder) がキャッシュエントリーを置き換えていました。ただし、ボリューム自体は削除されなかったため、クォータを消費する使用できないボリュームが生じていました。現在は、イメージボリュームキャッシュ内の PowerFlex ボリュームがスナップショット制限に達すると、Block Storage サービスはキャッシュエントリーを置き換え、元のキャッシュエントリーの PowerFlex ボリュームを削除します。

Jira:OSPRH-17569

この更新前は、バージョン 9.13.1 以降の NetApp ONTAP ストレージシステムでは、処理中の場合に FlexVol スナップショットおよび FlexClone のクローン削除要求を拒否していました。この更新により、Shared File Systems サービス (manila) の NetApp ONTAP ドライバーは、共有またはスナップショットの削除前にクローン分割操作を管理し、削除の失敗を防止します。ユーザーは、クローンの削除に失敗することなく、作成後いつでも Shared File Systems サービスのスナップショットとスナップショットから作成された共有を削除できるようになりました。

Jira:OSPRH-17569

RHOSO 18 では、project-id 引数が指定されていない場合、cinder-manage quota check および cinder-manage quota sync コマンドが失敗し、Block Storage サービス (cinder) でのクォータ使用量を正確に管理できません。

回避策: 現在、この問題に対する回避策はありません。

Jira:OSPRH-17569

設定されたイメージサイズの制限 (image_size_total) より大きいイメージを Image サービス (glance) にアップロードすると、Image サービスはアップロード前にイメージサイズを検証しないため、アップロードは成功します。イメージがアップロードされ保存されると、Image サービスはイメージサイズを把握しますが、場合によってはクォータを超過しています。クォータを超過していれば、Image サービスは後続のアップロードを拒否します。

Jira:OSPRH-17569

この更新により、extraMounts を使用して httpd.conf ファイルをロードすることで、Dashboard である horizon-operator の httpd タイムアウト値をカスタマイズできるようになりました。詳細は、https://github.com/openstack-k8s-operators/horizon-operator/blob/main/config/samples/httpd-overrides/README.md を参照してください。

Jira:OSPRH-17569

この更新により、Dashboard サービス (horizon) では direct アップロード方式がデフォルトのアップロード方式になります。direct アップロード方式では、Image サービス (glance) で Cross-Origin Resource Sharing (CORS) を有効にする必要がありますが、現在は glance-operator で CORS がデフォルトで有効になっています。

そのため、Dashboard サービスの Web UI を使用して、サイズが 1 GiB を超えるイメージをアップロードできるようになりました。direct アップロード方式では、まず Dashboard サービスにイメージを保存してから Image サービスに送信するのではなく、Web ブラウザーから Image サービスに直接イメージを送信します。

Jira:RHOSSTRAT-89

この更新前は、Optimize サービス (watcher) は、独自の Operator を使用してインストールされるテクニカルプレビュー機能として提供されていました。この更新により、Optimize サービスが OpenStack Operator に統合され、完全にサポートされるようになりました。

If you have installed the Optimize service as a technical preview, you must remove the Optimize service Operator and any custom resource of kind `Watcher` before updating your RHOSO deployment to 18.0.14 or later.

Jira:OSPRH-17569

この更新により、Optimize サービス (watcher) が他の OpenStack サービスから通知の更新を受信できるようになり、Optimize サービスの精度が向上しました。

Jira:OSPRH-17569

この更新により、OpenStack Dashboard (horizon) で CONTINUOUS 監査を作成するときに、開始時刻と終了時刻を設定できるようになりました。

Jira:OSPRH-17569

この更新により、Openstack Dashboard で Audit を作成するときに、パラメーターを JSON 値として追加できるようになりました。

Jira:OSPRH-17569

この更新により、Openstack Dashboard では、表示されるストラテジーが、選択した goal に適用可能なストラテジーのみ表示されるようになりました。

Jira:OSPRH-17569

この更新前は、ボリューム移動操作に関連する Optimize サービス (watcher) のレガシーコードにより、2 つのインスタンスが同じホストブロックデバイスにアクセスする可能性がありました。これにより、ボリュームの移行後にテナント間で破損や不正なデータアクセスが発生する可能性がありました。

この更新では、レガシーコードが削除され、ボリュームの移行が Block Storage サービス (cinder) に委任されました。これにより、データ破損とデータアクセスの問題が解決されました。

Jira:OSPRH-17569

RHOSO 18 では、watcher_applier.rollback_when_actionplan_failed 設定オプションを有効にして、Action Plan が失敗した際に (失敗したアクションを) 自動的に元に戻すよう設定した場合でも、Optimize サービス (watcher) の Engine は、失敗したアクションを自動的に元に戻しません。

回避策: Action Plan で失敗した各アクションを手動で元に戻します。ロールバックを回避するには、失敗の根本原因を診断して修正し、監査を再度実行して新しい解決策を提案します。

Jira:OSPRH-19735

現在、ボリュームタイプの volume_backend_name パラメーター値が宛先プールの volume_backend_name パラメーター値と一致しない場合、ボリュームを移行しようとするとエラーが発生します。

回避策: ボリューム移行に参加するすべてのボリュームタイプと cinder プールの volume_backend_name を共通する値に設定します。

Jira:OSPRH-17569

RHOSO 18.0.14 (機能リリース 4) および RHOSP 17.1 では、VMware Migration Toolkit を使用して、ワークロードを VMware から OpenStack に移行できるようになりました。

Jira:RHOSSTRAT-89

Red Hat OpenStack Services on Openshift (RHOSO) は、プロビジョニングされていないデータプレーンノードのプロビジョニングに metal3 を使用します。bootMacAddress を更新できないノードを置き換える必要がある場合、エラー状態が発生します。その結果、ノードは、デプロイメントから完全に削除され、新しいノードと同じようにプロビジョニングされなければならない状態に陥ります。automatedCleaningMode 属性が automatedCleaningMode: disabled に設定されている場合、このエラー状態は発生しません。

回避策: プロビジョニングされていないデータプレーンノードをプロビジョニングする場合は、必ず automatedCleaningMode 属性を automatedCleaningMode:disabled に設定します。

Jira:OSPRH-17569

Compute サービス (nova) の電源管理機能は、デフォルトでは無効になっています。次の nova-compute 設定でこれを有効にできます。

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

デフォルトの cpu_power_management_strategy cpu_state は現在サポートされていません。nova-compute を再起動すると、そのホスト上のすべての専用 PCPU (インスタンスが使用しているものも含む) の電源がオフになります。cpu_state ストラテジーを使用すると、それらのインスタンスの CPU は固定が解除されます。

Jira:OSPRH-10772

マイナー更新中、RHOSO コントロールプレーンは一時的に利用できなくなります。API リクエストは、エラー 500 などの HTTP エラーコードで失敗する可能性があります。または、API リクエストは成功しても、基礎となるライフサイクル操作が失敗する可能性があります。たとえば、マイナー更新中に openstack server create コマンドで作成された仮想マシンインスタンスは、ACTIVE 状態に到達しません。コントロールプレーンの停止は一時的なものであり、マイナー更新が完了すると自動的に回復します。コントロールプレーンの停止は、すでに実行中のワークロードには影響しません。

回避策: この中断を防ぐには、Red Hat ナレッジベースの記事 How to enable mirrored queues in Red Hat Openstack Services on OpenShift を参照してください。

Jira:OSPRH-10790

Red Hat Ceph Storage の問題により、CephFS-NFS バックエンドを持つ Shared File Systems サービス (manila) 共有で IPv6 エクスポート場所の使用が阻止されます。回避策: 現時点では回避策はありません。

Jira:OSPRH-19498

RHOSO 18.0.10 (機能リリース 3) では、OpenStack 関連のパッケージ更新とシステム関連のパッケージ更新を分割する新しい更新ワークフローが導入されました。この新しい機能により、データプレーン update サービスは非推奨となり、分割された update-services と update-system サービスが採用されるようになりました。update サービスは今後のリリースで削除される予定です。お客様は分割更新機能の使用に移行する必要があります。分割更新機能の詳細は、Red Hat ナレッジベースの記事 Performing a minor update of OpenStack service containers and RHEL RPMs separately を参照してください。

Jira:OSPRH-20354

現在、ボリュームタイプの volume_backend_name パラメーター値が宛先プールの volume_backend_name パラメーター値と一致しない場合、ボリュームを移行しようとするとエラーが発生します。

回避策: ボリューム移行に参加するすべてのボリュームタイプと cinder プールの volume_backend_name を共通する値に設定します。

Jira:OSPRH-17569

RHOSO 18 では、watcher_applier.rollback_when_actionplan_failed 設定オプションを有効にして、Action Plan が失敗した際に (失敗したアクションを) 自動的に元に戻すよう設定した場合でも、Optimize サービス (watcher) の Engine は、失敗したアクションを自動的に元に戻しません。

回避策: Action Plan で失敗した各アクションを手動で元に戻します。ロールバックを回避するには、失敗の根本原因を診断して修正し、監査を再度実行して新しい解決策を提案します。

Jira:OSPRH-19735

マイナー更新中、RHOSO コントロールプレーンは一時的に利用できなくなります。API リクエストは、エラー 500 などの HTTP エラーコードで失敗する可能性があります。または、API リクエストは成功しても、基礎となるライフサイクル操作が失敗する可能性があります。たとえば、マイナー更新中に openstack server create コマンドで作成された仮想マシンインスタンスは、ACTIVE 状態に到達しません。コントロールプレーンの停止は一時的なものであり、マイナー更新が完了すると自動的に回復します。コントロールプレーンの停止は、すでに実行中のワークロードには影響しません。

回避策: この中断を防ぐには、Red Hat ナレッジベースの記事 How to enable mirrored queues in Red Hat Openstack Services on OpenShift を参照してください。

Jira:OSPRH-10790

Red Hat Ceph Storage の問題により、CephFS-NFS バックエンドを持つ Shared File Systems サービス (manila) 共有で IPv6 エクスポート場所の使用が阻止されます。回避策: 現時点では回避策はありません。

Jira:OSPRH-19498

以前は、OVS に行われたバグ修正により、OVS ポートへのカーネルのデフォルト QOS ポリシーの適用が変更されました。この修正は 17.1 には適用されましたが、18.0 には適用されませんでした。 その結果、OVS インターフェイスのネットワーク設定のリグレッションにより、カーネル OVS を使用する際の Openstack インスタンスのネットワークパフォーマンスに悪影響が生じました。この更新では、os-vif OVS プラグインが強化され、デフォルトで linux-noop QOS ポリシーを使用することで、OVS インターフェイス上のネットワークパフォーマンスが向上しました。これは、引き続き neutron QOS ポリシーによってオーバーライドされる可能性があります。更新を適用するには、インスタンスを再起動または移動してハードリブートでポートを再作成するか、デタッチ操作に続いてアタッチ操作を実行するか、ライブマイグレーション操作を実行します。

Jira:OSPRH-18532

以前は、ISO イメージを備えたコンピュートインスタンスは、CD-ROM ではなくブロックデバイス経由で起動されていました。これにより、CD-ROM からの RHEL キックスタートインストールが開始されませんでした。このバグ修正により、コンピュートはインスタンスを ISO イメージから CD-ROM 経由で正しく起動するようになりました。

Jira:OSPRH-17569

Compute サービス (nova) の電源管理機能は、デフォルトでは無効になっています。次の nova-compute 設定でこれを有効にできます。

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

デフォルトの cpu_power_management_strategy cpu_state は現在サポートされていません。nova-compute を再起動すると、そのホスト上のすべての専用 PCPU (インスタンスが使用しているものも含む) の電源がオフになります。cpu_state ストラテジーを使用すると、それらのインスタンスの CPU は固定が解除されます。

Jira:OSPRH-10772

この更新では、OpenShift Lifecycle Manager (OLM) Operator リソースに namespace フィールドが定義されていないデータが含まれていた場合に、OpenStack Operator バージョン 1.0.6 以前からのアップグレードが失敗する場合があるという問題が修正されました。

この更新により、OpenStack Operator は、OpenStack コントローラー内の Operator 参照用に namespace フィールドが実装されているか確認するようになりました。OpenStack Service Operator のアップグレードに影響はありません。

Jira:OSPRH-17456

マイナー更新中、RHOSO コントロールプレーンは一時的に利用できなくなります。API リクエストは、エラー 500 などの HTTP エラーコードで失敗する可能性があります。または、API リクエストは成功しても、基礎となるライフサイクル操作が失敗する可能性があります。たとえば、マイナー更新中に openstack server create コマンドで作成された仮想マシンインスタンスは、ACTIVE 状態に到達しません。コントロールプレーンの停止は一時的なものであり、マイナー更新が完了すると自動的に回復します。コントロールプレーンの停止は、すでに実行中のワークロードには影響しません。

回避策: この中断を防ぐには、Red Hat ナレッジベースの記事 How to enable mirrored queues in Red Hat Openstack Services on OpenShift を参照してください。

Jira:OSPRH-10790

この更新前は、Image サービス (glance) の S3 バックエンドがある場合、イメージインポートワークフローを使用してマルチパートイメージをアップロードする必要がありました。この更新により、Block Storage (cinder) ボリュームから S3 バックエンドにイメージを作成するときに、s3_store_large_object_size を 0 に設定して、マルチパートアップロードを強制できるようになりました。

Jira:OSPRH-11018

Red Hat Ceph Storage の問題により、CephFS-NFS バックエンドを持つ Shared File Systems サービス (manila) 共有で IPv6 エクスポート場所の使用が阻止されます。回避策: 現時点では回避策はありません。

Jira:OSPRH-19498

ゾーン移行ストラテジーの一部であるボリューム移行操作は、テクノロジープレビュー機能としてのみ提供されています。実稼働環境では使用しないでください。

Jira:OSPRH-17639

この機能拡張により、RHOSO 内で実行される MariaDB データベースのオブザーバビリティーを可能にする新しいエクスポーターが実装されます。

Jira:RHOSSTRAT-882

コンピュートノードのテレメトリーデータは、内部メッセージバスを経由せずに Prometheus から直接収集されるようになりました。これにより、テレメトリーストレージシステムにコンピュートノードテレメトリーを保存できるようになりました。

[注記] IPv6 環境では Prometheus からコンピュートノードメトリクスを収集できません。

Jira:RHOSSTRAT-905

この更新では、8 文字未満の DNS 検索ドメイン (dns_search_domains) がアルファベット順でコントロールプレーン DNS ドメインより前に表示され、テレメトリーデータの収集が中断される問題が修正されました。

Jira:OSPRH-16162

この更新では、nova-operator で専用の通知メッセージバスを設定するためのサポートが追加されました。Nova カスタムリソース (CR) で notificationsBusInstance を設定することで、バージョン付きおよびバージョンなしの通知を発行するための外部 RabbitMQ を指定できます。

[notification] および [oslo_messaging_notifications] セクションは、nova.conf でレンダリングされます。

novaEnabledNotification が設定されており、OpenShift シークレット経由で transport_url が提供される場合、nova-compute は外部システムに構造化された通知を送信します。これにより、RHOSO 環境での統合とオブザーバビリティーが向上します。

RHOSO で Nova 通知を有効にするには、OpenStackControlPlane CR を更新して新しい RabbitMQ インスタンスを追加し、notificationsBusInstance を使用して Nova CR でそれを参照します。nova-operator は、コントロールプレーンサービスを自動的に設定します。

データプレーンを更新するには、データプレーンノードを再デプロイします。

Jira:OSPRH-16489

クラウド運用者は、TripleO 管理から RHOSO の新しいインストーラーに、共通ネットワークを備えた既存の 17.1 マルチセル Nova デプロイメントを導入できるようになりました。

Jira:OSPRH-6548

Compute サービス (nova) の電源管理機能は、デフォルトでは無効になっています。次の nova-compute 設定でこれを有効にできます。

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

デフォルトの cpu_power_management_strategy cpu_state は現在サポートされていません。nova-compute を再起動すると、そのホスト上のすべての専用 PCPU (インスタンスが使用しているものも含む) の電源がオフになります。cpu_state ストラテジーを使用すると、それらのインスタンスの CPU は固定が解除されます。

Jira:OSPRH-10772

この更新前は、コントローラー間のパケットロスにより、python-networking-baremetal エージェントによるリクエスト処理が影響を受け、ベアメタルノードの Networking サービス (neutron) で物理ネットワークマッピングが更新されない可能性がありました。この更新では、ロギングとエラー処理が追加され、パケットロスが発生した場合に python-networking-baremetal 提供のサービスが終了し、コンテナーが自動的に再起動できるようになりました。コントローラーノードのネットワーク中断が発生しても、ベアメタルノードの物理ネットワークマッピングは引き続き更新されます。

Jira:OSPRH-10799

この更新により、デプロイメントエージェントの起動中に接続が中断されたためにデプロイメントプロセスがループし、タイムアウトする原因となっていた Bare Metal Provisioning サービス (ironic) の問題が解決されました。この問題は、RAM ドライブが最近起動されたかどうかを評価する試行が 1 回しか実行されないことが原因で発生していました。この問題が発生すると、ベアメタルノードはクリーンアップ、デプロイ、またはその他のワークフローアクションの実行に失敗します。

Jira:OSPRH-15883

コントローラー/ネットワークノードの組み合わせを使用する RHOSP 17.1 環境の導入は、Red Hat OpenStack Platform 17.1 デプロイメントの導入 に記載されているとおりに機能することが検証されています。

Jira:OSPRH-10714

この更新前は、外部最大転送単位 (MTU) が内部 MTU より小さい場合、OpenStack は期待どおりに north-south パケットを断片化せず、その結果、パケットが通知されることなくドロップされていました。この更新により、断片化が期待どおりに発生し、パケットが通知なくドロップされることがなくなります。

Jira:OSPRH-12695

この更新前は、RHEL 9.4 の Free Range Routing (FRR) で双方向フォワーディング検出 (BFD) を無効にすると、エラーの回復中にトラフィックが中断される可能性がありました。

このリリースでは、BGP ピアの BFD を無効にする必要がなくなりました。BGP ピアに対して BFD を運用することで、BGP の回復時間が向上し、トラフィックの中断が最小限に抑えられます。

Jira:OSPRH-15728

このテクノロジープレビューでは、DNS サービス (designate) を使用して DNS レコード、名前、ゾーンの管理をテストできます。詳細は、DNS をサービスとして設定 を参照してください。

Jira:RHOSSTRAT-441

このテクノロジープレビューを使用すると、アベイラビリティーゾーン (AZ) にロードバランサーを作成することで、トラフィックスループットの改善、レイテンシーの短縮、セキュリティーの強化をテストできます。詳細は、エッジにおけるネットワークトラフィックの負荷分散のためのアベイラビリティーゾーンの作成 を参照してください。

Jira:RHOSSTRAT-528

Load-balancing サービス (octavia) リソースは、デフォルトでプロジェクト (テナント) サービス内に作成されます。RHOSO 18.0.10 (機能リリース 3) では、リソースの使用を特定のプロジェクトに制限する、Octavia Operator の新しい TenantName パラメーターのテクノロジープレビューが導入されました。RHOSO 管理者はプロジェクトのドメインを変更することもできます。

Jira:RHOSSTRAT-614

RHOSO 18.0.10 (機能リリース 3) 以降で、OVN BGP エージェント (ovn-bgp-agent) が非推奨になりました。ovn-bgp-agent は、RHOSO の BGP 統合コンポーネントです。代替の BGP 統合メカニズムは、今後のリリースで予定されています。それまでは、Red Hat はこの機能に対するバグ修正とサポートのみを提供します。

Jira:OSPRH-17130

RHOSO 18.0.6 (機能リリース 2) では、OVS-DPDK を使用した RHOSO 環境向けの TCP セグメンテーションオフロード (TSO) のテクノロジープレビューが導入されました。

RHOSO 18.0.10 (機能リリース 3) 以降で、OVS-DPDK を使用した RHOSO 環境の TCP セグメンテーションオフロード (TSO) が一般提供機能になりました。

Jira:OSPRH-3885

以前は、Physical Function (PF) がインスタンスに割り当てられている場合、os-net-config を再実行すると、os-net-config はホスト内の SR-IOV PF を見つけることができず、導入に失敗していました。このリリースでは、導入は失敗しません。

Jira:OSPRH-12024

この更新前は、NetworkManager-dispatcher サービスは SELinux 権限拒否によってブロックされ、SELinux が強制されるとサービスが失敗していました。このリリースでは、NetworkManager が更新され、強制モードの SELinux で `NetworkManager-dispatcher` サービスを実行できるようになりました。その結果、NetworkManager-dispatcher サービスが強制モードの SELinux で実行できるようになり、障害は解消されました。

Jira:OSPRH-13544

この更新前は、VLAN 経由でコントロールプレーンと通信するためにコンピュートノードを事前プロビジョニングすると、NetworkManager CLI (nmcli) 接続が適切なインターフェイス名で作成されないことがありました。これによりデプロイメントが失敗しました。

このリリースでは、事前にプロビジョニングされたノードで nmstate プロバイダーが VLAN インターフェイスを処理する場合の問題が解決されました。その結果、nmstate プロバイダーを使用したデータプレーンのデプロイメントは成功するようになりました。

Jira:OSPRH-16526

edpm_network_config_nonconfigured_cleanup: true フラグは、機能リリース 2 でデフォルトとして導入され、一部の新しいデプロイメントが失敗する原因となりました。

この更新により、edpm_network_config_nonconfigured_cleanup: true フラグを適切に使用しても、デプロイメントが失敗しなくなりました。

以下を設定する際に、edpm_network_config_nonconfigured_cleanup: true を設定できるようになりました。

以前は、os-net-config nmstate プロバイダーを使用する環境では、br-ex ブリッジに割り当てられた物理 NIC に QoS 帯域幅制限ルールが適切に適用されませんでした。

この更新により、QoS 帯域幅制限ルールが適用されます。

Jira:OSPRH-17551

この更新により、nmstate プロバイダーを使用する環境で、br-ex にパッチポートが存在するアクティブインスタンスをホストするコンピュートノードでネットワーク更新が失敗する問題が修正されました。

Jira:OSPRH-17622

この機能により、開発、ステージング、テスト環境の namespace (プロジェクト) 分離を使用して、単一の RHOCP クラスターに複数の RHOSO 環境をデプロイできます。

詳細は、単一の RHOCP クラスターに複数の RHOSO 環境をデプロイする を参照してください。

Jira:RHOSSTRAT-612

マイナー更新中は、コントロールプレーンサービスが同時に更新されます。この機能拡張により、galera、rabbitmq、memcached、keystone の各サービスが分離され、マイナーコントロールプレーンサービスの更新フェーズ内で順番に連続して更新が実行されるようになります。

Jira:RHOSSTRAT-871

OpenStack Operator のインストール の手順が更新され、デフォルトの自動 Operator 更新承認が手動承認に変更されました。手動更新承認を使用すると、RHOSO 管理者は RHOSO Operator の更新をスケジュールできます。

Jira:RHOSSTRAT-890

マイナー更新中、RHOSO コントロールプレーンは一時的に利用できなくなります。API リクエストは、エラー 500 などの HTTP エラーコードで失敗する可能性があります。または、API リクエストは成功しても、基礎となるライフサイクル操作が失敗する可能性があります。たとえば、マイナー更新中に openstack server create コマンドで作成された仮想マシンインスタンスは、ACTIVE 状態に到達しません。コントロールプレーンの停止は一時的なものであり、マイナー更新が完了すると自動的に回復します。コントロールプレーンの停止は、すでに実行中のワークロードには影響しません。

回避策: この中断を防ぐには、Red Hat ナレッジベースの記事 How to enable mirrored queues in Red Hat Openstack Services on OpenShift を参照してください。

Jira:OSPRH-10790

この更新では、OpenShift Lifecycle Manager (OLM) Operator リソースに namespace フィールドが定義されていないデータが含まれている場合に、OpenStack Operator バージョン 1.0.6 以前からのアップグレードが失敗する場合があるという問題が修正されました。

この更新により、OpenStack Operator は、OpenStack コントローラー内の Operator 参照用に namespace フィールドが実装されているか確認するようになりました。OpenStack Service Operator のアップグレードに影響はありません。

Jira:OSPRH-17456

この更新前は、BGPConfiguration パラメーター (spec.frrNodeConfigurationSelector.nodename) の JSON タグに不整合がありました。正しいノード名は frrConfigurationNamespace ですが、NodeName 文字列は json:"frrConfigurationNamespace,omitempty となっており、正しくありませんでした。この更新により、JSON タグ内の NodeName 文字列が正しく json:"nodeName,omitempty" に設定されました。次の仕様を使用して、frrNodeConfigurationSelector を設定できるようになりました。

    frrNodeConfigurationSelector:
    - nodeName: nodeA
      nodeSelector:
        matchLabels:
          foo: bar

修正バージョンへの更新中に、以前に frrConfigurationNamespace JSON タグを使用して指定したノード名はすべて削除されるため、正しい nodeName JSON タグを使用してノード名を再設定する必要があります。

Jira:OSPRH-16550

この更新により、Image サービスの S3 ドライバーに新しい s3_store_cacert オプションが追加され、ユーザーは使用する認証局 (CA) バンドルへのパスを指定できるようになりました。

Jira:OSPRH-11189

この更新前は、Red Hat Ceph Storage 8 との統合時に NFS はサポートされていませんでした。この更新により、Red Hat Ceph Storage 8 との統合で NFS がサポートされるようになりました。

Jira:OSPRH-14788

この更新により、クラウド管理者は、VAST Data ストレージシステムの Shared File Systems サービスで認証を設定するときに、vast_mgmt_user と vast_mgmt_password、または vast_api_token を使用できるようになりました。クラウド管理者が VAST Data API ユーザーを指定する際にパスワードの代わりを必要とする場合、RHOSO デプロイメントでは API ベースの認証が役立ちます。

Jira:OSPRH-16085

この更新により、lsscsi コマンドを呼び出す必要がなくなったため、ボリュームをデタッチする際のファイバーチャネルのパフォーマンスが向上しました。

Jira:OSPRH-16924

RHOSO 18.0.10 (機能リリース 3) は、分散ゾーン環境におけるサードパーティー製ストレージアプライアンスの統合をサポートします。分散ゾーン環境の NFS およびファイバーチャネルプロトコルはテクノロジープレビューとして提供されており、実稼働環境での使用はまだ推奨されていません。

Jira:RHOSSTRAT-259

この更新により、notificationBusInstance パラメーターを使用して Image サービスで通知を有効にできるようになりました。これにより、既存の RabbitMQ インスタンスまたは専用のインスタンスとの統合が可能になります。

Jira:RHOSSTRAT-682

この更新により、次のコマンドの出力で共有の __mount_options メタデータを表示することで、ネイティブ CephFS 共有のマウント時に CephFS ファイル名を確認できるようになりました。

$ openstack share show <share_id>

Jira:RHOSSTRAT-685

この更新前は、デバイスの部分的なスキャンが原因で、NoFibreChannelVolumeDeviceFound エラーによりファイバーチャネルボリュームの割り当てが断続的に失敗していました。この更新により、スキャン範囲が拡大され、デバイスの検出が向上し、割り当て操作が成功するようになりました。

Jira:OSPRH-16737

この更新により、外部管理リングを使用して Object Storage サービスのデプロイメントをカスタマイズするための、2 つの新しいオプションをテストできるようになりました。このテクノロジープレビューにより、自動リング管理を無効にし、大規模なリングを複数の configmap に分散できるようになりました。

Jira:RHOSSTRAT-789

S3 バックエンドを使用してマルチパートイメージをアップロードする場合は、インポートワークフローを使用する必要があります。

Jira:OSPRH-11018

Red Hat Ceph Storage Object Gateway (RGW) は、現在、Red Hat Ceph Storage 8 との統合ではサポートされていません。

回避策: 現時点で回避策はありません。

Jira:OSPRH-14789

RHOSO 18.0.10 (機能リリース 3) では、RHOSO EDPM ノードの更新プロセスを、次の 2 つの異なるフェーズに分離する機能が導入されました。

この更新前は、ゾーン移行ストラテジーの実装は dst_node パラメーターの影響を受けていました。現在、実装は API スキーマに準拠し、dst_node パラメーターはオプションになりました。dst_node の値を指定しない場合は、Nova スケジューラーが適切なホストを自動的に選択します。

Jira:OSPRH-17179

この更新では、すべての Actions が終了した後に RHOSO Watcher が Action Plans の状態を正しく報告しない問題 (たとえば Actions が実際には FAILED 状態で終了した場合でも SUCCESS を報告するなど) が修正されます。

Jira:OSPRH-17257

RHOSO 18.0.10 (機能リリース 3) では、Optimize サービスでサポートされる新しい 3 つのストラテジー (ホストメンテナンス、インスタンスのゾーン移行、ワークロードバランス) のサポートが導入されました。リソース最適化の目標を達成するためにサポートされているストラテジーの詳細は、「インフラストラクチャーリソースの使用の最適化」の「Optimize サービスワークフローの例」を参照してください。

Jira:RHOSSTRAT-237

ゾーン移行ストラテジーの一部であるボリューム移行操作は、テクノロジープレビュー機能としてのみ提供されています。実稼働環境では使用しないでください。

Jira:OSPRH-17639

Compute サービス (nova) の電源管理機能は、デフォルトでは無効になっています。次の nova-compute 設定でこれを有効にできます。

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

デフォルトの cpu_power_management_strategy cpu_state は現在サポートされていません。nova-compute を再起動すると、そのホスト上のすべての専用 PCPU (インスタンスが使用しているものも含む) の電源がオフになります。cpu_state ストラテジーを使用すると、それらのインスタンスの CPU は固定が解除されます。

Jira:OSPRH-10772

この更新前は、redhat サービスはデータプレーンサービスのデフォルトリストから一時的に削除されていたため、ユーザーは OpenStackDataPlaneNodeSet CR 内のサービスリストに redhat サービスを手動で追加する必要がありました。この更新により、redhat サービスはデータプレーンサービスのデフォルトリストに復元されます。

Jira:OSPRH-15644

Egress QoS ポリシールール (最大帯域幅および/または最小帯域幅) を持つすべての VLAN またはフラットネットワークポートは、この情報を Logical_Switch_Port. options ディクショナリーに保存します。この更新前は、ポート名の変更やライブマイグレーションを含め、このポートに対する更新により QoS 情報が削除されていました。この更新により、QoS 情報はポートの更新を経ても維持されます。

Jira:OSPRH-15457

外部 MTU が内部 MTU より大きい場合、RHOSO は想定どおりに north-south パケットを断片化しません。代わりに、Ingress パケットは通知なしにドロップされます。

また、テナントネットワーク間の east/west トラフィックでも、断片化は機能しません。

これらの問題が解決されるまで、外部の MTU 設定が内部の MTU 設定以下であること、および east/west 経路上のすべての MTU 設定が等しいことを確認してください。

回避策:

これらの問題が解決されるまで、次の手順を実行して、外部の MTU 設定が内部の MTU 設定以下であること、および east/west 経路上のすべての MTU 設定が等しいことを確認してください。

たとえば、外部ネットワーク datacentre の MTU が 1500 であるとします。

この更新前は、VLAN 経由でコントロールプレーンと通信するためにコンピュートノードを事前プロビジョニングすると、NetworkManager CLI (nmcli) 接続が適切なインターフェイス名で作成されないことがありました。これによりデプロイメントが失敗しました。

このリリースでは、事前にプロビジョニングされたノードで nmstate プロバイダーが VLAN インターフェイスを処理する場合の問題が解決されました。その結果、nmstate プロバイダーを使用したデータプレーンのデプロイメントは成功するようになりました。

Jira:OSPRH-16526

マイナー更新中、RHOSO コントロールプレーンは一時的に利用できなくなります。API リクエストは、エラー 500 などの HTTP エラーコードで失敗する可能性があります。または、API リクエストは成功しても、基礎となるライフサイクル操作が失敗する可能性があります。たとえば、マイナー更新中に openstack server create コマンドで作成された仮想マシン (VM) は、ACTIVE 状態に到達しません。コントロールプレーンの停止は一時的なものであり、マイナー更新が完了すると自動的に回復します。コントロールプレーンの停止は、すでに実行中のワークロードには影響しません。

回避策: この中断を防ぐには、Red Hat ナレッジベースの記事 How to enable mirrored queues in Red Hat Openstack Services on OpenShift を参照してください。

Jira:OSPRH-10790

この機能拡張により、RHOSO のコンピュートインスタンス高可用性 (インスタンス HA) サービスに TAGGED_AGGREGATES パラメーターが追加されます。デフォルトでは、このパラメーターは true に設定されており、インスタンス HA サービスはタグ付けされたホストアグリゲートをチェックします。このパラメーターを false に設定すると、インスタンス HA サービスはタグ付けされたホストアグリゲートを確認しないため、対象となるすべてのコンピュートノードを退避します。

Jira:OSPRH-16342

S3 バックエンドを使用してマルチパートイメージをアップロードする場合は、インポートワークフローを使用する必要があります。

Jira:OSPRH-11018

現在、Red Hat Ceph Storage 8 との統合では NFS はサポートされていません。

回避策: 現時点で回避策はありません。

Jira:OSPRH-14788

Red Hat Ceph Storage Object Gateway (RGW) は、現在、Red Hat Ceph Storage 8 との統合ではサポートされていません。

回避策: 現時点で回避策はありません。

Jira:OSPRH-14789

Compute サービス (nova) の電源管理機能は、デフォルトでは無効になっています。次の nova-compute 設定でこれを有効にできます。

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

デフォルトの cpu_power_management_strategy cpu_state は現在サポートされていません。nova-compute を再起動すると、そのホスト上のすべての専用 PCPU (インスタンスが使用しているものも含む) の電源がオフになります。cpu_state ストラテジーを使用すると、それらのインスタンスの CPU は固定が解除されます。

Jira:OSPRH-10772

この更新前は、後方互換性を確保するために、iptables のデフォルトテーブルが nftables に追加されていました。しかし、デフォルトの DROP ルールの代わりにデフォルトの ALLOW INPUT ルールがあり、デプロイメントの最後に nftables がリロードされませんでした。この更新により、正しいルールが適用され、デプロイメントの最後に nftables が確実にリロードされます。

Jira:OSPRH-15473

redhat サービスは、データプレーンサービスのデフォルトリストから一時的に削除されました。その結果、コンピュートノードにサブスクリプションまたはリポジトリーをアタッチし、データプレーンシークレットを作成するときにドキュメント化された rhc_* パラメーターを使用すると、ノードは登録されず、データプレーンのデプロイメントは失敗します。

回避策: OpenStackDataPlaneNodeSet CR 内のサービスリストをオーバーライドし、リストの最初のサービスとして redhat サービスを追加するようにします。Red Hat OpenStack Services on OpenShift デプロイメントのカスタマイズ の データプレーンサービス に表示されるデフォルトのリストをコピーできます。

Jira:OSPRH-15644

この更新前は、事前にビルドされたディスク全体のイメージに device-mapper-multipath パッケージが含まれていなかったため、ペアになったブート RAM ディスクがマルチパスブロックストレージをサポートできませんでした。その結果、マルチパスブロックストレージがあるベアメタルノードは、デプロイメント後に起動できず、緊急シェルでスタックしていました。この更新により、事前にビルドされたディスク全体のイメージには device-mapper-multipath パッケージが含まれ、デプロイされたベアメタルノードでデプロイ後に緊急シェルが発生しなくなりました。

Jira:OSPRH-15887

この更新前は、RHOSO が BGP による動的ルーティングを使用するように設定されている場合にデータプレーンノードにデプロイされる Free Range Routing (FRR) サービスのログは使用できませんでした。この更新により、これらのログが利用できるようになります。

Jira:OSPRH-10204

この更新前は、edpm_tripleo_cleanup タスクの後にレガシーの tripleo Networking サービス (neutron) サービスが存在し、これを手動で削除する必要がありました。これらのサービスは導入後に停止されるため、RHOSO サービスは影響を受けませんでした。この更新により、すべての tripleo Networking サービスは、データプレーンノードの導入後に削除されます。

Jira:OSPRH-11323

外部 MTU が内部 MTU より大きい場合、RHOSO は想定どおりに north-south パケットを断片化しません。代わりに、Ingress パケットは通知なしにドロップされます。

また、テナントネットワーク間の east/west トラフィックでも、断片化は機能しません。

これらの問題が解決されるまで、外部の MTU 設定が内部の MTU 設定以下であること、および east/west 経路上のすべての MTU 設定が等しいことを確認してください。

回避策:

これらの問題が解決されるまで、次の手順を実行して、外部の MTU 設定が内部の MTU 設定以下であること、および east/west 経路上のすべての MTU 設定が等しいことを確認してください。

たとえば、外部ネットワーク datacentre の MTU が 1500 であるとします。

Egress QoS ポリシールール (最大帯域幅および/または最小帯域幅) を持つすべての VLAN またはフラットネットワークポートは、この情報を Logical_Switch_Port. options ディクショナリーに保存します。ポート名の変更やライブマイグレーションなど、このポートを更新すると、この QoS 情報が削除されます。

回避策: QoS 情報を復元するには、このポートの QoS ポリシーを削除して再度設定する必要があります。

Jira:OSPRH-15457

Physical Function (PF) がインスタンスにアタッチされている場合、os-net-config を再実行すると、os-net-config はホスト内の SR-IOV PF を見つけることができず、デプロイメント、更新または導入が失敗します。

回避策: 導入またはネットワーク更新を実行する前に、インスタンスを別のコンピュートホストに移行します。

Jira:OSPRH-12024

os-net-config 設定ツールは、ドライバーバインディングに NetworkManager-dispatcher スクリプトを使用します。SELinux が有効になっている場合、これらのスクリプトは実行に失敗し、os-net-config ネットワークのデプロイメントは失敗します。

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

Jira:OSPRH-13544

この更新前は、サービス設定の更新が失敗すると、その失敗はデプロイメントの状態ステータスに反映されませんでした。代わりに、更新により作成された新しい Pod はデプロイメントの準備状況の確認時に考慮されないため、Ready 状態が True と表示されました。この更新により、設定の更新中に作成された新しい Pod は、デプロイメントの準備状況の評価時に考慮されるようになりました。新しい Pod のロールアウトに失敗すると、それを反映してデプロイメントは Deployment in progress でスタックしていることが示されます。

Jira:OSPRH-14472

マイナー更新中、RHOSO コントロールプレーンは一時的に利用できなくなります。API リクエストは、エラー 500 などの HTTP エラーコードで失敗する可能性があります。または、API リクエストは成功しても、基礎となるライフサイクル操作が失敗する可能性があります。たとえば、マイナー更新中に openstack server create コマンドで作成された仮想マシン (VM) は、ACTIVE 状態に到達しません。コントロールプレーンの停止は一時的なものであり、マイナー更新が完了すると自動的に回復します。コントロールプレーンの停止は、すでに実行中のワークロードには影響しません。

回避策: この中断を防ぐには、Red Hat ナレッジベースの記事 How to enable mirrored queues in Red Hat Openstack Services on OpenShift を参照してください。

Jira:OSPRH-10790

この更新前は、RHOSO コントロールプレーンによって生成された CA バンドルは、デプロイ済みまたは実行中のサービスのデータプレーンノードにデプロイされていましたが、データプレーンノード自体に CA バンドルとしてインストールされませんでした。CA バンドルには、Satellite にアクセスするためなど、カスタムサードパーティー CA ファイルを含めることができます。この更新により、CA バンドルがデータプレーンノードにインストールされます。

Jira:OSPRH-14205

この更新前は、Compute サービス (nova) API で設定エラーが発生した場合、500 エラーが一度返され、その後リロード後に壊れた設定で実行され続けました。この問題は、アプリケーションの初期化中にエラーが発生したときに、mod_wsgi が wsgi アプリケーションを同じ Python インタープリターに再ロードしたために発生しました。この更新により、Compute サービスが変更され、アプリケーションが正常に再起動するまで設定エラーが再度発生するようになりました。現在、無効な設定でデプロイすると、Compute サービス API CR は ready チェックに失敗し、OpenShift CR のステータスフィールドを更新して、設定エラーのログファイルを確認するように要求します。

Jira:OSPRH-9737

Compute サービス (nova) の電源管理機能は、デフォルトでは無効になっています。次の nova-compute 設定でこれを有効にできます。

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor

デフォルトの cpu_power_management_strategy cpu_state は現在サポートされていません。nova-compute を再起動すると、そのホスト上のすべての専用 PCPU (インスタンスが使用しているものも含む) の電源がオフになります。cpu_state ストラテジーを使用すると、それらのインスタンスの CPU は固定が解除されます。

Jira:OSPRH-10772

redhat サービスは、データプレーンサービスのデフォルトリストから一時的に削除されました。その結果、コンピュートノードにサブスクリプションまたはリポジトリーをアタッチし、データプレーンシークレットを作成するときにドキュメント化された rhc_* パラメーターを使用すると、ノードは登録されず、データプレーンのデプロイメントは失敗します。

回避策: OpenStackDataPlaneNodeSet CR 内のサービスリストをオーバーライドし、リストの最初のサービスとして redhat サービスを追加するようにします。Red Hat OpenStack Services on OpenShift デプロイメントのカスタマイズ の データプレーンサービス に表示されるデフォルトのリストをコピーできます。

Jira:OSPRH-15644

今回のアップデート以前は、Border Gateway Protocol (BGP) を使用したダイナミックルーティングで RHOSO をデプロイした場合、BFD および BGP ポートを許可する nft ルールが存在しなかったため、双方向フォワーディング検出 (BFD) が期待どおりに機能しませんでした。この更新では、nft ルールが追加され、BFD が期待どおりに動作するようになりました。

  BGP
       - 179 tcp
   BFD
       - 3784 udp
       - 3785 udp
       - 4784 udp
       - 49152 udp
       - 49153 udp

Jira:OSPRH-14536

RHOSO が BGP による動的ルーティングを使用するように設定されている場合、データプレーンノードにデプロイされる FRR サービスにはログがありません。

回避策:

OpenstackDataplaneDeployment が完了した後に FRR ログを取得するには、FRR を実行しているすべての networker ノードとコンピュートノードで次のアクションを実行します。

edpm_tripleo_cleanup タスクの後でも、レガシーの tripleo Networking サービス (neutron) のサービスが残っています。これらのサービスは導入後に停止されるため、RHOSO サービスには影響しません。

回避策:

レガシーサービスを手動で削除するには、次の手順を実行します。

外部 MTU が内部 MTU より大きい場合、RHOSO は想定どおりに north-south パケットを断片化しません。代わりに、Ingress パケットは通知なしにドロップされます。

また、テナントネットワーク間の east/west トラフィックでも、断片化は機能しません。

これらの問題が解決されるまで、外部の MTU 設定が内部の MTU 設定以下であること、および east/west 経路上のすべての MTU 設定が等しいことを確認してください。

回避策: