Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

2.5. リリース情報 RHOSO 18.0.6

Red Hat OpenStack Services on OpenShift のこのリリースの既知の問題、バグ修正、およびその他のリリースノートを確認します。

2.5.1. アドバイザリーの一覧
リンクのコピー

Red Hat OpenStack Services on OpenShift (RHOSO) のこのリリースには、次のアドバイザリーが含まれています。

RHBA-2025:3029
RHOSO 18.0.6 のコンポーネントのリリース (機能リリース 2)
RHBA-2025:3030
RHOSO 18.0.6 のデータプレーン Operator (機能リリース 2)
RHBA-2025:3031
RHOSO 18.0.6 の Operator のリリース (機能リリース 2)
RHBA-2025:3032
RHOSO 18.0.6 のコントロールプレーン Operator (機能リリース 2)
RHBA-2025:3033
RHOSO 18.0.6 のコンテナーのリリース (機能リリース 2)

2.5.2. Observability
リンクのコピー

2.5.2.1. 新機能
リンクのコピー

この部分では、Red Hat OpenStack Services on OpenShift 18.0 で導入された新機能と主な機能拡張を説明します。

RHOSO Observability のメトリクスの改善

RHOSO サービスの健全性を監視するために、以下をはじめとする新しいメトリクスを使用できるようになりました。

  • kube_pod_status_phase
  • kube_pod_status_ready
  • node_systemd_unit_state
  • podman_container_state
  • podman_container_health

kube_pod_status_phase と kube_pod_status_ready を使用して、コントロールプレーンサービスを監視できます。

  • kube_pod_status_phase - 関連するパラメーターは Phase、値は Pending、Running、Succeeded、Failed、Unknown のいずれかで、対応するブール値は 1 または 0 です。
  • kube_pod_status_ready - このメトリクスにもブール値があり、1 は Pod ですべてのコンテナーが実行されており、レディネスプローブが成功していることを示し、0 は Pod ですべてのコンテナーが実行されていないか、レディネスプローブが成功しなかったことを示します。

node_systemd_unit_state を使用して、データプレーンサービスの実行状態を監視できます。

  • node_systemd_unit_state - 関連するパラメーターは`State` で、値は activating、active、deactivating、failed、inactive、対応するブール値は 1 または 0 です。

podman_container_state と podman_container_health を使用して、データプレーンのコンテナー化されたサービスの健全性を監視できます。

  • podman_container_state - このメトリクスの値には、-1=不明、0=作成済み、1=初期化済み、2=実行中、3=停止、4=一時停止、5=終了、6=削除中、7=停止中があります。
  • podman_container_health - このメトリクスの値には、-1=不明、0=正常、1=異常、2=開始中があります。

Jira:OSPRH-1052

追加の Ceilometer メトリクスが利用可能

VMs: ceilometer_power_state メトリクスを取得して、libvirt の電源状態を示すことができるようになりました。

Jira:OSPRH-10377

追加の仮想マシンメトリクスが利用可能

ダッシュボードを使用して、専用の仮想マシンネットワークトラフィックダッシュボードを表示したり、仮想マシンの電源状態を監視できるようになりました。

Jira:OSPRH-10481

Ceilometer IPMI でハードウェアセンサーメトリクスを可視化する

ダッシュボードを使用して、コンピュートノードから利用可能な IPMI センサーハードウェアメトリクスを表示できるようになりました。

Jira:OSPRH-10808

Kepler ダッシュボードがよりユーザーフレンドリーに (テクノロジープレビュー)

Compute サービス UUID ではなく、人間が判読できるホスト名でコンピュートノードを表示できるようになりました。

Jira:OSPRH-11755

Telemetry Operator と OpenShift Logging 間の互換性が向上

OpenShift Logging バージョン 6.1 以降で Telemetry Operator を使用できるようになりました。

Jira:OSPRH-12147

Prometheus の接続情報をシークレットに公開

Telemetry Operator は、内部 Prometheus 接続の詳細が含まれるシークレットを作成します。他の OpenShift サービスは、そのシークレットをサービス検出メカニズムとして使用して、Prometheus に接続できます。

