今回の更新以前は、Leapp のアップグレードを実行する前に、director は Red Hat Ceph Storage OSD に noout フラグを設定していませんでした。その結果、アップグレード後に OSD がバランスをとり直すのに追加の時間が必要でした。

今回の更新により、ディレクターは Leapp のアップグレード前に noout フラグを設定するようになり、これによりアップグレードプロセスが迅速化されました。また、director は Leapp のアップグレード後に noout フラグの設定を解除します。

PowerMax 設定オプションは、OSP10 newton から変更されています。今回の更新により最新の PowerMax 設定オプションが追加され、iSCSI ドライバーと FC ドライバーの両方がサポートされるようになりました。

CinderPowermaxBackend パラメーターも、複数のバックエンドをサポートします。CinderPowermaxBackendName はバックエンドのリストをサポートし、新しい CinderPowermaxMultiConfig パラメーターを使用して各バックエンドのパラメーター値を指定することができます。構文の例は、environments/cinder-droidmc-powermax-config.yaml を参照してください。

今回の更新以前は、IPv6 内部 API ネットワークを使用した DCN と HCI の組み合わせのデプロイメントでは、Block Storage サービス (cinder) および etcd サービスは不適切な etcd URI で設定され、Block Storage サービスおよび etcd サービスが起動時に失敗していました。

今回の更新により、etcd URI の IPv6 アドレスが正しくなり、Block Storage サービスおよび etcd サービスが正常に起動するようになりました。

今回の更新以前は、IPv6 内部 API ネットワークを使用したデプロイメントでは、Block Storage サービス (cinder) および Compute サービス (nova) は不適切な glance-api エンドポイントの URI で設定されていました。その結果、DCN またはエッジデプロイメントの Block Storage サービスおよび Compute サービスは、Image サービス (glance) にアクセスできませんでした。

今回の更新により、glance-api エンドポイントの URI の IPv6 アドレスが正しくなり、エッジサイトの Block Storage サービスおよび Compute サービスが正しく Image サービスにアクセスできるようになりました。

今回の更新以前は、Block Storage サービス (cinder) は、ボリューム種別を指定する代替方法を無視して volume create 要求のデフォルトボリューム種別を割り当てていました。

今回の更新により、Block Storage サービスが正しく機能するようになりました。

今回の更新以前は、Bare Metal Provisioning サービス (ironic) の直接デプロイインターフェイスを使用して最終的なインスタンスイメージをダウンロードする際に、リトライやタイムアウトがありませんでした。その結果、イメージをホストするサーバーが応答に失敗すると、デプロイメントに失敗する可能性がありました。

今回の更新により、イメージのダウンロードプロセスに 60 秒の接続タイムアウトが設定され、リトライを 2 回試みます。

ipmitool-1.8.18-11 にリグレッションが生じ、Get Cipher Suites をサポートしない特定の BMC の場合、IPMI アクセスに 2 分以上の時間がかかっていました。その結果、イントロスペクションに失敗し、デプロイメントにかかる時間が以前よりも大幅に長くなる可能性がありました。

今回の更新により、ipmitool のリトライ処理が変更され、イントロスペクションにパスし、デプロイメントに成功するようになりました。

今回の更新以前は、ExtraConfigPre per_node スクリプトは Python 3 と互換性がありませんでした。その結果、オーバークラウドのデプロイメントは、TASK [Run deployment NodeSpecificDeployment] のステップで SyntaxError: invalid syntax のメッセージと共に失敗していました。

今回の更新により、ExtraConfigPre per_node スクリプトが Python 3 と互換性を持ち、カスタムの per_node hieradata をプロビジョニングできるようになりました。

今回の更新以前は、ceph osd stat -f json コマンドが返すデータ構造の形式が変更されていました。その結果、一定の割合の Red Hat Ceph Storage (RHCS) OSD が実行されていない限りデプロイメントを停止する検証が正常に機能せず、動作中の OSD の数にかかわらずデプロイメントを停止していました。

今回の更新により、新しいバージョンの openstack-tripleo-validations が動作中の RHCS OSD の割合を正しく計算し、定義した割合の RHCS OSD が実行されていない場合に、デプロイメントが早期に停止するようになりました。パラメーター CephOsdPercentageMin を使用して、動作していなければならない RHCS OSD の割合をカスタマイズすることができます。デフォルト値は 66% です。検証を無効にするには、このパラメーターを 0 に設定します。

今回の更新以前は、Red Hat Ceph Storage ダッシュボードが無効であっても、ダッシュボードリスナーが HA Proxy 設定に作成されていました。その結果、Ceph Storage を使用する Red Hat OpenStack Platform のアップグレードに失敗する可能性がありました。

今回の更新によりサービス定義が更新され、Ceph MGR サービスをダッシュボードサービスと区別し、ダッシュボードサービスが有効でなければ設定されないようになりました。これにより、アップグレードが正常に実行されます。

今回の更新以前は、NFS 共有がマウントされていると、Leapp のアップグレードに失敗する場合がありました。特に、Compute サービス (nova) または Image サービス (glance) を実行するノードで NFS マウントが使用されている場合、これらのノードがハングアップしていました。

今回の更新により、Leapp のアップグレード前に、director は /var/lib/nova/instances、/var/lib/glance/images、および GlanceNodeStagingUri パラメーターで定義する Image サービスのステージングエリアをアンマウントするようになりました。

今回の機能拡張により、openstack tripleo container image push コマンドに、ソースレジストリーの認証情報を指定するための新しいオプションが追加されています。新しいオプションは --source-username および --source-password です。

今回の更新以前は、認証を必要とするソースレジストリーからコンテナーイメージをプッシュする際に、認証情報を指定できませんでした。この場合、コンテナーをプッシュする唯一の方法は、イメージを手動でプルし、ローカルシステムからプッシュすることでした。

今回の機能拡張で、Red Hat OpenStack Platform ノードにポリシーベースのルーティングを使用できるようになりました。これにより、os-net-config で複数のルーティングテーブルおよびルーティングルールを設定することができます。

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

今回の更新で、undercloud.conf ファイルの container_images_file パラメーターが必須のオプションになりました。アンダークラウドをインストールする前に、このパラメーターを設定する必要があります。

コンテナーソースに registry.redhat.io を使用する昨今の変更により、コンテナーを取得する際に認証が必要となります。アンダークラウドについては、container_images_file が、インストール実行時に認証情報を指定するための推奨オプションです。この更新以前は、このパラメーターが設定されていないと、コンテナーの取得を試みる際に認証エラーでデプロイメントが失敗していました。

今回の機能拡張により、新たな 2 つのパラメーター NovaPMEMMappings および NovaPMEMNamespaces を使用して、vPMEMEM を管理できるようになりました。

NovaPMEMMappings を使用して、vPMEM と物理 PMEM 名前空間の間のマッピングを反映する nova 設定オプション pmem_namespaces を定義します。

NovaPMEMNamespaces を使用して、vPMEM のバックエンドとして使用する物理 PMEM 名前空間を作成および管理します。

Red Hat OpenStack Platform 16.1 では、ML2/OVS メカニズムドライバーを使用するルーティング対応プロバイダーネットワークがテクノロジープレビューとして提供されます。ルーティング対応プロバイダーネットワークを使用すると、1 つのプロバイダーネットワークを有効にして、複数のレイヤー 2 ネットワーク (ブロードキャストドメイン) またはセグメントに対応することができます。これにより、オペレーターはユーザーに対して 1 つのネットワークだけを提供することができます。これは、エッジ DCN デプロイメントおよびスパイン/リーフ型ルーティング対応データセンターデプロイメントの一般的なネットワーク種別です。

Compute サービス (nova) スケジューラーはセグメントを認識しないため、それぞれのリーフ、ラックセグメント、または DCN エッジサイトを Compute サービスのホストアグリゲートまたはアベイラビリティーゾーンにマッピングする必要があります。デプロイメントで DHCP またはメタデータサービスが必要な場合には、それぞれのエッジサイトまたはセグメントに Compute サービスのアベイラビリティーゾーンを定義する必要もあります。

既知の制限

glance イメージの変換メソッドとして、glance-direct はデフォルトでは有効ではありません。この機能を有効にするには、glance-api.conf ファイルの DEFAULT セクションで、enabled_import_methods を [glaince-direct,web-download] または [glaince-direct] に設定します。

glance-direct インポートメソッドを使用する場合、Image サービス (glance) にはステージングエリアが必要です。glance-api.conf ファイルの DEFAULT セクションで、node_staging_uri オプションを file://<absolute-directory-path> に設定します。このパスは、すべての Image サービス API ノードからアクセス可能な共有ファイルシステム上になければなりません。

Red Hat OpenStack Platform (RHOSP) 13 DCN から RHOSP 16.1 DCN にアップグレードする場合、単一スタックの RHOSP 13 デプロイメントからマルチスタックの RHOSP 16.1 デプロイメントに移行することはできません。RHOSP 13 スタックは、RHOSP 16.1 にアップグレードした後も引き続き Orchestration サービス (heat) の単一スタックとして管理されます。

RHOSP 16.1 にアップグレードした後に、新たな DCN サイトを新規スタックとしてデプロイすることができます。詳細は、RHOSP 16.1 DCN のマルチスタックに関するドキュメントを参照してください。

