3.5. Red Hat OpenStack Platform 16.1.4 メンテナーンスリリース (2021 年 3 月 17 日)

今回の更新以前は、ユーザーが標準の 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 でアップグレードを試みないでください。