Jira:OSPRH-13223

2.5.2.2. バグ修正
リンクのコピー

ここでは、ユーザーに大きな影響を与えるバグで、Red Hat OpenStack Services on OpenShift 18.0 で修正されたものを説明します。

手動介入なしでの Kepler メトリクスのスクレイピング (テクノロジープレビュー)

この更新前は、コンピュートノードにファイアウォールが適用されていなかったため、ポート 8888 を開くことができました。しかし、ファイアウォールが有効になっている場合、ポート 8888 へのアクセスが予期せず失われる可能性がありました。この更新により、ansible ロールはファイアウォールが有効になっているかどうかを確認してからポート 8888 を開くようになります。その結果、Prometheus は手動介入なしで Kepler メトリクスをスクレイピングできます。

Jira:OSPRH-11066

Kepler で GPU メトリクスをキャプチャーする (テクノロジープレビュー)

Red Hat OpenStack Services on OpenShift (RHOSO) の今回の更新により、Kepler を使用して GPU メトリクスをキャプチャーできるようになりました。

Jira:OSPRH-11890

TLS エラーが原因でノードエクスポーターのスクレイピングで問題が発生

Red Hat OpenStack Services on OpenShift (RHOSO) のこのリリースでは、特定のデータプレーン設定でのメトリクスのスクレイピングに関する問題が修正されています。

Jira:OSPRH-12359

IPv6 アドレスを囲む角括弧の欠落

Red Hat OpenStack Services on OpenShift (RHOSO) のこのリリースでは、IPv6 アドレスを囲う角括弧が欠落しているために発生する可能性のあるデータスクレイピングの問題が修正されています。

Jira:OSPRH-13151

IPv6 での RabbitMQ メトリクスへの接続が拒否されました。

Red Hat OpenStack Services on OpenShift (RHOSO) の今回の更新により、RabbitMQ メトリクスエクスポーターは IPv6 コントロールプレーンネットワーク上の正しいインターフェイスをリッスンするようになりました。

Jira:OSPRH-13152

2.5.3. コンピュート
リンクのコピー

2.5.3.1. 新機能
リンクのコピー

この部分では、Red Hat OpenStack Services on OpenShift 18.0 で導入された新機能と主な機能拡張を説明します。

統合制限の導入

この更新では、RHOSO 18.0 に統合制限が導入されます。統合制限は、クォータ制限が一元的に Identity サービスに保存される最新のクォータシステムです。文書化された手順に従うことで、統合制限を有効にできます。

Jira:OSPRH-9518

ハイパーバイザー上における systemd-container パッケージのインストールの検証

データプレーンの導入の最終手順を開始する前に、systemd-container パッケージがハイパーバイザーにインストールされていることを確認できるようになりました。パッケージがすべてのハイパーバイザーにインストールされるまで、ソースの Red Hat OpenStack Platform クラウドを Red Hat OpenStack Services on OpenShift (RHOSO) に導入することはできません。

Jira:OSPRH-10321

Nova 内部インスタンス情報キャッシュの定期的な修復を無効化

nova-compute エージェントによって作成された負荷を削除することで、neutron API サーバーのパフォーマンスを高めるために、heal_instance_info_cache_interval がデフォルトで無効になりました。これは、ほとんどの仮想マシン操作中に更新されるため、キャッシュの正確性には影響しません。

Jira:OSPRH-10744

hugepage を持つノードの導入をサポート

この更新により、データプレーンの導入では、hugepage を使用するために設定された OSP ワークロードを持つハイパーバイザーのインポートがサポートされるようになりました。

Jira:OSPRH-12073

Nova により NVIDIA vGPU インスタンスのライブマイグレーションが可能に

Nova は、ターゲットが同じ NVIDIA ドライバーバージョンと同じ仲介タイプを使用している場合に、ホスト間で vGPU リソースを使用してインスタンスのライブマイグレーションを可能にします。

ライブマイグレーションを行うには、Operator は各ホストの設定を変更する必要があります。 