Red Hat OpenStack Platform 16.1 では、以下のように PowerMax ドライバーが更新されています。

機能の更新:

sg-bridge コンテナーは、sg-bridge RPM を使用して sg-core の AMQP1/unix 間のソケットインターフェイスを提供します。どちらのコンポーネントも Service Telemetry Framework の一部です。

これは、sg-bridge コンポーネントの初期リリースです。

sg-bridge および sg-core コンテナーイメージは、Service Telemetry Framework に collectd メトリックのの新しいデータパスを提供します。

sg-bridge コンポーネントは AMQP1/unix 間のソケット変換を sg-core に提供します。その結果、従来の Smart Gateway コンポーネントに比べて 500% パフォーマンスが向上します。

これは、sg-bridge および sg-core コンテナーイメージコンポーネントの初期リリースです。

OVN は、直接コンピュートノード上で ovn-controller を使用して openflow コントローラーとして DHCP を提供します。ただし、SR-IOV インスタンスは VF/PF を介して直接ネットワークにアタッチされます。したがって、SR-IOV インスタンスは DHCP の応答を受け取ることができません。

回避策: OS::TripleO::Services::NeutronDhcpAgent を OS::TripleO::Services::NeutronDhcpAgent: deployment/neutron/neutron-dhcp-container-puppet.yaml に変更します。

Red Hat OpenStack Platform Load-balancing サービス (octavia) インスタンス (amphora) の keepalived インスタンスが、異常な状態で終了して UDP トラフィックを中断する可能性があります。この問題の原因は、UDP ヘルスモニターのタイムアウト値が短すぎることです。

回避策: 新しいタイムアウト値として 2 秒を超える値を指定します (例: $ openstack loadbalancer healthmonitor set --timeout 3 <heath_monitor_id>)。

詳細は、コマンドラインインターフェイスの参考ドキュメントで loadbalancer healthmonitor を検索してください。

16.0 から 16.1 に更新する際に、Orchestration サービス (heat) の TLS 定義が不完全で、更新に失敗します。

この失敗を防ぐには、パラメーターおよび値を InternalTLSCAFile: '' と設定する必要があります。

パブリック TLS または TLS-Everywhere が使用されている場合、16.0 から 16.1 への更新に失敗する既知の問題があります。

パラメーター InternalTLSCAFile は、オーバークラウドインスタンスの CA 証明書バンドルの場所を定義します。このパラメーターが正しく設定されていないと、アップグレードおよび更新に失敗します。新規デプロイメントでは、heat がこのパラメーターを正しく設定しますが、古い heat テンプレートを使用するデプロイメントをアップグレードする場合、デフォルト値が正しくない可能性があります。

回避策: アンダークラウドがデフォルトのトラストストアの証明書を使用するように、InternalTLSCAFile パラメーターを空の文字列 '' に設定します。

RHOSP 13 から RHOSP 16.1 にアップグレードする際に、既知の問題があります。HostnameFormatDefault の値が %stackname%-compute-%index% から %stackname%-novacompute-%index% に変更されています。このデフォルト値の変更により、サービスエントリーが重複し、さらにライブマイグレーション等の操作に影響を及ぼす可能性があります。

回避策: RHOSP 13 から RHOSP 16.1 にアップグレードする場合、HostnameFormatDefault の値を上書きして以前のデフォルト値を設定し、以前のホスト名の形式が維持されるようにしなければなりません。RHOSP 15 または RHOSP 16.0 からアップグレードする場合は、特別な対応は必要ありません。

RHOSP 16.1 では、tripleo-ansible-inventory の出力形式が変更されました。これにより、generate-inventory ステップで失敗します。

回避策: インベントリーを手動で作成します。

アンダークラウドが外部の (パブリック) エンドポイントに接続して初期リソースおよびプロジェクトを作成する際に、デプロイメント時に heat パラメーター InternalTLSCAFile が使用されるという既知の問題があります。内部インターフェイスとパブリックインターフェイスの証明書が異なる認証局 (CA) からの証明書である場合、デプロイメントに失敗します。アンダークラウドが keystone パブリックインターフェイスへの接続に失敗するか、内部インターフェイスが不適切な設定を受け取ります。

IPA サーバーは内部インターフェイスを提供するが、パブリックインターフェイスがオペレーターの提供する証明書を持つ場合に、このシナリオは TLS Everywhere が設定されたデプロイメントに影響を及ぼします。また、既存のパブリック証明書が設定されたデプロイメントが TLS Everywhere の再デプロイおよび設定を試みるブラウンフィールドデプロイメントも阻害されます。

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

以下の条件により、Block Storage サービス (cinder) には既知の問題があります。

Object Storage サービス (swift) には既知の問題があります。事前にデプロイされたノードを使用する場合、/var/log/containers/stdouts/swift_rsync.log に以下のエラーメッセージが記録される場合があります。

failed to create pid file /var/run/rsyncd.pid: File exists

回避策: 事前にデプロイされているすべてのコントローラーノードで以下のコマンドを入力します。

for d in $(podman inspect swift_rsync | jq '.[].GraphDriver.Data.UpperDir') /var/lib/config-data/puppet-generated/swift; do sed -i -e '/pid file/d' $d/etc/rsyncd.conf; done

python3-tripleoclient を更新またはアップグレードすると、Ansible は更新またはアップグレードを受け取らず、Ansible または ceph-ansible のタスクが失敗します。

更新またはアップグレードする際は、Playbook タスクが正常に実行されるように Ansible も更新を受け取るようにしてください。

ovn-controller が生成するパケットに対する OVN フィルターには既知の問題があります。OVN の ACL 処理を受信するルーター広告は、このトラフィックを許可する明示的な ACL ルールがない場合にドロップされます。

回避策: 以下のコマンドを入力してセキュリティールールを作成します。

openstack security group rule create --ethertype IPv6 --protocol icmp --icmp-type 134 <SECURITY_GROUP>

OVS OFFLOAD デプロイメント時の VF LAG モード、SRIOV Switchdev モードの Mellanox ConnectX-5 アダプターカードには、いくつか既知の制限事項があります。

Mellanox ConnectX-5 アダプターカードを OVS OFFLOAD デプロイメント時の Virtual Function (VF) リンクアグリゲーショングループ (LAG) 設定、SRIOV Switchdev モードで使用した場合、以下に示す既知の問題および制限事項に当面する可能性があります。

dashboard_protocol パラメーターがヒートテンプレートから不適切に削除されたため、現在 Ceph Dashboard は TLS Everywhere のフレームワークでは機能しません。その結果、HAproxy の起動時にバックエンドが表示されません。

一時的なソリューションとしては、Dashboard_protocol パラメーターが含まれる新しい環境ファイルを作成し、-e オプションを使用してその環境ファイルをオーバークラウドデプロイメントに追加します。

parameter_defaults:
  CephAnsibleExtraConfig:
    dashboard_protocol: 'https'

このソリューションにより、ceph-ansible のバグが生じます。詳細は、BZ#1860815 を参照してください。

強制的なシャットダウン後に、Ceph コンテナーがシステムのリブート時に自動的に起動しないという既知の問題があります。

回避策: podman rm コマンドを使用して、古いコンテナー ID を手動で削除します。詳細は、https://bugzilla.redhat.com/show_bug.cgi?id=1858865#c2 を参照してください。

ゲスト仮想マシン内で realtime-virtual-host tuned プロファイルを有効にすると、スループットが低下し、予測不可能なパフォーマンスを示すという既知の問題があります。ovs-dpdk PMD は、ハウスキーピング用の CPU に不適切に固定されます。

回避策: ゲスト仮想マシン内で cpu-partitioning tuned プロファイルを使用し、tuned.conf ファイルを更新するデプロイメント後のスクリプトを作成し、ノードをリブートしてください。

ps_blacklist=ksoftirqd.*;rcuc.*;rcub.*;ktimersoftd.*;.*pmd.*;.*PMD.*;^DPDK;.*qemu-kvm.*

Red Hat OpenStack Platform(RHOSP)13 から RHOSP 16.1 への Fast Forward Upgrade(FFU) 中に、hugepages パラメーターの値などの TRIPLEO_HEAT_TEMPLATE_KERNEL_ARGS を変更すると、カーネル引数のエントリーが重複しているため、アップグレードが失敗します。

FFU 中にカーネル引数を変更することは回避してください。

回避策: RHOSP 16.1 では、通常 /usr/share/ansible/roles/tripleo-kernel/tasks/kernelargs.yml で、カーネル引数を手動で変更することができます。

director のこの拡張機能により、OpenStack のアップグレード準備を行うために、オーバークラウドノードに Leapp ユーティリティーが自動的にインストールされます。https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/16.1/html-single/release_notes/index 今回の機能拡張には、2 つの新たな Heat パラメーター (LeappRepoInitCommand および LeappInitCommand) が含まれます。また、以下のデフォルトのリポジトリーがある場合は、UpgradeLeappCommandOptions の値を渡す必要はありません。

