3.14. Red Hat OpenStack Platform 13 メンテナーンスリリース (2020 年 10 月 28 日)

今回の更新以前は、コンピュートノードが復元されるまで、Compute (nova) サービスはネットワークポート等のリソースを解放しませんでした。これにより、ダウンしたコンピュートノードのインスタンスからネットワークポートを切り離すことができない場合に、Load-balancing サービス (octavia) がフェイルオーバーに失敗していました。

今回の更新により、Load-balancing サービスのフェイルオーバーフローが更新され、この Compute サービスの問題を回避できるようになりました。Load-balancing サービスは、Compute サービスが解放しないポートを放棄し、コンピュートノードが復元されたら Compute サービスまたは Networking サービスがクリーンアップするように削除待ちの状態のままにするようになりました。これにより問題が解決され、コンピュートノードがまだダウンした状態でもフェイルオーバーが成功します。

今回の更新以前は、複数の復元が同時に実行されていると、システムがメモリーを使い果たすため、バックアップサービスが失敗していました。

今回の更新で、データをすぐに参照する回数を減らして、バックアップ/リストア操作時に Python がメモリーを解放する頻度を上げました。これにより、Python は復元が完了するのを待たずに、データが展開されたら直ぐにデータのガベージ収集を行うことができます。これにより問題が解決され、バックアップサービスが複数の復元を同時に処理できるようになりました。

今回の更新以前は、スナップショットからボリュームを作成する際の非同期移行中に作成された内部の一時スナップショットが、VNX ストレージから削除されませんでした。

たとえば、ボリューム V1 から作成したスナップショット S1 から新規ボリューム V2 を作成する場合、S1 のコピーから内部の一時スナップショット S2 が作成されます。V1 は、2 つのスナップショット S1 および S2 を持つようになります。V1、V2、および S1 を OpenStack Block Storage (cinder) から削除しても、S2 は削除されません。これにより、V1 と S2 の両方が VNX ストレージ上に残ります。

今回の更新で、一時スナップショット S2 が削除され、V1 が正常に削除できるようになりました。

今回の更新以前は、RHOSP 10 から RHOSP 13 へのアップグレード後に、インスタンスはそのボリュームにアクセスすることができませんでした。OpenStack Block Storage (cinder) サービスをホストからコンテナーに移行する前に、OpenStack Block Storage のバックエンドとして使用されている NFS 共有がアンマウントされないためです。したがって、コンテナー化されたサービスが起動し、OpenStack Block Storage サービスディレクトリー内の全ファイルの所有者を変更すると、NFS 共有上のファイルの所有者も変更されていました。

今回の更新により、コンテナー内で実行されるようにサービスをアップグレードする前に、OpenStack Block Storage NFS 共有がアンマウントされるようになりました。これにより問題が解決され、RHOSP 13 へのアップグレード後にインスタンスがボリュームにアクセスできるようになりました。

今回の更新以前は、OpenStack Shared File Systems (manila) サービスが VServer スコープの ONTAP 認証情報で設定されている場合、ファイル共有のプロビジョニングに失敗していました。これは、昨今の NetApp ONTAP ドライバーの変更により、ストレージシステム機能の特定を試みる間、共有マネージャーサービスが再起動ループから抜け出せなくなるためです。

今回の更新により、NetApp ONTAP ドライバーは Vserver スコープの NetApp ユーザーを確認し、ストレージシステム機能を特定するためのフォールバックパスを追加するようになりました。これにより、問題が解決されました。OpenStack Shared File Systems 共有マネージャーサービスはストレージシステム機能を正しく特定し、ファイル共有のプロビジョニングに成功するようになりました。

今回の更新以前は、エージェントとの初期接続エラーによりリトライロジックを中断され、エージェントが Ironic サービスとの通信に失敗し、エージェントのコンソールに誤った TypeError が記録されていました。

今回の更新で、既知の接続および検索失敗ケースを明示的に処理するように例外処理が修正され、エージェントで何が生じているかについて明確な情報を提供するようにロギングが更新されました。接続がエージェントの要求どおりにリトライされ、予期しない異常が発生した場合にログが TypeError とだけ報告することがなくなりました。

起動時に、ironic-conductor サービスにより、ironic-conductor 再起動プロセスの初期段階で受け入れられた作業についてのベアメタルノードの予約ロックが失われる可能性があります。ロックが失われると、ironic-conductor サービスの再起動時に OpenStack Bare Metal Provisioning (ironic)デプロイメントに送信された作業に対して競合状態が発生し、要求が NodeNotLocked エラーで失敗していました。

今回の更新により、ironic-conductor プロセスで作業を許可する前にデータベースのクリーンアップチェックが実行され、問題が解決されました。