[libvirt]
live_migration_completion_timeout = 0
live_migration_downtime = 500000
live_migration_downtime_steps = 3
live_migration_downtime_delay = 3
Copy to Clipboard Toggle word wrap

Jira:OSPRH-13767

Compute サービス (nova) と placement サービスのトポロジーサポート

TopologySpreadConstraints および Affinity/Anti-Affinity ルールに基づき、RHOSO Nova および Placement サービスの Pod をスケジュールするための新しいカスタムリソース定義を実装しました。

Jira:OSPRH-13785

nova_statedir_ownership.py に関連する更新の失敗を修正

この修正の前は、RHOSO18.0.3 からそれ以降のリリースへの更新は、nova_statedir_ownership.py スクリプトの欠落に関連するエラーで失敗していました。この修正により、RHOSO 18.0.3 から RHOSO 18.0.6 (機能リリース 2) への更新でこれらのエラーは生成されなくなります。

Jira:OSPRH-14506

2.5.3.2. バグ修正
リンクのコピー

ここでは、ユーザーに大きな影響を与えるバグで、Red Hat OpenStack Services on OpenShift 18.0 で修正されたものを説明します。

割り当て候補が Placement GET/allocation_candidates クエリーでホスト間に分散される

たとえば同じルートの下に同じリソースクラスのインベントリーを持つ複数の子プロバイダーがある、幅広く対称的なプロバイダーツリーを持つデプロイメントでは、割り当て候補リクエストが複数のリクエストグループ内のそれらの子リソースプロバイダーからリソースをリクエストすると、割り当て候補の数は急速に増加します。Placement サービスは、割り当て候補クエリーで指定された制限パラメーターを適用する前に、これらの候補を完全に生成します。Placement サービスでは、この量の割り当て候補を生成するために過度の時間とメモリーを消費し、クライアントがタイムアウトする可能性があります。

リクエストのタイムアウトやメモリー不足イベントを回避するために、候補生成プロセス中に新しい [placement]max_allocation_candidates 設定オプションが適用されます。デフォルトでは、[placement]max_allocation_candidates オプションは -1 に設定されています。これは以前の動作と同じで、制限がないことを意味します。Placement サービスに使用可能なメモリーとクライアントのタイムアウト設定に基づき、影響を受けるデプロイメントでこの設定オプションの値を編集します。推奨値は 100000 です。

生成される割り当て候補の数が [placement]max_allocation_candidates 設定オプションで制限されている場合、Placement サービスは depth-first ストラテジーを使用して、最初のルートからすべての候補を生成してから次のルートを検討するため、コンピュートノードなどの限られたルートプロバイダーセットから候補を取得できます。これを回避するには、[placement]allocation_candidates_generation_strategy 設定オプションを使用します。これには次の 2 つの値を指定できます。

  • depth-first: 次のルートプロバイダーに移動する前に、最初の実行可能なルートプロバイダーからすべての候補を生成します。これはデフォルトであり、従来の動作をトリガーします。
  • breadth-first: ラウンドロビン方式で実行可能なルートから候補を生成し、実行可能なルートごとに 1 つの候補を作成してから、最初のルートから 2 番目の候補を作成します。これは新しい動作です。

[placement]max_allocation_candidates が正の数に設定されているデプロイメントでは、[placement]allocation_candidates_generation_strategy を breadth-first に設定します。

Jira:OSPRH-37

NFS 共有上の一時ストレージを持つインスタンスが Compute サービスの再起動後に動作を継続する

この更新前は、NFS 共有上の一時ストレージを持つ Compute サービス (nova) インスタンスは、ハイパーバイザーホストでコンテナー化された Compute エージェントサービスが再起動するとすぐに動作を停止しました。

この更新により、NFS 共有上の一時ストレージを備えた Nova Compute サービスインスタンスが動作を停止しなくなりました。Nova Compute の init コンテナーは、リンクされた Openstack Dataplane Nodeset に含まれる Nova EDPM サービスを使用して Openstack Dataplane デプロイメントが作成されるたびにトリガーされ、ハイパーバイザー上における /var/lib/nova/ ディレクトリーの内容の権限を修正します。

Jira:OSPRH-10729