--enablerepo rhel-8-for-x86_64-baseos-eus-rpms --enablerepo rhel-8-for-x86_64-appstream-eus-rpms --enablerepo rhel-8-for-x86_64-highavailability-eus-rpm1866372s --enablerepo advanced-virt-for-rhel-8-x86_64-rpms --enablerepo ansible-2.9-for-rhel-8-x86_64-rpms --enablerepo fast-datapath-for-rhel-8-x86_64-rpms

今回の更新により、ML2/OVS から ML2/OVN へのインプレースマイグレーション中 generate-inventory ステップが失敗する原因となっていたバグが修正されました。

Red Hat OpenStack Platform 16.1.0 (GA リリース) では、ML2/OVS から ML2/OVN への移行はサポートされていませんでした。Red Hat OpenStack Platform 16.1.1 の時点では、NFV 以外のデプロイメントのインプレースアップグレードがサポートされます。ただし、ML2/OVS から ML2/OVN への移行[1] で説明するさまざまな例外、制限、および要件が適用されます。

[1] ML2/OVS から ML2/OVN への移行

今回の更新以前は、Red Hat Ceph Storage Dashboard が無効であっても、Dashboard リスナーが HA Proxy 設定に作成されていました。その結果、Ceph を使用する Red Hat OpenStack Platform (RHOSP) のアップグレードに失敗する可能性がありました。

今回の更新によりサービス定義が更新され、Ceph MGR サービスを Dashboard サービスと区別し、Dashboard サービスが有効でなければ設定されないようになりました。これにより、アップグレードが正常に実行されます。

オーバークラウドのデプロイメントステップには、tripleo-bootstrap および tripleo-ssh-known-hosts ロールを common_roles としてタグ付けする古い Ansible 構文が含まれていました。この古い構文により、Ansible が common_roles タグを使用しない場合に common_roles にタグ付けされたタスクが実行されました。この構文が原因で、13 から 16.1 への system_upgrade プロセス中にエラーが発生していました。

今回の更新により、新しい構文を使用して tripleo-bootstrap および tripleo-ssh-known-hosts ロールを common_roles としてタグ付けできるようになりました。13 から 16.1 の system_upgrade プロセス中にエラーが発生しなくなり、回避策として --playbook upgrade_steps_playbook.yaml オプションを system_upgrade プロセスに追加する必要がなくなりました。

今回の更新以前は、Leapp のアップグレードを実行する前に、director は Red Hat Ceph Storage OSD に noout フラグを設定していませんでした。その結果、アップグレード後に OSD がバランスをとり直すのに追加の時間が必要でした。

今回の更新により、ディレクターは Leapp のアップグレード前に noout フラグを設定するようになり、これによりアップグレードプロセスが迅速化されました。また、director は Leapp のアップグレード後に noout フラグの設定を解除します。

今回の更新以前は、NFS 共有がマウントされていると、Leapp のアップグレードに失敗する場合がありました。特に、Compute サービス (nova) または Image サービス (glance) を実行するノードで NFS マウントが使用されている場合、これらのノードがハングアップしていました。

今回の更新により、Leapp のアップグレード前に、director は /var/lib/nova/instances、/var/lib/glance/images、および GlanceNodeStagingUri パラメーターで定義する Image サービスのステージングエリアをアンマウントするようになりました。

今回の更新により、leapp によるアップグレード時にコンピュートノードが予期せぬ挙動を示す原因となっていた GRUB パラメーターの命名規則が修正されました。

従来は、GRUB パラメーターに廃止された TRIPELO 接頭辞が存在することが原因で問題が生じていました。

GRUB の /etc/default/grub ファイルの tripleo kernel 引数パラメーターが更新され、これにより leapp が正しくアップグレードできるようになりました。そのために、roles_data.yaml ファイルのすべてのロールに追加された新規サービスの OS::TripleO::Services::BootParams サービスに upgrade_tasks を追加しました。

今回の更新で、Leapp によるアップグレード時にベアメタルノードが応答しなくなる問題が修正されました。

以前のリリースでは、Leapp は移行時に SR-IOV Virtual Function (VF) 等の一時的なインターフェイスを処理しませんでした。そのため、Leapp はアップグレード時に VF インターフェイスを検出せず、ノードがリカバリー不能な状態になっていました。

サービス OS::TripleO::Services::NeutronSriovAgent は、すべての VF を削除するように Physical Function (PF) を設定し、アップグレードの前にワークロードを移行するようになりました。Leapp によるアップグレードが正常に完了したら、--no-activate フラグを設定して os-net-config を再度実行し、VF を確立し直します。

本リリースでは、ML2/OVN デプロイメントで SR-IOV とネイティブの OVN DHCP の組み合わせを使用することができます。ML2/OVN デプロイメントの SR-IOV は、Networking サービス (neutron) の DHCP エージェントを必要としなくなりました。

SR-IOV NIC をサポートするハイパーバイザー上で仮想マシンがブートすると、コントローラーノードまたはネットワークノードの OVN コントローラーは、仮想マシンからの DHCP、内部 DNS、および IPv6 ルーター要請の要求に応答することができます。

この機能は、RHOSP 16.1.0 ではテクノロジープレビューとして提供されていました。今回のリリースで、サポート対象の機能になりました。

本リリースでは、機能に以下の制限が適用されます。

Red Hat OpenStack Platform 16.1 の最初のメンテナンスリリースでは、ML2/OVS および SR-IOV メカニズムドライバーを使用するルーティング対応プロバイダーネットワークがサポートされます。

ルーティング対応プロバイダーネットワークを使用すると、1 つのプロバイダーネットワークを有効にして、複数のレイヤー 2 ネットワーク (ブロードキャストドメイン) またはセグメントに対応することができます。これにより、オペレーターはユーザーに対して 1 つのネットワークだけを提供することができます。これは、エッジ DCN デプロイメントおよびスパイン/リーフ型ルーティング対応データセンターデプロイメントの一般的なネットワーク種別です。

詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/16.1/html-single/networking_guide/index#deploy-routed-prov-networks_rhosp-network を参照してください。

現在、Red Hat OpenStack Platform が tripleo-ipa を使用して TLS-e を設定してデプロイされている場合、コンピュートノードをスケールダウンしたり削除したりすることはできません。これは、従来ローカルホストとしてアンダークラウドに委譲されていたクリーンアップロールが、mistral コンテナーから呼び出されるようになったためです。

詳細は、In an environment with TLSe setup with tripleo-ipa, Compute node replacement procedure fails to remove compute node を参照してください。

Leapp の問題により、Red Hat OpenStack Platform (RHOSP) 13 から RHOSP 16.1 への Fast Forward Upgrade に失敗します。

RHEL 7 から RHEL 8 への Leapp アップグレードにより、古い RHOSP パッケージがすべて削除され、オペレーティングシステムのアップグレードおよびリブートが実行されます。Leapp は overcloud upgrade run 段階で os-net-config パッケージをインストールするため、リブート後に sriov_config サービスが Virtual Function (VF) および switchdev モードを設定する際に os-net-config-sriov 実行ファイルを利用することができません。その結果、VF は設定されず、switchdev モードは Physical Function (PF) インターフェイスに適用されません。

回避策としては、VF を手動で作成して switchdev モードを VF インターフェイスに適用し、VF インターフェイスを再起動する方法があります。

この更新には、完全修飾ドメイン名 (FQDN) に関連する以下のバグ修正パッチが含まれています。

タイムアウト値が不適切な場合、オーバークラウドのデプロイメントが 4 時間後に失敗する可能性があります。タイムアウトによるこれらの失敗を防ぐには、以下に示すアンダークラウドおよびオーバークラウドのタイムアウトパラメーターを設定します。

今回の更新以前は、Block Storage サービス (cinder) は、ボリューム種別を指定する代替方法を無視して volume create 要求のデフォルトボリューム種別を割り当てていました。

今回の更新により、Block Storage サービスは予想どおりに機能するようになりました。

今回の更新で、RHOSP 16 で Brocade FCZM ドライバーを実行できるようになりました。

Brocade FCZM のベンダーは Python 3 向けにドライバーを更新しない決定を下し、OpenStack の Train リリース以降ドライバーのサポートを終了しました [1]。Red Hat OpenStack (RHOSP) 16 は Python 3.6 を使用します。

アップストリームの Cinder コミュニティーはベストエフォートベースで Brocade FCZM ドライバーの維持を引き継ぎ、Python 3 環境 (したがって RHOSP 16 ) での Brocade FCZM の動作を妨げていたバグが修正されています。

[1] https://docs.broadcom.com/doc/12397527

今回の更新で、特定のケースでスタック更新の速度が向上しています。

以前のリリースでは、Ansible --limit オプションが ceph-ansible に渡されていない場合、スタック更新のパフォーマンスが低下していました。--limit 引数が使用されていても、ceph-ansible はスタックの更新時にノード上でべき等性を持つ更新を行う場合がありました。

director は Ansible --limit オプションをインターセプトし、それを ceph-ansible 実行可能ファイルに渡すようになりました。openstack overclouddeploy で始まるコマンドに渡された --limit オプションは、ceph-ansible 実行可能ファイルに渡され、スタックの更新に必要な時間を短縮します。

今回の更新以前は、RHOSP 13 から RHOSP 16.1 へのアップグレードフレームワーク (FFU) 時に leapp アップグレードが正常に実行されるためには、Red Hat Enterprise Linux のアップグレードが生じているノードの ssh 設定ファイル (/etc/ssh/sshd_config) に PermitRootLogin フィールドが定義されている必要がありました。

今回の更新により、Orchestration サービス (heat) では PermitRootLogin フィールドで /etc/ssh/sshd_config を変更する必要がなくなりました。

今回の更新で、VxFlexOS cinder バックエンドでボリュームの接続に失敗する原因となっていた問題が解決されました。

以前のリリースでは、VxFlexOS バックエンドの cinder ドライバーにボリュームに接続するのに必要なすべての情報が含まれないため、VxFlexOS cinder バックエンドでボリュームを接続する試みが失敗していました。

ボリュームに接続するのに必要なすべての情報が含まれるように、VxFlexOS cinder ドライバーが更新されました。接続が正常に機能するようになりました。

今回の更新で、VxFlex ボリューム切断の試みが失敗する原因となっていた非互換性が解消されました。

昨今の VxFlex cinder ボリュームの認証方法に関する変更は、既存のボリューム接続への後方互換性を持ちませんでした。認証方法の変更前に VxFlex ボリュームを接続した場合、ボリューム切断の試みが失敗していました。

これで、切断に失敗しなくなりました。

今回の更新で、lsscsi を使用して [H:C:T:L] 値を取得するように get_device_info が変更され、これにより 255 を超える論理ユニット番号 (LUN) およびホスト論理ユニット (HLU) の ID 値に対応できるようになりました。

以前のリリースでは、get_device_info は sg_scan を使用してこれらの値を取得し、最大で 255 という制限がありました。

get_device_info を使用して、2 つのデバイス種別を取得することができます。

今回の更新により、分散コンピュートノード (DCN) の Compute サービスが glance サービスにアクセスできない原因となっていたバグが修正されました。

以前のリリースでは、内部 Transport Layer Security (TLS) を使用してデプロイした場合でも、分散コンピュートノードは IP アドレスを指定する glance エンドポイントの URI で設定されていました。TLS では完全修飾ドメイン名 (FQDN) を指定するエンドポイントの URI が必要なため、Compute サービスは glance サービスにアクセスできませんでした。

内部 TLS を使用してデプロイした場合、DCN サービスは FQDN を指定する glance エンドポイントの URI で設定され、DCN の Compute サービスが glance サービスにアクセスできるようになりました。

この更新には、完全修飾ドメイン名 (FQDN) に関連する以下のバグ修正パッチが含まれています。

タイムアウト値が不適切な場合、オーバークラウドのデプロイメントが 4 時間後に失敗する可能性があります。タイムアウトによるこれらの失敗を防ぐには、以下に示すアンダークラウドおよびオーバークラウドのタイムアウトパラメーターを設定します。

今回の更新以前は、Block Storage サービス (cinder) は、ボリューム種別を指定する代替方法を無視して volume create 要求のデフォルトボリューム種別を割り当てていました。

今回の更新により、Block Storage サービスは予想どおりに機能するようになりました。

今回の更新で、RHOSP 16 で Brocade FCZM ドライバーを実行できるようになりました。

Brocade FCZM のベンダーは Python 3 向けにドライバーを更新しない決定を下し、OpenStack の Train リリース以降ドライバーのサポートを終了しました [1]。Red Hat OpenStack (RHOSP) 16 は Python 3.6 を使用します。

アップストリームの Cinder コミュニティーはベストエフォートベースで Brocade FCZM ドライバーの維持を引き継ぎ、Python 3 環境 (したがって RHOSP 16 ) での Brocade FCZM の動作を妨げていたバグが修正されています。

[1] https://docs.broadcom.com/doc/12397527

今回の更新で、特定のケースでスタック更新の速度が向上しています。

以前のリリースでは、Ansible --limit オプションが ceph-ansible に渡されていない場合、スタック更新のパフォーマンスが低下していました。--limit 引数が使用されていても、ceph-ansible はスタックの更新時にノード上でべき等性を持つ更新を行う場合がありました。

director は Ansible --limit オプションをインターセプトし、それを ceph-ansible 実行可能ファイルに渡すようになりました。openstack overclouddeploy で始まるコマンドに渡された --limit オプションは、ceph-ansible 実行可能ファイルに渡され、スタックの更新に必要な時間を短縮します。

今回の更新以前は、RHOSP 13 から RHOSP 16.1 へのアップグレードフレームワーク (FFU) 時に leapp アップグレードが正常に実行されるためには、Red Hat Enterprise Linux のアップグレードが生じているノードの ssh 設定ファイル (/etc/ssh/sshd_config) に PermitRootLogin フィールドが定義されている必要がありました。

今回の更新により、Orchestration サービス (heat) では PermitRootLogin フィールドで /etc/ssh/sshd_config を変更する必要がなくなりました。

今回の更新で、VxFlexOS cinder バックエンドでボリュームの接続に失敗する原因となっていた問題が解決されました。

以前のリリースでは、VxFlexOS バックエンドの cinder ドライバーにボリュームに接続するのに必要なすべての情報が含まれないため、VxFlexOS cinder バックエンドでボリュームを接続する試みが失敗していました。

ボリュームに接続するのに必要なすべての情報が含まれるように、VxFlexOS cinder ドライバーが更新されました。接続が正常に機能するようになりました。

今回の更新で、VxFlex ボリューム切断の試みが失敗する原因となっていた非互換性が解消されました。

昨今の VxFlex cinder ボリュームの認証方法に関する変更は、既存のボリューム接続への後方互換性を持ちませんでした。認証方法の変更前に VxFlex ボリュームを接続した場合、ボリューム切断の試みが失敗していました。

これで、切断に失敗しなくなりました。

今回の更新で、lsscsi を使用して [H:C:T:L] 値を取得するように get_device_info が変更され、これにより 255 を超える論理ユニット番号 (LUN) およびホスト論理ユニット (HLU) の ID 値に対応できるようになりました。

以前のリリースでは、get_device_info は sg_scan を使用してこれらの値を取得し、最大で 255 という制限がありました。

get_device_info を使用して、2 つのデバイス種別を取得することができます。

今回の更新により、分散コンピュートノード (DCN) の Compute サービスが glance サービスにアクセスできない原因となっていたバグが修正されました。

以前のリリースでは、内部 Transport Layer Security (TLS) を使用してデプロイした場合でも、分散コンピュートノードは IP アドレスを指定する glance エンドポイントの URI で設定されていました。TLS では完全修飾ドメイン名 (FQDN) を指定するエンドポイントの URI が必要なため、Compute サービスは glance サービスにアクセスできませんでした。

内部 TLS を使用してデプロイした場合、DCN サービスは FQDN を指定する glance エンドポイントの URI で設定され、DCN の Compute サービスが glance サービスにアクセスできるようになりました。

今回の更新で、Key Manager サービス (barbican) が管理するキーで暗号化されたイメージがサポートされるようになりました。

保存データを暗号化された状態で維持する必要がある安全なワークフロー用に、入念に準備した暗号化済みイメージを Image サービス (glance) にアップロードし、Block Storage サービス (cinder) で使用することができます。

今回の更新により、分散コンピュートノード (DCN) 上で暗号化されたボリュームおよびイメージがサポートされるようになりました。

DCN ノードは、中央のコントロールプレーンで実行されている Key Manager サービス (barbican) にアクセスできるようになりました。

以下に例を示します。

$ openstack overcloud roles generate DistributedComputeHCI DistributedComputeHCIScaleOut -o ~/dcn0/roles_data.yaml

ロールデータファイルへの適切なパスを使用します。

RHOSP 16.1.2 では、AMD EPYC 2 (Rome) プラットフォームの UEFI 設定 NPS (Numa Per Socket) を 1 に指定するテクノロジープレビュー機能が追加されています。

NPS のその他の値 (2 または 4) は、OpenStack を使用せずベアメタル上で、プラットフォームのピークパフォーマンスに到達するために DPDK ベンチマークで使用されます。

Red Hat では、OpenStack を使用した NPS=2 または NPS=4 との運用上のトレードオフ評価を継続しています。この設定では、ソケットごとに複数の Numa ノードを公開します。

Red Hat OpenStack Platform 16.1.2 では、AMD EPYC 2 (Rome) プラットフォームの UEFI 設定 NPS (Numa Per Socket) を 1 に指定するテクノロジープレビュー機能が追加されています。

NPS のその他の値 (2 または 4) は、OpenStack を使用せずベアメタル上で、プラットフォームのピークパフォーマンスに到達するために DPDK ベンチマークで使用されます。

Red Hat では、OpenStack を使用した NPS=2 または NPS=4 との運用上のトレードオフ評価を継続しています。この設定では、ソケットごとに複数の Numa ノードを公開します。

Red Hat OpenStack Platform 16.1.2 では、同じハイパーバイザー上で OVN および OVS-DPDK が SR-IOV と共存するテクノロジープレビュー機能が追加されています。

関連する問題については、以下のバグレポートを参照してください。

Bug 1575512 および

Bug 1575512

Red Hat OpenStack Platform 16.1.2 では、OVN と OVS TC Flower ベースのオフロードの組み合わせがテクノロジープレビュー機能として追加されています。

通常のシャーシ間の通信では、OVN は VXLAN をサポートしない点に注意してください。そのため、VXLAN と OVN を使用したハードウェアオフロードの組み合わせはサポートされません。Bug 1881704 を参照してください。

Red Hat OpenStack Platform 16.1 では、以下のように PowerMax ドライバーが更新されています。

機能の更新:

今回の更新では、Red Hat OpenStack Platform (RHOSP) Orchestration サービス (heat) を使用して、Block Storage サービス (cinder) 用に、任意のストレージプロトコルの組み合わせで複数の Dell EMC XtremIO バックエンドをデプロイすることができます。

新しい heat パラメーター CinderXtremioStorageProtocol により、ファイバーチャネル (FC) または iSCSI ストレージプロトコルのいずれかを選択することができるようになりました。

新しい heat テンプレートにより、複数の XtremIO バックエンドをデプロイすることができます。

以前のリリースでは、RHOSP director は Block Storage サービス用に 1 つの iSCSI バックエンドしかサポートしていませんでした (従来の iSCSI だけに対応した heat テンプレートは、RHOSP の今後のリリースで非推奨になります)。

PowerMax 設定オプションは、Red Hat OpenStack Platform 10 (newton) 以降変更されています。今回の更新により最新の PowerMax 設定オプションが追加され、iSCSI プロトコルと FC プロトコルの両方がサポートされるようになりました。

CinderPowermaxBackend パラメーターも、複数のバックエンドをサポートします。CinderPowermaxBackendName はバックエンドのリストをサポートし、新しい CinderPowermaxMultiConfig パラメーターを使用して各バックエンドのパラメーター値を指定することができます。構文の例は、environments/cinder-droidmc-powermax-config.yaml を参照してください。

ML2/OVN ルーターへの UDP ジャンボフレームの送信は、まだ利用することのできないカーネルリリースに依存します。

外部ネットワークの最大伝送単位を超える UDP ジャンボフレームを受信した場合、ML2/OVN ルーターは ICMP の fragmentation needed パケットを送信元の仮想マシンに返すことができます。これにより、送信元アプリケーションはペイロードをより小さなパケットに分割することができます。パケットサイズを判断するためには、South-North パスの MTU 限度を検出できる必要があります。

South-North パスの MTU 検出には kernel-4.18.0-193.20.1.el8_2 が必要です。これは、今後のリリースで利用可能になる予定です。カーネルバージョンの可用性を把握するには、Bug 1860169 を参照してください。

Load-balancing サービスインスタンス (amphora) のログオフロードを有効にすると、管理ログとテナントログの両方が同じファイル (octavia-amphora.log) に書き込まれます。これは、Orchestration サービス (heat) のパラメーター OctaviaTenantLogFacility のデフォルト値が誤っていること原因で発生する既知の問題です。回避策として、以下の手順を実施してください。

カスタムの環境ファイルで OctaviaTenantLogFacility をゼロ (0) に設定し、openstack overcloud deploy コマンドを実行します。

parameter_defaults:
    OctaviaLogOffload: true
    OctaviaTenantLogFacility: 0
    ...

詳しい情報は、オーバークラウド環境の変更 を参照してください。

既知の問題が原因で、Ceph OSD の FileStore から BlueStore への移行に失敗します。Red Hat Ceph Storage 3 と共に Red Hat OpenStack Platform 13 をデプロイする際に osd_objectstore パラメーターを明示的に設定しない場合、一切 OSD を変換せずに移行が終了し、OSD がすでに BlueStore を使用しているという誤った報告がなされます。この既知の問題に関する詳細は、Bug 1875777 を参照してください。

回避策として、以下の手順を実施してください。

Red Hat OpenStack Platform Load-balancing サービス (octavia) インスタンス (amphora) の keepalived インスタンスが、異常な状態で終了して UDP トラフィックを中断する可能性があります。この問題の原因は、UDP ヘルスモニターのタイムアウト値が短すぎることです。

回避策: 新しいタイムアウト値として 2 秒を超える値を指定します (例: $ openstack loadbalancer healthmonitor set --timeout 3 <heath_monitor_id>)。

詳細は、コマンドラインインターフェイスの参考ドキュメントで loadbalancer healthmonitor を検索してください。

ゲスト仮想マシン内で realtime-virtual-host tuned プロファイルを有効にすると、スループットが低下し、予測不可能なパフォーマンスを示します。ovs-dpdk PMD は、ハウスキーピング用の CPU に不適切に固定されます。

回避策として、ゲスト仮想マシン内で cpu-partitioning tuned プロファイルを使用し、tuned.conf ファイルを更新するデプロイメント後のスクリプトを作成し、ノードをリブートしてください。

ps_blacklist=ksoftirqd.*;rcuc.*;rcub.*;ktimersoftd.*;.*pmd.*;.*PMD.*;^DPDK;.*qemu-kvm.*

現在、Red Hat OpenStack Platform が tripleo-ipa を使用して TLS Everywhere を設定してデプロイされている場合、コンピュートノードをスケールダウンしたり削除したりすることはできません。これは、従来ローカルホストとしてアンダークラウドに委譲されていたクリーンアップロールが、Workflow サービス (mistral) コンテナーから呼び出されるようになったためです。

詳細は、In an environment with TLSe setup with tripleo-ipa, Compute node replacement procedure fails to remove compute node を参照してください。

今回の更新で、階層化ポリシーに対応したボリューム作成がサポートされるようになりました。サポートされる値は以下の 4 つです。

今回の機能拡張により、Dell EMC PowerStore 用の新しいドライバーが追加され、Block Storage サービスのバックエンドサーバーがサポートされるようになりました。新しいドライバーは FC プロトコルおよび iSCSI プロトコルをサポートし、以下の機能を備えています。

現在、少なくとも 1 つのデバイスが LVMFilterAllowlist パラメーターに設定されていない限り、LVM フィルターは設定されません。

回避策: LVMFilterAllowdisk パラメーターに少なくとも 1 つのデバイス (ルートディスクなど) を設定します。LVM フィルターは /etc/lvm/lvm.conf に設定されます。

Object Storage サービス (swift) には既知の問題があります。事前にデプロイされたノードを使用する場合、/var/log/containers/stdouts/swift_rsync.log に以下のエラーメッセージが記録される場合があります。

failed to create pid file /var/run/rsyncd.pid: File exists

回避策: 事前にデプロイされているすべてのコントローラーノードで以下のコマンドを入力します。

for d in $(podman inspect swift_rsync | jq '.[].GraphDriver.Data.UpperDir') /var/lib/config-data/puppet-generated/swift; do sed -i -e '/pid file/d' $d/etc/rsyncd.conf; done

dashboard_protocol パラメーターがヒートテンプレートから不適切に削除されたため、現在 Ceph Dashboard は TLS Everywhere のフレームワークでは機能しません。その結果、HAproxy の起動時にバックエンドが表示されません。

一時的なソリューションとしては、Dashboard_protocol パラメーターが含まれる新しい環境ファイルを作成し、-e オプションを使用してその環境ファイルをオーバークラウドデプロイメントに追加します。

parameter_defaults:
  CephAnsibleExtraConfig:
    dashboard_protocol: 'https'

このソリューションにより、ceph-ansible のバグが生じます。詳細は、BZ#1860815 を参照してください。

現在、OSP13 の Puppet モジュール kmod に加えた変更により、systemd-modules-load.service のモジュール設定に誤りが生じています。これは OSP13 の問題ではありませんが、OSP16.1 での Fast Forward Upgrade のデプロイメント時にエラーが生じます。

回避策: 以下のコマンドを入力します。

rm -f /etc/modules-load.d/nf_conntrack_proto_sctp.conf

オーバークラウドのコントローラーノードを置き換えると、ノード間で swift リングの一貫性が失われる可能性があります。これにより、Object Storage サービスの可用性が低下します。

回避策: SSH を使用してそれまで存在していたコントローラーノードにログインして更新されたリングをデプロイし、Object Storage コンテナーを再起動します。

今回の更新以前は、ユーザーが標準の tag_from_label: "{version}-{release}"ではなくカスタムのタグ (例:tag: "latest"または tag: "16.1") を使用するように ContainerImagePrepare パラメーターを設定した場合、コンテナーは最新のコンテナーイメージに更新されませんでした。

今回の更新により、ユーザーがデプロイメントアクション (更新を含む) を実行すると、コンテナーイメージが必ずフェッチされるようになりました。イメージ ID を実行中のコンテナーに対して確認し、最新のイメージが使用されるようにコンテナーを再ビルドする必要があるかどうかを判断します。デプロイメントアクション時に必ずコンテナーがリフレッシュされ、更新された場合には再起動されるようになりました。

今回の更新以前は、エッジサイトにデプロイされた Image (glance) サービスは、中央サイトのコントロールプレーンで実行されている Key Manager (barbican) サービスにアクセスするように設定されませんでした。そのため、エッジサイト上で実行中の Image サービスは、Key Manager サービスに保存された暗号鍵にアクセスすることができませんでした。

今回の更新により、エッジサイト上で実行中の Image サービスは、Key Manager サービスに保存された暗号鍵にアクセスするように設定されるようになりました。

今回の更新以前は、TLS everywhere 環境での Red Hat OpenStack Platform 13 から 16.1 へのインプレースアップグレードにおいて、novajoin コンテナーに誤った rabbitmq パスワードが使用されていました。これにより、アンダークラウドの novajoin コンテナーが正しく機能せず、すべてのオーバークラウドノードでのアップグレードの実行が以下のエラーと共に失敗していました。

2020-11-24 20:01:31.569 7 ERROR join   File "/usr/lib/python3.6/site-packages/amqp/connection.py", line 639, in _on_close
2020-11-24 20:01:31.569 7 ERROR join     (class_id, method_id), ConnectionError)
2020-11-24 20:01:31.569 7 ERROR join amqp.exceptions.AccessRefused: (0, 0): (403) ACCESS_REFUSED - Login was refused using authentication mechanism AMQPLAIN. For detail see the broker logfile.

今回の更新により、TLS everywhere 環境での RHOSP 13 から 16.1 へのアップグレードで正しい rabbitmq パスワードが使用され、アップグレードのフレームワークを正常に完了できるようになりました。

今回の更新以前は、ローカル一時ストレージを持ち UseTLSTransportForNbd が False に設定された TLS everywhere 環境をアップグレードする場合、ライブマイグレーションに失敗していました。これは、UseTLSTransportForNbd 設定のデフォルト値が RHOSP 13 では False であったのが RHOSP 16.x では True に変更され、これにより QEMU プロセスコンテナーに正しい証明書が含まれなかったためです。

今回の更新により、director は global_config_settings で以前のデプロイメント環境の設定を確認し、それを使用してアップグレードで UseTLSTransportForNbd が以前のデプロイメントと同じ状態を維持するようになりました。設定ファイルに global_config_settings が存在する場合、director は use_tls_for_nbd キーの設定を確認します。global_config_settings が存在しない場合、director は hieradata キー nova::compute::libvirt::qemu::nbd_tls を評価します。アップグレードしたデプロイメントの UseTLSTransportForNbd を以前のデプロイメントと同じ状態に維持することで、ライブマイグレーションが機能するようになりました。

今回の更新以前は、OSP 16.1.3 における python-network-runner の 0.1.7 から 0.2.2 へのリベースにより、Ansible を使用する ML2 ネットワークが機能しなくなりました。

今回の更新で、python-networking-ansible が 0.1.7 に戻され、Ansible ネットワークが機能する状態に戻りました。

詳細は、ML2 networking-ansible を参照してください。

今回の更新以前は、ボリュームがイメージ、スナップショット、または他のボリューム等の別のソースから作成された場合でも、Block Storage (cinder) サービスは、新たに規作したボリュームに必ずデフォルトのボリューム種別を割り当てていました。これにより、別のソースから作成されたボリュームのボリューム種別が、ソースのボリューム種別と異なっていました。

今回の更新により、デフォルトのボリューム種別を割り当てるべきかどうかをソースのボリューム種別に基づいて判別した後にのみ、デフォルトのボリューム種別が割り当てられるようになりました。別のソースから作成されたボリュームのボリューム種別が、ソースのボリューム種別と一致するようになりました。

今回の機能拡張により、インスタンスに永続メモリーを提供するように NVDIMM コンピュートノードを設定できるようになりました。この機能を使用して、NVDIMM ハードウェアを持つコンピュートノードで PMEM 名前空間を作成および設定することで、インスタンスは PMEM を仮想 PMEM (vPMEM) として利用することができます。これにより、インスタンスのシャットダウン後にコンテンツを維持する必要がある場合、クラウドユーザーは vPMEM を要求するインスタンスを作成することができます。

注記: daxio パッケージは x86_64 アーキテクチャーでのみ利用可能であるため、この機能は x86_64 コンピュートノードでのみサポートされます。

今回の機能拡張により、新たな 2 つのパラメーター NovaPMEMMappings および NovaPMEMNamespaces を使用して、vPMEMEM を管理できるようになりました。

今回の機能拡張により、新規デプロイメントにおいて Network Functions Virtualization infrastructure (NFVi) での Open Virtual Network (OVN) の使用がサポートされるようになりました。これには、以下の機能のサポートが含まれます。

注記: NFV のデプロイメントでは、ML2/OVS から ML2/OVN への移行はまだサポートされていません。

今回の機能拡張により、ML2/OVN メカニズムドライバーと vlan および geneve ネットワークタイプドライバーの組み合わせにおいて、vlan の透過性がサポートされるようになりました。

vlan の透過性により、Networking (neutron) サービスのネットワーク上のインスタンスを使用して vlan タグを管理することができます。他のネットワークに影響を与えずに、インスタンスに vlan インターフェイスを作成し、任意の vlan タグを使用することができます。Networking サービスは、これらの vlan タグを認識しません。

備考:

virt-admin ツールが利用できるようになり、これを使用して RHOSP のバグを報告するログを取得することができます。ログにはコンピュートノード上の libvirt と QEMU 間の通信が記録されるので、このツールは、libvirt および QEMU に関するすべての問題のトラブルシューティングに役立ちます。virt-admin を使用すると、libvirt および QEMU のデバッグ用ログフィルターを動的に設定することができます。この場合、nova_libvirt コンテナーを再起動する必要はありません。

コンピュートノードで libvirt および QEMU のログフィルターを有効にするには、以下の手順を実施します。

現在、サブスクライブした環境に正しい DNF モジュールストリームが設定されるようにするメカニズムに既知の問題があります。Advanced Virtualization リポジトリーは、Ceph ノードが使用するサブスクリプションで常に利用可能な訳ではありません。そのため、virt:8.2 を有効にしようとすると、Ceph ノードのアップグレードまたは更新に失敗します。この既知の問題に関する詳細は、Bug 1923887 を参照してください。

回避策:

アップグレードまたは更新用環境ファイルの DnfStreams パラメーターをオーバーライドし、Ceph のアップグレードが失敗するのを回避します。

parameter_defaults:
  ...
  DnfStreams: [{'module':'container-tools', 'stream':'2.0'}]

OSP13 で UEFI ブートおよび UEFI ブートローダーを使用するシステムは、UEFI の問題が発生し以下のような状況に陥る可能性があります。

システムで UEFI が使用されている場合は、Red Hat Technical Support にお問い合わせください。詳細は、Red Hat ナレッジベースのソリューション FFU 13 to 16.1: Leapp fails to update the kernel on UEFI based systems and /etc/fstab does not contain the EFI partition を参照してください。

現在、[workarounds]/disable_native_luksv1 および [workarounds]/rbd_volume_local_attach 設定オプションに関する既知の問題が存在します。これらのオプションは、libgcrypt および librdb の既知のパフォーマンスリグレッションに対する一時的な回避策としてのみ提供されます。RHOSP で使用されるベースの RHEL リリースでリグレッションが解決されたら、これらの回避策用オプションは削除されます。

これらの回避策用オプションのいずれかを使用する際には、注意が必要です。これらの注意に従わない場合、RDB 暗号化ボリュームで問題が発生する可能性があります。注意事項は以下のとおりです。

Red Hat Ceph Storage のサブスクリプションを使用し、Red Hat Ceph Storage ノード用に overcloud-minimal イメージを使用するように director を設定している場合、Leapp の制限により Red Hat Ceph Storage ノードのオペレーティングシステムのアップグレードに失敗する可能性があります。

この問題を回避するには、system_upgrade の実行ステップの後に、Red Hat Ceph Storage ノードにログインして RHEL のマイナーリリースバージョンの設定を解除し、利用可能な最新の RHEL マイナーリリースバージョンに更新し、ノードをリブートする必要があります。

Leapp アップグレード用の RPM コンテンツをホストするのに Red Hat Satellite Server を使用している場合、使用するコンテンツビューに以下の 8.2 リポジトリーを追加する必要があります。

詳細は、BZ#1936419 を参照してください。

現在、ceph-ansible には、外部の非管理 Ceph クラスターを使用するように設定された Ceph Ganesha コンテナーのデプロイまたは更新に使用された場合、Ansible Playbook が正常に完了しないという既知の問題があります。

この問題により、Shared File Systems サービス (manila) と共に Ceph Ganesha を使用し、外部の Ceph クラスターを使用するように設定されたオーバークラウドのデプロイメント、マイナー更新、またはメジャーアップグレードに失敗します。

回避策:

環境が Shared File Systems サービスと共に Ceph Ganesha を使用し、外部の Ceph クラスターを使用するように設定されている場合、オーバークラウドのアップグレードまたはマイナー更新を行う際に、ceph-ansible バージョン 4.0.49.1 以降を使用してください。これらの条件下では、アンダークラウドにインストールされた 4.0.49.1 よりも前のバージョンの ceph-ansible でアップグレードを試みないでください。

Networking (neutron) サービスで DNS インテグレーションが有効な場合、インスタンスが作成されると、Compute (nova) サービスはインスタンスの表示名をサニタイズして、有効なホスト名を生成します。

今回の更新以前は、サニタイズでインスタンス名のピリオド (.) が置き換えられませんでした (例: rhel-8.4)。これにより、表示名が完全修飾ドメイン名 (FQDN) として認識され、無効なホスト名が生成される場合がありました。インスタンス名にピリオドが含まれ、DNS インテグレーションが Networking サービスで有効化されている場合、Networking サービスは無効なホスト名を拒否し、その結果インスタンスの作成に失敗し、Compute サービスから HTTP 500 サーバーエラーが返されました。

今回の更新により、インスタンス名のピリオドはハイフンに置き換えられ、ホスト名が FQDN として解析されなくなりました。インスタンスの表示名には、引き続きフリーフォームの文字列を使用できます。

今回の更新により、一部のケースで openstack undercloud upgrade 実行前に検証に失敗する原因となっていたバグが修正されました。今回のアップグレード以前は、要求されたロギングディレクトリーへのアクセスに必要な権限がない場合、以下のようなエラーが発生することがありました。

今回の更新により、CephStorage ノードでの実行中に Leapp によるアップグレードが停止および失敗することの原因となっていた設定の問題が修正されました。

以前のリリースでは、CephStorage ノードは、Leapp によるアップグレード時に OpenStack highavailability、advanced-virt、および fast-datapath リポジトリーを使用するように誤って設定されていました。

UpgradeLeappCommand オプションがノードごとに設定可能になり、CephStorage ノードに正しいデフォルトを使用し、CephStorage ノードで Leapp によるアップグレードが正常に実行できるようになりました。

本リリース以前は、API 要求を再試行するたびに SolidFire ドライバーが重複ボリュームを作成していました。これにより、未使用のボリュームが蓄積し、予期しない動作が発生していました。

今回の更新により、Block Storage サービス (cinder) は、ボリュームを作成する前に既存のボリューム名の有無をチェックするようになりました。Block Storage サービスが読み取りタイムアウトを検出すると、ボリュームの作成を直ちにチェックし、無効な API 呼び出しを防ぎます。今回の更新で、SolidFire ドライバーの sf_volume_create_timeout オプションが追加され、お使いの環境に適切なタイムアウト値を設定できるようになりました。

今回の更新により、ワークロードのリバランス操作時に、スナップショットの作成など一部の API 呼び出しが、xNotPrimary エラーと共に失敗する原因となっていた問題が修正されました。

SolidFire の負荷が大きい場合やアップグレードされている場合、SolidFire クラスターは、プライマリーノードからセカンダリーノードに接続を自動的に移動させることにより、クラスターのワークロードのリバランスを行います。以前のリリースでは、これらのワークロードのバランス操作時に、一部の API 呼び出しが xNotPrimary エラーと共に失敗し、再試行されませんでした。

今回の更新により、SolidFire ドライバーの再試行可能な例外リストに xNotPrimary 例外を追加することで、問題が修正されました。

以前のリリースでは、iSCSI または FC ターゲットが RHOSP ホストに接続されていない場合、Dell EMC XtremIO ドライバーを使用する Red Hat OpenStack Platform (RHOSP) デプロイメントでは、タイムアウトするまでボリュームの接続操作を待機していました。これにより、ボリュームの接続操作が失敗しました。

今回のリリースで、Dell EMC XtremIO ドライバーのポートフィルタリングのサポートが追加され、使用されていない iSCSI ポートまたは FC ポートが無視されるようになりました。

今回の更新以前は、Shared File Systems サービス (manila) ダッシュボードには動的なフォーム要素があり、その名前により、フォームが応答しなくなる可能性があります。そのため、共有ネットワーク内での共有グループ、共有ネットワーク、およびファイル共有の作成が機能しませんでした。

今回の更新により、名前が問題となる可能性がある動的要素がエンコードされるようになりました。そのため、共有ネットワーク内での共有グループ、共有ネットワーク、およびファイル共有の作成が正常に機能するようになりました。

以前のリリースでは、Dell EMC PowerStore ポートが複数の用途 (iSCSI、レプリケーション等) に設定された場合、誤った REST フィルタリングにより、cinder ドライバーはアクセス可能な iSCSI ターゲットが見つからなかったと報告していました。

今回のリリースでは、Dell EMC PowerStore REST フィルター機能が修正されました。

今回の更新以前は、ユーザーが DEFAULT ボリュームタイプを削除する際に失敗が発生していました。

今回の更新により、cinder.conf ファイルの default_volume_type パラメーターの値として設定されていない場合に、DEFAULT のボリューム種別を削除できるようになりました。default_volume_type パラメーターのデフォルト値は DEFAULT です。したがって、DEFAULT のボリューム種別を削除できるように、これを tripleo などの適切なボリューム種別に設定する必要があります。

今回の更新以前は、OpenStack コンポーネントの tripleo 検証中に、以下の例外エラーが発生しました。

Unhandled exception during validation run.

このエラーは、コードの変数が参照されても割り当てられないことが原因で発生しました。

今回の更新でこの問題が修正され、このエラーなしで検証が実行されるようになりました。

今回の更新以前は、iSCSI ポータルへの接続中に例外が処理されませんでした。たとえば、iscsiadm -m session の失敗などです。これは、一部の障害パターンで _connect_vol スレッドが予期せず中断する可能性があるために発生しました。この中断により、_connct_vol スレッドからの結果を待つ間に後続のステップでハングアップが発生します。

今回の更新で、iSCSI ポータルへの接続中の例外が _connect_vol メソッドで正しく処理され、スレッドの結果を更新せずに予期せず中断することがなくなりました。

今回の更新以前は、KernelArgs パラメーターを変更すると、バージョン 13 から 16 への Red Hat OpenStack Platform (RHOSP) Fast Forward Upgrade (FFU) プロセスでエラーが発生していました。

今回の更新以前は、暗号化されたボリュームのスナップショットからボリュームを作成すると、ボリュームが使用できなくなる可能性がありました。宛先ボリュームが元のボリュームと同じサイズである場合は、暗号化されたボリュームのスナップショットから暗号化されたボリュームを作成する場合、新規ボリューム内のデータが省略されて切り捨てられます。これにより、サイズの不一致が生じました。

今回の更新により、RBD バックエンドが暗号化ヘッダーに対応し、データを切り捨てなくなり、暗号化されたボリュームのスナップショットからボリュームを作成してもエラーが生じなくなりました。

今回の機能拡張で、Red Hat OpenStack Platform ノードにポリシーベースのルーティングを使用できるようになりました。これにより、os-net-config で複数のルーティングテーブルおよびルーティングルールを設定することができます。

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

ハイパーバイザーのホスト名を検出するロジックが修正され、Compute サービス (nova) の libvirt ドライバーと一貫性のある結果を返すようになりました。今回の修正により、最小帯域幅を確保する QoS 機能を使用する際に、resource_provider_hypervisors オプションを指定する必要がなくなりました。

今回の更新で、デフォルトのハイパーバイザー名を置き換えるために、Modular Layer 2 と Open Virtual Network メカニズムドライバーの組み合わせ (ML2/OVN) に、新しいオプション resource_provider_default_hypervisor が追加されました。このオプションは、ユーザーがカスタマイズする必要がある場合に、resource_provider_hypervisors オプションでインターフェイスまたはブリッジのリストを指定せずに root リソースプロバイダーを見つけます。この新しいオプションは、ovs-agent の [ovs] ini-section と、sriov-agent の [sriov_nic] ini-section にあります。

今回の機能拡張により、新たな CinderRpcResponseTimeout パラメーターおよび CinderApiWsgiTimeout パラメーターが追加され、Block Storage サービス (cinder) での RPC および API WSGI タイムアウトの調整がサポートされるようになりました。大規模なデプロイメントや、システムの負荷が原因でトランザクションが遅延する可能性がある場合には、デフォルトのタイムアウト値が適切ではない場合があります。

RPC および API WSGI タイムアウトを調整して、トランザクションが早期にタイムアウトしないようにできるようになりました。

今回の更新により、tripleo validator コマンドが、キーと値のペア形式で変数と環境変数を受け入れるようになりました。以前のリリースでは、JSON ディクショナリーのみが環境変数を許可しました。

openstack tripleo validator run \
[--extra-vars key1=<val1>[,key2=val2 --extra-vars key3=<val3>] \
| --extra-vars-file EXTRA_VARS_FILE] \
[--extra-env-vars key1=<val1>[,key2=val2 --extra-env-vars key3=<val3>]]
(--validation <validation_id>[,<validation_id>,...] | --group <group>[,<group>,...])

$ openstack tripleo validator run --validation check-cpu,check-ram --extra-vars minimal_ram_gb=8 --extra-vars minimal_cpu_count=2

サポートされるオプションの完全なリストを確認するには、以下のコマンドを実行します。

$ openstack tripleo validator run --help

現在、ポートの MAC-IP アドレスが不明な場合に、特定の実際のシナリオをシミュレートできない既知の問題があります。RHOSP Networking サービス (neutron) は、DHCP またはセキュリティーグループが設定されていない場合でも、ポートの MAC-IP を直接指定します。

回避策:RHOSP 16.1.7 にアップグレードし、ML2/OVN v21.03 をインストールします。DHCP とポートセキュリティーが無効にされている場合、ポートの address フィールドには MAC-IP アドレスのペアが含まれず、ML2/OVN は MAC のラーニング機能を使用してトラフィックを必要なポートにだけ送信することができます。

今回の更新以前は、IPv6 内部 API ネットワークを使用した DCN と HCI の組み合わせのデプロイメントでは、Block Storage サービス (cinder) および etcd サービスは不適切な etcd URI で設定され、Block Storage サービスおよび etcd サービスが起動時に失敗していました。

今回の更新により、etcd URI の IPv6 アドレスが正しくなり、Block Storage サービスおよび etcd サービスが正常に起動するようになりました。

今回の更新により、Telemetry ヘルスチェックがより堅牢になり、ヘルスチェックの解析方法が簡素化されました。

ヘルスチェックを直接実行するときに冗長モードを取得するには、sudo podman -u root -e "HEALTHCHECK_DEBUG=1" <container> /openstack/healthcheck コマンドを実行します

この更新の前に、OpenStack Storage サービス (cinder) GPFS SpectrumScale ドライバーは、ストレージバックエンドがコピーオンライト (COW) モードをサポートしているかどうかを正しく検出しませんでした。その結果、ドライバーは、イメージからボリュームを迅速に作成する機能などの COW 機能を無効にします。これにより、イメージから複数のインスタンスを同時に起動すると、一部のインスタンスがタイムアウトする可能性があります。

今回の更新により、GPFS SpectrumScale ドライバーは、ストレージバックエンドの COW サポートを適切に検出します。

この更新以前は、PowerMaxOS 5978.711 でスナップショットを作成すると、REST でペイロード応答が変更され、デバイスラベルの形式が変更されました。ソリューションイネーブラーからの基になるデータが変更され、コロン文字 (:) が含まれなくなりました。これにより、PowerMax ドライバーで IndexError 例外が発生します。

IndexError: list index out of range

今回の更新で、この問題は PowerMaxOS 5978.711 以降で解決されています。

実験的な rsyslog reopenOnTruncate を有効にして、ファイルでログローテーションが発生したときに rsyslog がすぐに認識できるようにします。この設定は、rsyslog と連携するように設定されたすべてのサービスに影響します。

rsyslog reopenOnTruncate が無効になっていると、rsyslog はログファイルが元の容量までいっぱいになるのを待ってから、追加のログを使用します。

この機能強化により、metrics_qdr サービスを新しい AMQ Interconnect リリースに更新するための環境が準備されます。これには、Service Telemetry Framework (STF) デプロイメントからの CA 証明書の内容のインポートが必要です。metrics_qdr サービスが更新されていないため、Red Hat OpenStack Service Platform (RHOSP) をデプロイまたは更新する場合、管理者はまだ変更を必要としません。この機能は、将来のリリースでの metrics_qdr サービスの更新に備えています。

https://bugzilla.redhat.com/show_bug.cgi?id=1949169 が出荷されたら、次の手順が必要になります。

今回の更新では、新しいオーケストレーションサービス (heat) パラメーター MetricsQdrSSLProfiles を提供することで、この問題を修正します。

Red Hat OpenShift TLS 証明書を取得するには、次のコマンドを実行します。

$ oc get secrets
$ oc get secret/default-interconnect-selfsigned -o jsonpath='{.data.ca\.crt}' | base64 -d

Red Hat OpenShift TLS 証明書の内容を含む MetricsQdrSSLProfiles パラメーターをカスタム環境ファイルに追加します。

MetricsQdrSSLProfiles:
    -   name: sslProfile
        caCertFileContent: |
           -----BEGIN CERTIFICATE-----
           ...
           TOpbgNlPcz0sIoNK3Be0jUcYHVMPKGMR2kk=
           -----END CERTIFICATE-----

次に、openstack overcloud deploy コマンドを使用してオーバークラウドを再デプロイします。

今回の更新により、ML2/OVS デプロイメントのハードウェアオフロードポートに QoS の最大帯域幅制限、出力方向ルールを設定できるようになりました。通常の QoS ポリシー/ルールメソッドを使用してポリシーを設定します。

バックエンドは、通常の OVS QoS エンジンではなくポリシーを適用するために ip link コマンドを使用します。これは、OVS meter アクションをオフロードできないためです。meter アクションがオフロードではない を参照してください。

既知の問題により、RHOSP 16.1.8 への更新後に Neutron の起動に失敗します。その後、Neutron を起動すると、OVN データベースが不安定になります。

RHOSP 16.1.9 では修正が予定されています。Red Hat は、可能であれば 16.1.9 に直接更新するまで待つことを推奨します。

16.1.8 のホットフィックスを利用できます。RHOSP 16.1.8 に緊急に更新する必要がある場合は、Red Hat グローバルサポートサービスに連絡して、環境がホットフィックスと互換性があるかどうかを確認してください。

この問題を追跡するには、https://bugzilla.redhat.com/show_bug.cgi?id=2125824 を参照してください。

このリリースより前は、dpdk-telemetry プラグインがインストールされていないにもかかわらず、dpdk-telemetry collectd 設定ファイルが自動的に作成されていたため、collectd コンテナーはコンピュートノードで開始できませんでした。

このリリースの時点で、dpdk_telemetry 設定ファイルが collectd コンテナーから削除されています。

RHOSP 16.1.9 の今回の更新では、RHOSP 16.1.8 への更新後に Networking サービス (neutron) の開始に失敗し、RHOSP 16.1.8 への更新後に OVN データベースが不安定になるバグが修正されています。

RHOSP 16.1.8 に更新する代わりに、RHOSP 16.1.9 に直接更新します。

今回の更新の前は、do_sync_check 操作中に一時的でないスナップショットの削除のチェックが行われなかったため、do_sync_check 操作によってボリュームから一時的でないスナップショットが誤って削除される可能性がありました。今回の更新では、スナップショットを削除する必要があるかどうかを判断するチェックがあります。do_sync_check 操作では、必要なくても、一時的ではないスナップショットの削除は行われません。

今回の更新の前は、ストレージグループが親ストレージグループの子であるかどうかを確認する際に、条件として大文字と小文字が区別されていました。 ストレージグループの変更中に、親ストレージグループにすでに子ストレージグループが含まれているというエラーが表示されました。今回の更新により、条件で使用されるパターンで大文字と小文字が区別されなくなり、ストレージグループを正常に変更できるようになりました。

今回の更新の前は、Telemetry サービス (ceilometer) ユーザーには、Object Storage サービス (swift) からオブジェクトをポーリングするための十分な権限がありませんでした。Object Storage サービスクライアントでは、Telemetry サービスユーザーがオブジェクトの詳細をフェッチできませんでした。今回の更新により、Telemetry サービスユーザーは ResellerAdmin ロールに関連付けられます。

この問題を手動で回避するには、次のコマンドを実行します。

$ openstack role add --user ceilometer --project service ResellerAdmin

関連する Telemetry サービスユーザーは、Object Storage サービスオブジェクトメトリックを正常にポーリングできます。

今回の更新により、director は、Shared File Systems サービス (manila) で CephFS-NFS バックエンドを使用する場合に、NVSv4 ID マッピングのオーバーライドの指定をサポートします。Shared File Systems サービスを使用する Ceph-NFS では、NFSv4.1+ を介したクライアントアクセスのみが許可されます。NFSv4.1 では、ユーザー名とグループ名が回線経由で送信され、サーバーとクライアントの両方で変換されます。デプロイ担当者は、ドメイン設定をカスタマイズして、複数のクライアントから共有ファイルシステムサービス共有にアクセスできる組織ユーザーをより適切に表すことができます。Director は、次のパラメーターによる NFS ID マッピング設定のカスタマイズをサポートしています。

ロールベースのアクセス制御 (RBAC) を使用して、プロジェクト間でセキュリティーグループを共有できます。ただし、インスタンスの起動時に --security-group 引数を使用して RBAC 共有セキュリティーグループを割り当てることはできません。openstack server create コマンドで --security-group 引数 を使用して RBAC 共有セキュリティーグループを割り当てようとすると、Compute サービス (nova) はセキュリティーグループを見つけられず、インスタンスの作成に失敗します。これは、Compute サービスが RBAC を介して共有されているセキュリティーグループをチェックしないためです。--security-group 引数で指定されたセキュリティーグループが、インスタンスを作成したプロジェクトに存在するかどうかのみを確認します。

回避策: ポートを作成し、セキュリティーグループをポートに割り当てます。ポートを指定するには、openstack server create コマンドで --nic 引数を使用します。Compute サービスは Networking サービス (neutron) でポートを作成しようとしないため、セキュリティーグループをチェックしません。

以下に例を示します。

   $ openstack port create --network net1 \
     --security-group \
     5ba835b7-22b0-4be6-bdbe-e0722d1b5f24 shared-sg-port

   $ openstack server create \
     --image cirros-0.5.1-x86_64-disk  \
     --flavor m1.tiny \
     --port shared-sg-port vm-with-shared-sg

現在のバージョンでは、移行先ホストの CPU と互換性のない CPU を使用してインスタンスをライブマイグレーションする場合に既知の問題があります。libvirt (QEMU >= 2.9 および libvirt >= 4.4.0) は、ライブマイグレーション中に宛先ホストの CPU 互換性チェックを正しく処理するため、回避策として、インスタンスを移行する前に宛先ホストで Compute サービスの CPU 比較チェックをスキップできます。

回避策: インスタンスのライブマイグレーションを実行する前に、影響を受ける各コンピュートノードの nova.conf ファイルに次の設定を追加します。

[workarounds]
skip_cpu_compare_on_dest = True