nova_statedir_ownership.py に関連する更新の失敗を修正

この修正の前は、RHOSO18.0.3 からそれ以降のリリースへの更新は、nova_statedir_ownership.py スクリプトの欠落に関連するエラーで失敗していました。この修正により、RHOSO 18.0.3 から RHOSO 18.0.6 (機能リリース 2) への更新でこれらのエラーは生成されなくなります。

Jira:OSPRH-13415

修正済み: NFS 共有上の一時ストレージを持つインスタンスが Compute サービスの再起動後に動作を停止する

この更新前は、NFS 共有上の一時ストレージを持つ Compute サービス (nova) インスタンスは、ハイパーバイザーホストでコンテナー化された Compute エージェントサービスが再起動するとすぐに動作を停止しました。これは、/var/lib/nova/ インスタンスの権限が変更されたために発生していました。

今回の更新でこのバグが修正されています。

Jira:OSPRH-14197

2.5.3.3. 既知の問題
リンクのコピー

この部分では、Red Hat OpenStack Services on OpenShift 18.0 の既知の問題を説明します。

Compute サービスの電源管理機能はデフォルトで無効化される

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

[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor
Copy to Clipboard Toggle word wrap

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

Jira:OSPRH-10772

Block Storage サービス (cinder) の既知の問題

Red Hat Ceph Storage を Block Storage サービス (cinder) のバックエンドとして使用している場合、アタッチされた暗号化ボリュームを拡張できない可能性があります。回避策: 暗号化された RBD ボリュームをデタッチし、拡張してから再度アタッチします。

Jira:OSPRH-14321

2.5.4. データプレーン
リンクのコピー

2.5.4.1. 新機能
リンクのコピー

この部分では、Red Hat OpenStack Services on OpenShift 18.0 で導入された新機能と主な機能拡張を説明します。

クラウドをスケーリングせずに障害ノードを置き換える

今回の更新により、クラウドを拡張せずに障害が発生したノードを置き換えるオプションが提供されます。

  • 事前にプロビジョニングされたノードの場合は、OpenStackDataPlaneNodeSet CR でノードの新しい ansibleHost を設定します。
  • プロビジョニングされたノードの場合は、障害が発生したベアメタルホスト (BMH) を削除します。OpenStackBaremetalSet CR が調整され、新しい利用可能な BMH がプロビジョニングされて OpenStackDataPlaneNodeSet のデプロイメントステータスがリセットされ、新しくプロビジョニングされたノードにデプロイするための新しい OpenStackDataPlaneDeployment CR を作成するように求められます。

スケールインの場合と同様に、削除されたノードは手動でクリーンアップする必要があります。

Jira:OSPRH-13948

2.5.4.2. バグ修正
リンクのコピー

ここでは、ユーザーに大きな影響を与えるバグで、Red Hat OpenStack Services on OpenShift 18.0 で修正されたものを説明します。

ドキュメント: OpenStackDataPlaneNodeSet CR 名の最大長を詳細に説明した制限を追加

`OpenStackDataPlaneNodeSet` CR の命名に関するルールの説明が更新され、最大長が 53 文字であることが記載されました。

Jira:OSPRH-12327

2.5.5. ネットワーク
リンクのコピー

2.5.5.1. バグ修正
リンクのコピー

ここでは、ユーザーに大きな影響を与えるバグで、Red Hat OpenStack Services on OpenShift 18.0 で修正されたものを説明します。

Load-balancing サービスのデフォルトの anti-affinity ポリシーを修正

この更新前は、active-standby トポロジーで amphorae を作成するときに、octavia Operator は anti-affinity を有効にしていませんでした。場合によっては、仮想マシンが同じコンピュートノードにスケジュールされていました。

このリリースではこの問題が修正され、anti-affinity が有効になっています。

Jira:OSPRH-10705

Load-balancing サービスプロバイダーのネットワーク可視性を修正

この更新前は、エンドユーザーに Load-balancing サービスプロバイダーネットワークが表示されていました。Load-balancing サービスプロバイダーネットワークは管理者にのみ表示されるようになりました。

Jira:OSPRH-12519

オフラインクラスターに Load-balancing サービスをデプロイする

この更新前は、octavia-rsyslog Pod のコンテナーイメージ URL はハードコードされており、オーバーライドできませんでした。そのため、ユーザーはオフラインクラスターに Load-balancing サービス (octavia) をデプロイできませんでした。

この更新により、コンテナーイメージ URL をオーバーライドできるようになり、Load-balancing サービスをオフラインでデプロイできるようになります。

Jira:OSPRH-13530

DCN モードでの Load-balancing サービスヘルスマネージャーの安定性の問題を修正

この更新前は、Load-balancing サービス (octavia) ヘルスマネージャー Pod を DCN モードで実行すると、Pod は Operator によってランダムに再起動されていました。この更新により、ランダムな再起動は発生しなくなります。

Jira:OSPRH-13951

Load-balancing サービスの rsyslog エンドポイントがリモートエリアゾーンからのログをドロップしなくなった

この更新前は、DCN で rsyslog サービスを使用した場合、リモート DCN へのルートが見つからないため、rsyslog Pod は受信 rsyslog パケットをドロップしていました。現在、パケットはドロップされません。

Jira:OSPRH-14085

2.5.5.2. テクノロジープレビュー
リンクのコピー

この部分では、Red Hat OpenStack Services on OpenShift 18.0 で利用可能なすべてのテクノロジープレビューのリストを示します。

テクノロジープレビュー機能のサポート範囲については、テクノロジープレビュー機能 - サポート範囲 を参照してください。

amphora 垂直スケーリング (スレッド/CPU ピニング) (テクノロジープレビュー)

このテクノロジープレビューを使用すると、改善された、amphora ドライバーにおける Load-balancing サービスの垂直スケーリングサポートの処理をテストできます。このテクノロジープレビューの更新では、改善された垂直スケーリングのために特別に最適化された追加の amphora イメージと、複数の仮想 CPU を使用する追加のロードバランサーフレーバーが使用されます。これにより、ロードバランサーのレイテンシーとスループットが向上します。

Jira:OSPRH-370

Load-balancing サービスを使用する TLS クライアント認証 (テクノロジープレビュー)

この更新には、証明書を使用して双方向 TLS 認証を確立する、RHOSO Load-balancing サービス (octavia) TLS 終端 HTTPS ロードバランサーとの TLS Web クライアント通信のテクノロジープレビューが含まれています。

Jira:OSPRH-1375

分散ゾーン機能の Load-balancing サービス (octavia) のサポート (テクノロジープレビュー)

この更新では、Load-balancing サービス (octavia) のアベイラビリティーゾーン (AZ) のテクノロジープレビューが導入され、プロジェクトユーザーは分散ゾーン環境でロードバランサーを作成して、トラフィックのスループットを増やし、レイテンシーを削減できるようになります。

Jira:OSPRH-8336

同じネットワークからの複数の Load-balancing グサービス仮想 IP アドレス

Amphora プロバイダーを使用した Octavia の Load-balancing サービスで、同じ Neutron ネットワークから割り当てられた複数の仮想 IP アドレスが必要になるユースケースがあります。このテクノロジープレビューを使用すると、仮想 IP ポートに関連付ける追加の subnet_id/ip_address ペアを指定する機能をテストできます。これにより、ロードバランサーに IPv4 アドレスと IPv6 アドレスの両方を同時に設定したり、パブリックサブネットとプライベートサブネットの両方に公開したりするシナリオが可能になります。

Jira:OSPRH-14480

TLS 暗号とプロトコルのサポートの改善 (テクノロジープレビュー)

この更新では、TLS 暗号とプロトコルに対する改良された Load-balancing サービス (octavia) サポートのテクノロジープレビューが導入されます。デフォルトの暗号リストをサイトに適した値でオーバーライドする機能や、各リスナーの暗号リストとプロトコルリストを設定する機能など、追加の新機能を使用できるようになりました。

Jira:OSPRH-14705

IPv6 負荷分散ネットワーク [テクノロジープレビュー]

負荷分散管理ネットワークに IPv6 CIDR を使用するテクノロジープレビューをテストできるようになりました。

Jira:OSPRH-14811

2.5.5.3. 既知の問題
リンクのコピー

この部分では、Red Hat OpenStack Services on OpenShift 18.0 の既知の問題を説明します。

FRR サービスにログがない

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

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

  1. /var/lib/config-data/ansible-generated/frr/etc/frr/frr.conf`file and replace `log file を log file /var/log/frr/frr.log で編集します。
  2. /var/lib/kolla/config_files/frr.json を編集し、sleep infinity を tail -f /var/log/frr/frr.log に置き換えます。
  3. FRR を再起動します: systemctl restart edpm_frr。

Jira:OSPRH-10204

導入後のレガシー Tripleo Networking サービス (neutron)

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

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

  • tripleo Neutron サービスリストを確認します (systemctl list-unit-files --type service)。
  • /etc/systemd/system/ から tripleo サービスを削除します。

Jira:OSPRH-11323

外部 MTU が内部 MTU より大きい場合、パケットは通知されることなくドロップされます

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

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

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

手順:

  1. ovn_emit_need_to_frag を true に設定します。
  2. Geneve トンネルのカプセル化オーバーヘッドに対応するために、global_physnet_mtu を外部ネットワーク MTU より 58 バイト以上大きいサイズに設定します。
  3. 各物理ネットワークの MTU を記述するには、physical_network_mtus 値のペアを設定します。
  4. 外部ネットワーク上のすべてのデバイスの MTU 設定が内部 MTU 設定よりも小さいことを確認します。
  5. 既存のルーターに変更を適用するには、ルーターを削除して再作成します。

例

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

  1. OpenStackControlPlane CR に次の Neutron 設定を入力します。 

    neutron:
    enabled: true
:
    template:
 :
      customServiceConfig: |
        [DEFAULT]
        global_physnet_mtu=1558
        [ml2]
        physical_network_mtus = ["datacentre:1500_{context}"]
        [ovn]
        ovn_emit_need_to_frag = true
    Copy to Clipboard Toggle word wrap
  2. 外部ネットワーク上のすべてのデバイスの MTU 設定が内部 MTU 設定よりも小さいことを確認します。
  3. OVN ルーターを使用するすべてのテナントネットワークの MTU が同じであることを確認します。
  4. 既存のルーターに変更を適用するには、ルーターを削除して再作成します。

Jira:OSPRH-12695

動的ルーティングを使用した RHOSO デプロイメントでは BFD が期待どおりに動作しないため、回避策が必要

ボーダーゲートウェイプロトコル (BGP) を使用した動的ルーティングで RHOSO をデプロイすると、双方向転送 (BFD) が期待どおりに動作しません。

回避策: OpenstackDataplaneNoteSet CR に NFT ルールを追加します。これには 2 通りの方法があります。1 つ選択してください。

  1. edpm_frr_bfd を false に設定して BFD を無効にします。
  2. BFD トラフィックを許可するように edpm_nftables_user_rules を設定します。 
edpm_nftables_user_rules: |
  - rule_name: 121 frr bgp port
    rule:
      proto: tcp
      dport:
       - 179
  - rule_name: 122 frr bfd ports
    rule:
      proto: udp
      dport:
       - 3784
       - 3785
       - 4784
       - 49152
       - 49153
      state: ["UNTRACKED_{context}"]
Copy to Clipboard Toggle word wrap

Jira:OSPRH-14536

物理インターフェイスがボンディングである場合、物理ネットワークのポートに最大帯域幅 (Egress) ルールのみが存在する場合は QoS ポリシーは適用されません。

最大帯域幅のみの QoS ルールと Egress 方向を持つ物理ネットワーク (VLAN、フラット) に接続されたポートは、物理ネットワークインターフェイスを使用して、TC コマンド経由で QoS ルールを適用します。

以前のバージョンでは、Neutron がネットワークタイプとルールの方向にかかわらず、OVN ポリサーを使用して帯域幅制限ルールを適用していました。

RHOSO 18.0.6 以降では、環境でボンディングを使用して物理ブリッジを物理ネットワークに接続すると、QoS は適用されなくなります。詳細は、https://issues.redhat.com/browse/OSPRH-18010 を参照してください。

Jira:OSPRH-18011

2.5.6. ネットワーク機能仮想化
リンクのコピー

2.5.6.1. バグ修正
リンクのコピー

ここでは、ユーザーに大きな影響を与えるバグで、Red Hat OpenStack Services on OpenShift 18.0 で修正されたものを説明します。

os-net-config プロバイダーを nmstate に変更

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

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

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

Jira:OSPRH-11309

2.5.6.2. テクノロジープレビュー
リンクのコピー

この部分では、Red Hat OpenStack Services on OpenShift 18.0 で利用可能なすべてのテクノロジープレビューのリストを示します。

テクノロジープレビュー機能のサポート範囲については、テクノロジープレビュー機能 - サポート範囲 を参照してください。

OVS-DPDK の TSO (テクノロジープレビュー)

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

詳細は、ネットワーク機能仮想化環境のデプロイ (https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/deploying_a_network_functions_virtualization_environment/plan-ovs-dpdk-deploy_rhoso-nfv#ovsdpdk-tso_plndpdk-nfv) の「TCP セグメンテーションオフロードを備えた OVS-DPDK (テクノロジープレビュー)」を参照してください。

Jira:OSPRH-3885

2.5.6.3. 非推奨の機能
リンクのコピー

この部分では、Red Hat OpenStack Services on OpenShift 18.0 で 非推奨 になった機能の概要を説明します。

非推奨の機能は、本製品の今後のメジャーリリースではサポートされない可能性が高く、新たに実装することは推奨されません。

edpm_ovs_dpdk_lcore_list 変数が非推奨に

RHOSO デプロイメントで edpm_ovs_dpdk_lcore_list Ansible 変数を使用しなくなりました。これは、以前は NFV 環境のデータプレーンデプロイメントで OVS DPDK を有効にするために、ノードセット CR 定義ファイルで使用されていました。これは不要になり、サポート対象外となりました。これを使用すると、デプロイメントエラーが発生します。

Jira:OSPRH-14642

2.5.6.4. 既知の問題
リンクのコピー

この部分では、Red Hat OpenStack Services on OpenShift 18.0 の既知の問題を説明します。

Physical Function が仮想マシンインスタンスにアタッチされている場合に導入が失敗する

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

Jira:OSPRH-12024

cpu-partitioning-powersave プロファイルを使用する場合に no_turbo を設定できない

カーネルの no_turbo パラメーターの設定に関する問題により、cpu-partitioning-powersave プロファイルを使用すると tuned がハングして失敗します。

回避策: edpm_bootstrap_command に次の設定を追加して、デプロイメントの一部である tuned を古いバージョンにダウングレードします。 

...
edpm_bootstrap_command: |-
...
dnf downgrade tuned-2.24.0
…
Copy to Clipboard Toggle word wrap

Jira:OSPRH-14688

マイナー更新中にリクエストされたサービスが見つからない

データプレーン上の残りのサービスを更新するときに、edpm_openstack_network_exporter.service が見つからないため、18.0.3 から 18.0.6 へのマイナー更新が失敗します。

回避策: `OpenStackDataplaneService` カスタムリソースを更新する前に、openstack-edpm-update-services.yaml ファイルの servicesOverride フィールドにテレメトリーサービスを追加します。以下に例を示します。 

apiVersion: dataplane.openstack.org/v1beta1
kind: OpenStackDataPlaneDeployment
metadata:
  name: edpm-deployment-ipam-update-dataplane-services
spec:
  nodeSets:
    - openstack-edpm-ipam
  servicesOverride:
    - telemetry
    - update
Copy to Clipboard Toggle word wrap

Jira:OSPRH-14841

2.5.7. コントロールプレーン
リンクのコピー

2.5.7.1. 新機能
リンクのコピー

この部分では、Red Hat OpenStack Services on OpenShift 18.0 で導入された新機能と主な機能拡張を説明します。

単一の OLM バンドルでサービス Operator のインストールを管理する

OpenStack Operator は、複数の RHOSO サービス Operator を個別にインストールしなくなりました。代わりに、新しい初期化リソースが、単一の Operator Lifecycle Manager (OLM) バンドルの下でサービス Operator のインストールを管理します。新しいインストール方法の詳細は、Operator のインストールと準備 を参照してください。

Jira:OSPRH-11244

OpenStackClient Pod のカスタム環境変数

OpenStackClient Pod にカスタム環境変数を設定できます。

Jira:OSPRH-13969

2.5.7.2. 既知の問題
リンクのコピー

この部分では、Red Hat OpenStack Services on OpenShift 18.0 の既知の問題を説明します。

マイナー更新中はコントロールプレーンが一時的に利用できない

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

Jira:OSPRH-10790

2.5.8. ストレージ
リンクのコピー

2.5.8.1. 新機能
リンクのコピー

この部分では、Red Hat OpenStack Services on OpenShift 18.0 で導入された新機能と主な機能拡張を説明します。

シンプロビジョニングされたバックエンドでの Block Storage ボリュームの復元を強化

この機能拡張により、シンプロビジョニングされたバックエンドで Block Storage ボリュームのバックアップを復元するプロセスが最適化されます。以前は、シンプロビジョニングされたバックエンドでバックアップを復元する場合、使用されたボリューム部分のみを復元するのではなく、ボリューム全体のサイズが復元されていました。これにより、不要なネットワークトラフィックが発生し、復元プロセスにかかる時間が大幅に増加しました。この機能拡張により、シンプロビジョニングされたバックエンドでボリュームを復元するときに、使用されたボリューム部分のみが復元されるようになります。

Jira:OSPRH-1783

Red Hat Ceph Storage 8 のサポート

この機能拡張により、外部の Red Hat Ceph Storage 8 との統合のサポートが追加されます。既知の問題により、サポートされない Red Hat Ceph Storage 8 機能もあります。これらの問題の詳細は、「既知の問題」セクションを参照してください。

Jira:OSPRH-10661

2.5.8.2. バグ修正
リンクのコピー

ここでは、ユーザーに大きな影響を与えるバグで、Red Hat OpenStack Services on OpenShift 18.0 で修正されたものを説明します。

Pod に任意の名前が接頭辞として付けられている場合、ExtraMounts は per-instance の伝播を処理できる

uniquePodNames が true の場合、すべての Cinder Pod (一般的には各コンポーネントとサービスも) の先頭に疑似ランダム文字列が付けられます。この更新により、Pod に任意の名前が接頭辞として付けられている場合、ExtraMounts は per-instance の伝播を処理できるようになりました。

Jira:OSPRH-11240

2.5.8.3. 既知の問題
リンクのコピー

この部分では、Red Hat OpenStack Services on OpenShift 18.0 の既知の問題を説明します。

S3 バックエンドでマルチパートイメージアップロードは機能しない

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

Jira:OSPRH-11018

Red Hat Ceph Storage 8 NFS はサポート対象外

現在 RHOSO 18.0.6 では、Red Hat Ceph Storage 8 と統合する場合に NFS はサポートされていません。

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

Jira:OSPRH-14788

Red Hat Ceph Storage 8 Object Gateway はサポート対象外

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

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

Jira:OSPRH-14789

2.5.9. アップグレードおよび更新
リンクのコピー

2.5.9.1. 既知の問題
リンクのコピー

この部分では、Red Hat OpenStack Services on OpenShift 18.0 の既知の問題を説明します。

マイナー更新中に OpenStack のインスタンスを作成する

Red Hat OpenStack Services on OpenShift 環境を 18.0.6 より前のリリースから更新する場合は、openstack-operator を更新した後、すべての Operator のデプロイメントをトリガーするための openstack インスタンスを作成する必要があります。以下に例を示します。 

cat > openstack-init.yaml <<'EOF'
---
apiVersion: operator.openstack.org/v1beta1
kind: OpenStack
metadata:
   name: openstack
   namespace: openstack-operators
EOF

$ oc apply -f ./openstack-init.yaml
Copy to Clipboard Toggle word wrap

Jira:OSPRH-14826

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat