第4章 テクニカルノート
本章には、コンテンツ配信ネットワークからリリースされる Red Hat OpenStack Platform「Rocky」のエラータアドバイザリーの補足情報を記載します。
4.1. RHEA-2019:0045: OpenStack director のバグ修正アドバイザリー リンクのコピーリンクがクリップボードにコピーされました!
本項に記載するバグは、アドバイザリー RHEA-2019:0045 で対応しています。このアドバイザリーについての詳しい情報は、「RHEA-2019:0045 - Product Enhancement Advisory」を参照してください。
ansible-role-redhat-subscription
- BZ#1641180
以前のリリースでは、Satele URL がロールに正しく設定されていませんでした。このためシステムは Satellite サーバーのバージョンを取得できず、登録に失敗していました。今回の修正で、デフォルトで rhsm_baseurl パラメーターから rhsm_satellite_url の値を取得し、URL を登録タスクに渡して強制的に登録する機能が追加されました。さらに、登録証のエラーを無視するオプションが追加されました。必要に応じて、デフォルト値の上書きやオプションの設定が可能です。
以前のリリースでは、Satele URL がロールに正しく設定されていませんでした。このためシステムは Satellite サーバーのバージョンを取得できず、登録に失敗していました。今回の修正で、デフォルトで rhsm_baseurl パラメーターから rhsm_satellite_url の値を取得し、URL を登録タスクに渡して強制的に登録する機能が追加されました。さらに、登録証のエラーを無視するオプションが追加されました。必要に応じて、デフォルト値の上書きやオプションの設定が可能です。
distribution
- BZ#1640095
これまでテクノロジープレビューとして含まれていた OpenStack Rally が、本リリースから削除されました。
これまでテクノロジープレビューとして含まれていた OpenStack Rally が、本リリースから削除されました。
openstack-aodh
- BZ#1467317
今回の更新で、aodh サービスがイベントタイプの入力クエリーを検証するようになりました。 今回の更新以前は、入力クエリーは検証されていませんでした。無効な入力クエリーのために、警告の発行に失敗する場合がありました。
今回の更新で、aodh サービスがイベントタイプの入力クエリーを検証するようになりました。
今回の更新以前は、入力クエリーは検証されていませんでした。無効な入力クエリーのために、警告の発行に失敗する場合がありました。
openstack-ceilometer
- BZ#1521176
Nova がインスタンスを作成/起動/削除した正確な時間を追跡するために、インスタンスリソースに 3 つの新たな属性 (launched_at、deleted_at、および created_at) が追加されました。
Nova がインスタンスを作成/起動/削除した正確な時間を追跡するために、インスタンスリソースに 3 つの新たな属性 (launched_at、deleted_at、および created_at) が追加されました。
- BZ#1596033
OpenStack Metrics サービス (Ceilometer) が、Monitoring サービス (Gnocchi) で計測されないメトリックを作成していました。今回の修正で、不必要なメトリックが削除されました。Ceilometer は、Gnocchi で計測されるメトリックだけを作成するようになりました。
OpenStack Metrics サービス (Ceilometer) が、Monitoring サービス (Gnocchi) で計測されないメトリックを作成していました。今回の修正で、不必要なメトリックが削除されました。Ceilometer は、Gnocchi で計測されるメトリックだけを作成するようになりました。
openstack-cinder
- BZ#1033180
本リリースでは、テクノロジープレビューとして、cinder および nova の両方において、ボリュームを同時に複数のホストまたはサーバーに読み取り/書き込み (RW) モードでアタッチする機能が追加されています (この機能がバックエンドドライバーでサポートされる場合)。この機能は、一般的にアクティブ/アクティブまたはアクティブ/スタンバイのシナリオが求められる、クラスター化したアプリケーション負荷のユースケースに対応したものです。
本リリースでは、テクノロジープレビューとして、cinder および nova の両方において、ボリュームを同時に複数のホストまたはサーバーに読み取り/書き込み (RW) モードでアタッチする機能が追加されています (この機能がバックエンドドライバーでサポートされる場合)。この機能は、一般的にアクティブ/アクティブまたはアクティブ/スタンバイのシナリオが求められる、クラスター化したアプリケーション負荷のユースケースに対応したものです。
- BZ#1262068
今回の機能拡張により、ボリュームが同じ Ceph クラスター内にある場合に、Cinder バックエンド間の RBD ボリュームの移行が最適化されるようになりました。両方のボリュームが同じ Ceph クラスターにある場合には、データ移行が cinder-volume プロセスではなく Ceph 自体で実施されます。これにより、移行に要する時間が短縮されます。
今回の機能拡張により、ボリュームが同じ Ceph クラスター内にある場合に、Cinder バックエンド間の RBD ボリュームの移行が最適化されるようになりました。両方のボリュームが同じ Ceph クラスターにある場合には、データ移行が cinder-volume プロセスではなく Ceph 自体で実施されます。これにより、移行に要する時間が短縮されます。
openstack-ironic
- BZ#1649894
OpenStack Bare Metal サービス (Ironic) から BMC/IPMI ハードウェアに送信されるコマンドの中には、ハードウェアドライバーのエラーにより正常に機能しないものがありました。このため、ベアメタルノードの起動が妨げられていました。今回の修正で ipmi_disable_boot_timeout ハードウェアドライバーオプションが追加され、これらのコマンドが Ironic から IPMI ハードウェアに送信されなくなりました。
OpenStack Bare Metal サービス (Ironic) から BMC/IPMI ハードウェアに送信されるコマンドの中には、ハードウェアドライバーのエラーにより正常に機能しないものがありました。このため、ベアメタルノードの起動が妨げられていました。今回の修正で ipmi_disable_boot_timeout ハードウェアドライバーオプションが追加され、これらのコマンドが Ironic から IPMI ハードウェアに送信されなくなりました。
- BZ#1394888
- BZ#1562171
今回の更新では、「neutron」ネットワークインターフェースを使用したマルチテナントベアメタルネットワーク設定が導入されています。 「neutron」ネットワークインターフェースを使用してベアメタルノードを設定すると、ベアメタルノードでのプロビジョニングとテナントトラフィック用に、独立した VLAN ネットワークを使用することができます。
今回の更新では、「neutron」ネットワークインターフェースを使用したマルチテナントベアメタルネットワーク設定が導入されています。
「neutron」ネットワークインターフェースを使用してベアメタルノードを設定すると、ベアメタルノードでのプロビジョニングとテナントトラフィック用に、独立した VLAN ネットワークを使用することができます。
- BZ#1638003
本リリース以前は、ironic-conductor ハッシュリングコードに競合状態が存在していました。動作中ハッシュリングを None に設定することはできますが、これにより内部サーバーエラー「'NoneType' object has no attribute '__getitem__'」が発生していました。本リリースでは競合状態が修正され、ironic API 操作がエラー「'NoneType' object has no attribute '__getitem__'」で失敗することはなくなりました。
本リリース以前は、ironic-conductor ハッシュリングコードに競合状態が存在していました。動作中ハッシュリングを None に設定することはできますが、これにより内部サーバーエラー「'NoneType' object has no attribute '__getitem__'」が発生していました。本リリースでは競合状態が修正され、ironic API 操作がエラー「'NoneType' object has no attribute '__getitem__'」で失敗することはなくなりました。
openstack-keystone
- BZ#1462048
今回の更新で、アプリケーションの認証情報を作成して、アプリケーションの keystone に対する認証を許可できるようになりました。 https://docs.openstack.org/keystone/latest/user/application_credentials.html を参照してください。
今回の更新で、アプリケーションの認証情報を作成して、アプリケーションの keystone に対する認証を許可できるようになりました。
https://docs.openstack.org/keystone/latest/user/application_credentials.html を参照してください。
openstack-manila-ui
- BZ#1600664
Manilla 用の OpenStack Dashboard (Horizon) プラグインは、プロジェクトクォータ情報を取得できませんでした。そのため、共有ファイルシステムのダッシュボードでファイル共有を作成できず、またレンダリングの問題が生じていました。今回の修正でクォータ情報取得の操作が想定どおりに機能するようになり、共有ファイルシステムを表示してダッシュボードでファイル共有を作成できるようになりました。
Manilla 用の OpenStack Dashboard (Horizon) プラグインは、プロジェクトクォータ情報を取得できませんでした。そのため、共有ファイルシステムのダッシュボードでファイル共有を作成できず、またレンダリングの問題が生じていました。今回の修正でクォータ情報取得の操作が想定どおりに機能するようになり、共有ファイルシステムを表示してダッシュボードでファイル共有を作成できるようになりました。
openstack-neutron
- BZ#1608090
linuxbridge ml2 ドライバーを使用している場合、権限のないテナントが IP アドレスを指定せずにポートを作成してそれをアタッチすることができるので、IP アドレスの検証が省略されてしまいます。その後、許可された割り当てプール以外から既存のゲストまたはルーターと競合する IP アドレスが割り当てられると、サービス拒否が発生する可能性があります。
linuxbridge ml2 ドライバーを使用している場合、権限のないテナントが IP アドレスを指定せずにポートを作成してそれをアタッチすることができるので、IP アドレスの検証が省略されてしまいます。その後、許可された割り当てプール以外から既存のゲストまたはルーターと競合する IP アドレスが割り当てられると、サービス拒否が発生する可能性があります。
openstack-nova
- BZ#1512941
今回の更新で、パケット破棄の削減用に、チューニング可能なオプションが新たに 2 つサポートされるようになりました。 強固なパーティション設定が使用されていても (isolcpus、tuned)、仮想 CPU (vCPU) がハイパーバイザーカーネルスレッドにより占有される場合があります。占有は頻繁ではなく 1 秒あたり数回ですが、virtio キュー 1 つあたりの記述子が 256 であれば、1 回の仮想 CPU 占有が発生しただけでパケットの破棄につながります (占有されている間 256 のスロットが埋まるため)。キュー 1 つあたりのパケットレートが 1 Mpps (1 秒あたり 100 万パケット) を超えているネットワーク機能仮想化 (NFV) の仮想マシンがこのケースです。 今回の更新で、2 つの新しいチューニング可能なオプション (「rx_queue_size」および「tx_queue_size」) がサポートされるようになりました。これらのオプションを使用して virtio NIC の受信キューサイズおよび送信キューサイズを設定し、パケットの破棄を削減します。
今回の更新で、パケット破棄の削減用に、チューニング可能なオプションが新たに 2 つサポートされるようになりました。
強固なパーティション設定が使用されていても (isolcpus、tuned)、仮想 CPU (vCPU) がハイパーバイザーカーネルスレッドにより占有される場合があります。占有は頻繁ではなく 1 秒あたり数回ですが、virtio キュー 1 つあたりの記述子が 256 であれば、1 回の仮想 CPU 占有が発生しただけでパケットの破棄につながります (占有されている間 256 のスロットが埋まるため)。キュー 1 つあたりのパケットレートが 1 Mpps (1 秒あたり 100 万パケット) を超えているネットワーク機能仮想化 (NFV) の仮想マシンがこのケースです。
今回の更新で、2 つの新しいチューニング可能なオプション (「rx_queue_size」および「tx_queue_size」) がサポートされるようになりました。これらのオプションを使用して virtio NIC の受信キューサイズおよび送信キューサイズを設定し、パケットの破棄を削減します。
- BZ#1398343
Nova の libvirt ドライバーは、ゲスト CPU モデルの設定時に CPU 機能のフラグをより細かく指定できるようになりました。 たとえば、「Meltdown」CVE の修正を適用した後に特定の Intel ベースの仮想 CPU モデルを実行することで生じるゲストパフォーマンスの低下を、この機能により軽減することができます。ゲストのパフォーマンスに対する影響は、CPU 機能フラグ「PCID」(Process-Context ID) をゲスト CPU に公開することによって軽減されます。これは、物理ハードウェア自体で PCID フラグが利用可能であることを前提とします。 CPU フラグのより細かな指定方法についての詳しい情報は、nova.conf の [libvirt]/cpu_model_extra_flags の説明を参照してください。
Nova の libvirt ドライバーは、ゲスト CPU モデルの設定時に CPU 機能のフラグをより細かく指定できるようになりました。
たとえば、「Meltdown」CVE の修正を適用した後に特定の Intel ベースの仮想 CPU モデルを実行することで生じるゲストパフォーマンスの低下を、この機能により軽減することができます。ゲストのパフォーマンスに対する影響は、CPU 機能フラグ「PCID」(Process-Context ID) をゲスト CPU に公開することによって軽減されます。これは、物理ハードウェア自体で PCID フラグが利用可能であることを前提とします。
CPU フラグのより細かな指定方法についての詳しい情報は、nova.conf の [libvirt]/cpu_model_extra_flags の説明を参照してください。
- BZ#1402584
- BZ#1469073
- BZ#1625122
今回の更新で、ヒュージページを持つインスタンスを起動する際に、Nova がホストヒュージページの NUMA アフィニティーをスクリーニングするようになりました。Nova は、十分なヒュージページのない NUMA ノードを拒否します。 今回の更新以前は、Nova はホストヒュージページの NUMA アフィニティーをスクリーニングしていませんでした。ホストに十分な NUMA ページがなければ、CPU の数が十分であってもインスタンスは起動に失敗していました。
今回の更新で、ヒュージページを持つインスタンスを起動する際に、Nova がホストヒュージページの NUMA アフィニティーをスクリーニングするようになりました。Nova は、十分なヒュージページのない NUMA ノードを拒否します。
今回の更新以前は、Nova はホストヒュージページの NUMA アフィニティーをスクリーニングしていませんでした。ホストに十分な NUMA ページがなければ、CPU の数が十分であってもインスタンスは起動に失敗していました。
openstack-sahara
- BZ#1547708
OpenStack Sahara が Cloudera Distribution Hadoop (CDH) プラグイン 5.13 をサポートするようになりました。
OpenStack Sahara が Cloudera Distribution Hadoop (CDH) プラグイン 5.13 をサポートするようになりました。
- BZ#1547710
今回の更新で、OpenStack Sahara に s3 互換オブジェクトストアのサポートが追加されました。
今回の更新で、OpenStack Sahara に s3 互換オブジェクトストアのサポートが追加されました。
- BZ#1639759
- BZ#1516911
OvsDpdkMemoryChannels パラメーターは、DPDK パラメーター抽出ワークフローを使用して抽出することができません。デフォルトでは、値は 4 に設定されています。お使いのハードウェアに合わせて、この値をカスタム環境ファイルで変更することができます。
OvsDpdkMemoryChannels パラメーターは、DPDK パラメーター抽出ワークフローを使用して抽出することができません。デフォルトでは、値は 4 に設定されています。お使いのハードウェアに合わせて、この値をカスタム環境ファイルで変更することができます。
openstack-tripleo-heat-templates
- BZ#1594261
今回の更新以前は、/var/lib/nova/instances の共有ストレージ (nfs 等) の場合、任意のコンピュートノードで nova_compute コンテナーを再起動すると、インスタンスの仮想エフェメラルディスクと console.log の所有者/グループが変更されていました。その結果、インスタンスは仮想エフェメラルディスクにアクセスできなくなり、機能しなくなっていました。 今回の更新で、/var/lib/nova/instances 内のインスタンスのファイルの所有権を変更するメソッドが改善され、必要なファイル/ディレクトリーだけを対象とするようになりました。 nova compute の再起動中にインスタンスのファイルへのアクセスが失われなくなりました。
今回の更新以前は、/var/lib/nova/instances の共有ストレージ (nfs 等) の場合、任意のコンピュートノードで nova_compute コンテナーを再起動すると、インスタンスの仮想エフェメラルディスクと console.log の所有者/グループが変更されていました。その結果、インスタンスは仮想エフェメラルディスクにアクセスできなくなり、機能しなくなっていました。
今回の更新で、/var/lib/nova/instances 内のインスタンスのファイルの所有権を変更するメソッドが改善され、必要なファイル/ディレクトリーだけを対象とするようになりました。
nova compute の再起動中にインスタンスのファイルへのアクセスが失われなくなりました。
- BZ#1613847
専用モニターノードのスケールアップやモニターの置き換えによって、stack update コマンドが失敗したり、このコマンドで Ceph モニターがクォーラムから外れたりしなくなりました。
専用モニターノードのスケールアップやモニターの置き換えによって、stack update コマンドが失敗したり、このコマンドで Ceph モニターがクォーラムから外れたりしなくなりました。
- BZ#1637988
instack_undercloud 機能が非推奨になった後、管理者ユーザーがアンダークラウドをアップグレードすると、アクセス権限エラーで失敗していました。これは、管理者ユーザーに member ロールがなかったためです。今回の修正で、member ロールが puppet-keystone モジュールおよび tripleo-teat-templates から管理者ユーザーに戻されました。
instack_undercloud 機能が非推奨になった後、管理者ユーザーがアンダークラウドをアップグレードすると、アクセス権限エラーで失敗していました。これは、管理者ユーザーに member ロールがなかったためです。今回の修正で、member ロールが puppet-keystone モジュールおよび tripleo-teat-templates から管理者ユーザーに戻されました。
- BZ#1652440
ODL の設定されたコントローラーノードを置き換える場合、従来は、再デプロイメント時に ODL の設定ファイルが見つからないため失敗していました。今回の修正で、/opt/opendaylight/data ディレクトリーがホストからアンマウントされ、これがトリガーになって置き換えプロセス時に ODL の設定ファイルが再生成されるようになりました。
ODL の設定されたコントローラーノードを置き換える場合、従来は、再デプロイメント時に ODL の設定ファイルが見つからないため失敗していました。今回の修正で、/opt/opendaylight/data ディレクトリーがホストからアンマウントされ、これがトリガーになって置き換えプロセス時に ODL の設定ファイルが再生成されるようになりました。
- BZ#1655151
従来 OpenStack director は、ソースバランスではなくラウンドロビンを使用して HAProxy ロードバランシングを設定していたため、スティッキーセッションが失敗していました。今回の修正で、director は HAProxy 設定のロードバランシングにソースバランスを使用するようになり、スティッキーセッションが想定どおりに動作するようになりました。
従来 OpenStack director は、ソースバランスではなくラウンドロビンを使用して HAProxy ロードバランシングを設定していたため、スティッキーセッションが失敗していました。今回の修正で、director は HAProxy 設定のロードバランシングにソースバランスを使用するようになり、スティッキーセッションが想定どおりに動作するようになりました。
- BZ#1655184
従来 OpenStack director は、openshift_master_cluster_hostname および openshift_master_cluster_public_hostname パラメーターには必ず IP アドレスを使用していたため、OpenShiftGlobalVariables Heat パラメーターからのホスト名が無視されていました。今回の修正で、director はホスト名が提供されていればホスト名を、提供されていなければ IP アドレスを使用するようになりました。
従来 OpenStack director は、openshift_master_cluster_hostname および openshift_master_cluster_public_hostname パラメーターには必ず IP アドレスを使用していたため、OpenShiftGlobalVariables Heat パラメーターからのホスト名が無視されていました。今回の修正で、director はホスト名が提供されていればホスト名を、提供されていなければ IP アドレスを使用するようになりました。
- BZ#1337770
今回の更新により、ルーティング対応スパイン/リーフ型ネットワークを使用する場合、OSP 14 でそれぞれのロールのノードごとに特定の IP アドレスを設定できるようになりました。 今回の更新以前は、それぞれのノードに特定の IP アドレスを設定できるのは、ルーティング対応スパイン/リーフ型ネットワークを使用しないデプロイメントの場合だけでした。OSP 13 でそれぞれのネットワークに特定の IP アドレスを設定することは可能ですが、ドキュメントおよびテストが不十分だったため、この機能はテクノロジープレビューとして扱われていました。 OSP 14 では、ルーティング対応スパイン/リーフ型ネットワークを使用する場合、それぞれのロールの各ノードのネットワークごとに使用する IP アドレスを選択できるようになりました。これには、同一ネットワーク内のルーティングされた複数サブネットも含まれます。
今回の更新により、ルーティング対応スパイン/リーフ型ネットワークを使用する場合、OSP 14 でそれぞれのロールのノードごとに特定の IP アドレスを設定できるようになりました。
今回の更新以前は、それぞれのノードに特定の IP アドレスを設定できるのは、ルーティング対応スパイン/リーフ型ネットワークを使用しないデプロイメントの場合だけでした。OSP 13 でそれぞれのネットワークに特定の IP アドレスを設定することは可能ですが、ドキュメントおよびテストが不十分だったため、この機能はテクノロジープレビューとして扱われていました。
OSP 14 では、ルーティング対応スパイン/リーフ型ネットワークを使用する場合、それぞれのロールの各ノードのネットワークごとに使用する IP アドレスを選択できるようになりました。これには、同一ネットワーク内のルーティングされた複数サブネットも含まれます。
- BZ#1578849
コンテナー設定およびデプロイメントの失敗を防ぐために、今回の更新で NTP 時刻がデプロイメントプロセスの初期に同期されるようになりました。NTP サーバーにアクセスできず同期できない場合には、デプロイメントは直ちに失敗します。 今回の更新以前は、不明確なエラーメッセージと共にデプロイメントプロセスの遅い段階で失敗していました。
コンテナー設定およびデプロイメントの失敗を防ぐために、今回の更新で NTP 時刻がデプロイメントプロセスの初期に同期されるようになりました。NTP サーバーにアクセスできず同期できない場合には、デプロイメントは直ちに失敗します。
今回の更新以前は、不明確なエラーメッセージと共にデプロイメントプロセスの遅い段階で失敗していました。
- BZ#1580338
- BZ#1613158
- BZ#1617927
- BZ#1623387
今回の更新で、コンテナー化されたアンダークラウドへの切り替え後、アンダークラウドで gnocchiclient を使用できるようになりました。これにより、ユーザーは Telemetry データをクエリーすることができます。
今回の更新で、コンテナー化されたアンダークラウドへの切り替え後、アンダークラウドで gnocchiclient を使用できるようになりました。これにより、ユーザーは Telemetry データをクエリーすることができます。
- BZ#1635864
Ceph ノードに対する設定の更新をブラックリストに登録しても、デプロイメントに失敗しなくなりました。
Ceph ノードに対する設定の更新をブラックリストに登録しても、デプロイメントに失敗しなくなりました。
- BZ#1640021
- BZ#1640443
OpenStack Platform director は、Block Storage サービス (cinder) が nova API の要権限部分にアクセスするのに必要な認証データを設定していませんでした。このため、nova の要権限 API を使用するボリュームでの操作 (例: 使用中のボリュームの移行) に失敗していました。今回の更新で、director が cinder に nova の認証データを設定するようになりました。その結果、権限を必要とするボリュームでの操作が正常に機能するようになりました。
OpenStack Platform director は、Block Storage サービス (cinder) が nova API の要権限部分にアクセスするのに必要な認証データを設定していませんでした。このため、nova の要権限 API を使用するボリュームでの操作 (例: 使用中のボリュームの移行) に失敗していました。今回の更新で、director が cinder に nova の認証データを設定するようになりました。その結果、権限を必要とするボリュームでの操作が正常に機能するようになりました。
- BZ#1652444
- BZ#1241017
今回の更新で、「openstack port list」コマンドの出力にホスト名およびネットワーク名が追加されました。 追加の情報により、Neutron ポートおよび IP アドレスと特定のホストを容易に関連付けられるようになりました。
今回の更新で、「openstack port list」コマンドの出力にホスト名およびネットワーク名が追加されました。
追加の情報により、Neutron ポートおよび IP アドレスと特定のホストを容易に関連付けられるようになりました。
- BZ#1344174
- BZ#1477606
今回の更新で、cinder ボリュームを作成する際に TripleO がデフォルトボリュームタイプ「tripleo」を割り当てるようになりました。今回の更新以前は、ボリュームタイプが設定されていないため、ボリュームのタイプ変更および移行操作時にエラーが発生していました。 CinderDefaultVolumeType パラメーターを上書きして、cinder のボリュームタイプを変更することができます。 注記: cinder のデフォルトボリュームタイプが手動で設定されている場合には (例: TripleO director 以外で設定)、オーバークラウドノードを更新する際に CinderDefaultVolumeType パラメーターを手動で定義した値に設定してください。これにより、デフォルトボリュームタイプの名前がデフォルト値「tripleo」に変更されなくなります。
今回の更新で、cinder ボリュームを作成する際に TripleO がデフォルトボリュームタイプ「tripleo」を割り当てるようになりました。今回の更新以前は、ボリュームタイプが設定されていないため、ボリュームのタイプ変更および移行操作時にエラーが発生していました。
CinderDefaultVolumeType パラメーターを上書きして、cinder のボリュームタイプを変更することができます。
注記: cinder のデフォルトボリュームタイプが手動で設定されている場合には (例: TripleO director 以外で設定)、オーバークラウドノードを更新する際に CinderDefaultVolumeType パラメーターを手動で定義した値に設定してください。これにより、デフォルトボリュームタイプの名前がデフォルト値「tripleo」に変更されなくなります。
- BZ#1579866
今回の変更により、nova_metadata コンテナーで nova-metadata-api が の httpd wsgi 経由で提供されるようになりました。 アップストリームでは、nova-api および nova-metadata-api を含め、すべての WSGI-run サービスについて eventlet の使用を非推奨にする計画です。詳細は、https://review.openstack.org/#/c/549510/ を参照してください。
今回の変更により、nova_metadata コンテナーで nova-metadata-api が の httpd wsgi 経由で提供されるようになりました。
アップストリームでは、nova-api および nova-metadata-api を含め、すべての WSGI-run サービスについて eventlet の使用を非推奨にする計画です。詳細は、https://review.openstack.org/#/c/549510/ を参照してください。
- BZ#1614282
先にインスタンスを移行せずにコンピュートノードがリブートした場合に、コンピュートノード上のインスタンスが自動的に再起動するように設定できるようになりました。Nova および libvirt-guests エージェントを設定して、インスタンスを安全にシャットダウンし、コンピュートノードのリブート時にインスタンスを起動することができます。 新たなパラメーター: NovaResumeGuestsStateOnHostBoot (True/False) NovaResumeGuestsShutdownTimeout (デフォルト: 300 秒)
先にインスタンスを移行せずにコンピュートノードがリブートした場合に、コンピュートノード上のインスタンスが自動的に再起動するように設定できるようになりました。Nova および libvirt-guests エージェントを設定して、インスタンスを安全にシャットダウンし、コンピュートノードのリブート時にインスタンスを起動することができます。
新たなパラメーター:
NovaResumeGuestsStateOnHostBoot (True/False)
NovaResumeGuestsShutdownTimeout (デフォルト: 300 秒)
- BZ#1638922
以前のリリースでは、システムの再起動後に Cinder iSCSI/LVM バックエンドのループバックデバイスが再作成されなかったため、cinder-volume サービスが再起動しませんでした。今回の修正でループバックデバイスを再作成する systemd サービスが追加され、再起動後に Cinder iSCSI/LVM バックエンドが維持されるようになりました。
以前のリリースでは、システムの再起動後に Cinder iSCSI/LVM バックエンドのループバックデバイスが再作成されなかったため、cinder-volume サービスが再起動しませんでした。今回の修正でループバックデバイスを再作成する systemd サービスが追加され、再起動後に Cinder iSCSI/LVM バックエンドが維持されるようになりました。
openvswitch
- BZ#1626488
バケットを持たないグループが原因で、Open vSwitch がデーモンをクラッシュさせていました。今回の更新でコードが変更され、バケットを持たないグループが許容されるようになりました。バケットを持つ/持たないにかかわらず、グループがアサートのトリガーになることが無くなりました。
バケットを持たないグループが原因で、Open vSwitch がデーモンをクラッシュさせていました。今回の更新でコードが変更され、バケットを持たないグループが許容されるようになりました。バケットを持つ/持たないにかかわらず、グループがアサートのトリガーになることが無くなりました。
- BZ#1654371
サービスを再起動すると、内部ポートが別のネットワーク名前空間に移動し、そこで再作成されます。この状況が発生すると、ポートはネットワーク設定を失い、間違ったネットワーク名前空間で再作成されます。今回のリリースでコードが変更され、サービスの再起動時にポートが再作成されなくなり、ポートがネットワーク設定を維持できるようになりました。
サービスを再起動すると、内部ポートが別のネットワーク名前空間に移動し、そこで再作成されます。この状況が発生すると、ポートはネットワーク設定を失い、間違ったネットワーク名前空間で再作成されます。今回のリリースでコードが変更され、サービスの再起動時にポートが再作成されなくなり、ポートがネットワーク設定を維持できるようになりました。
- BZ#1646707
一部の OVS バージョンでは、updelay および downdelay ボンディング設定が無視され、常にデフォルト設定が使用されます。
一部の OVS バージョンでは、updelay および downdelay ボンディング設定が無視され、常にデフォルト設定が使用されます。
puppet-nova
- BZ#1547954
今回のリリースで、Nova の libvirt ドライバーは、CPU モデルの設定時に CPU 機能のフラグをより細かく指定できるようになりました。 「Meltdown」CVE の修正を適用した後に、特定の Intel ベースの仮想 CPU モデルで実行しているゲストのパフォーマンスが低下していました。今回の変更の利点の 1 つは、このパフォーマンス低下が軽減されることです。ゲストのパフォーマンスに対する影響は、CPU 機能フラグ「PCID」(Process-Context ID) を ゲスト CPU に公開することによって軽減されます。これは、物理ハードウェア自体で PCID フラグが利用可能であることを前提とします。 使用方法についての詳しい情報は、nova.conf の [libvirt]/cpu_model_extra_flags の説明を参照してください。
今回のリリースで、Nova の libvirt ドライバーは、CPU モデルの設定時に CPU 機能のフラグをより細かく指定できるようになりました。
「Meltdown」CVE の修正を適用した後に、特定の Intel ベースの仮想 CPU モデルで実行しているゲストのパフォーマンスが低下していました。今回の変更の利点の 1 つは、このパフォーマンス低下が軽減されることです。ゲストのパフォーマンスに対する影響は、CPU 機能フラグ「PCID」(Process-Context ID) を ゲスト CPU に公開することによって軽減されます。これは、物理ハードウェア自体で PCID フラグが利用可能であることを前提とします。
使用方法についての詳しい情報は、nova.conf の [libvirt]/cpu_model_extra_flags の説明を参照してください。
puppet-tripleo
- BZ#1614810
今回の更新で、コンテナー化されたサービスのログローテーションに、デフォルトで logrotate の copytruncate が使用されるようになりました。古いログを保管するデフォルトの期間に変更はありません (14 日間)。
今回の更新で、コンテナー化されたサービスのログローテーションに、デフォルトで logrotate の copytruncate が使用されるようになりました。古いログを保管するデフォルトの期間に変更はありません (14 日間)。
python-amqp
- BZ#1607963
python-networking-ovn
- BZ#1627838
OpenStack TripleO Heat テンプレートの一部のバージョンで、Neutron service_plugins パラメーターに誤った設定が含まれていました。そのため、OVN を使用した場合に Octavia が機能しませんでした。本リリースでは openstack-tripleo-heat-templates-9.0.1-0 パッケージにより OVN がアップグレードされ、Octavia がサポートされるようになりました。
OpenStack TripleO Heat テンプレートの一部のバージョンで、Neutron service_plugins パラメーターに誤った設定が含まれていました。そのため、OVN を使用した場合に Octavia が機能しませんでした。本リリースでは openstack-tripleo-heat-templates-9.0.1-0 パッケージにより OVN がアップグレードされ、Octavia がサポートされるようになりました。
python-oslo-service
- BZ#1642934
以前のリリースでは、eventlet を使用してイベントをスレッド化すると不必要なシステムコールが作成され、REST API のパフォーマンスが低下し、Tempest のタイムアウトエラーが生じていました。今回の修正で REST API コールの応答時間が向上し、Tempest のタイムアウトエラー発生が軽減されるようになりました。
以前のリリースでは、eventlet を使用してイベントをスレッド化すると不必要なシステムコールが作成され、REST API のパフォーマンスが低下し、Tempest のタイムアウトエラーが生じていました。今回の修正で REST API コールの応答時間が向上し、Tempest のタイムアウトエラー発生が軽減されるようになりました。
python-paunch
- BZ#1595733
リブート時のシステムのシャットダウンが不適切なため、コンテナーが停止するのを待たないという問題がありました。今回の更新で、この問題が修正されています。 この問題により、コンテナーは安全に停止する前に強制終了されていました。 今回の更新により新たなサービスが追加され、コンテナーが完全に停止するのを待ってから、システムがリブートプロセスを続行するようになりました。
リブート時のシステムのシャットダウンが不適切なため、コンテナーが停止するのを待たないという問題がありました。今回の更新で、この問題が修正されています。
この問題により、コンテナーは安全に停止する前に強制終了されていました。
今回の更新により新たなサービスが追加され、コンテナーが完全に停止するのを待ってから、システムがリブートプロセスを続行するようになりました。
python-pecan
- BZ#1597622
以前のリリースでは、非管理者ユーザーのアクセス権限を確認するためにポリシーファイルに API リクエストを行うと、再度ファイル全体が読み込まれ解析されていました。そのため処理時間が長くなり、パフォーマンスが低下していました。 今回のバグ修正で、ファイルへのクエリーで再度ファイル全体が読み込まれないように、ポリシーファイルをキャッシュする機能が追加されました。ファイルの変更部分だけが再読み込みされ、再解析されるようになりました。
以前のリリースでは、非管理者ユーザーのアクセス権限を確認するためにポリシーファイルに API リクエストを行うと、再度ファイル全体が読み込まれ解析されていました。そのため処理時間が長くなり、パフォーマンスが低下していました。
今回のバグ修正で、ファイルへのクエリーで再度ファイル全体が読み込まれないように、ポリシーファイルをキャッシュする機能が追加されました。ファイルの変更部分だけが再読み込みされ、再解析されるようになりました。
python-tempestconf
- BZ#1622011
python-tripleoclient
- BZ#1523328
OpenStack director が、オーバークラウドノードのソフトウェア設定に Ansible を使用するようになりました。Ansible によりオーバークラウドのデプロイメントが分りやすく、またデバッグがより簡単になります。Ansible を使用することで、heat とオーバークラウドノード上の heat エージェント (os-collect-config) 間の通信およびソフトウェア設定デプロイメントデータの移動が置き換えられます。 各オーバークラウドノード上で os-collect-config を動作させ heat からデプロイメントデータをポーリングするのに代わって、Ansible のコントロールノードが Ansible インベントリーファイルおよび Playbook とタスクのセットと共に ansible-playbook を実行し、設定を適用します。Ansible のコントロールノード (ansible-playbook を実行するノード) は、デフォルトではアンダークラウドです。
OpenStack director が、オーバークラウドノードのソフトウェア設定に Ansible を使用するようになりました。Ansible によりオーバークラウドのデプロイメントが分りやすく、またデバッグがより簡単になります。Ansible を使用することで、heat とオーバークラウドノード上の heat エージェント (os-collect-config) 間の通信およびソフトウェア設定デプロイメントデータの移動が置き換えられます。
各オーバークラウドノード上で os-collect-config を動作させ heat からデプロイメントデータをポーリングするのに代わって、Ansible のコントロールノードが Ansible インベントリーファイルおよび Playbook とタスクのセットと共に ansible-playbook を実行し、設定を適用します。Ansible のコントロールノード (ansible-playbook を実行するノード) は、デフォルトではアンダークラウドです。
- BZ#1601613
コンテナー化された Ironic サービスに対応するために、--http-boot のデフォルト値が /httpboot から /var/lib/ironic/httpboot に変更されました。
コンテナー化された Ironic サービスに対応するために、--http-boot のデフォルト値が /httpboot から /var/lib/ironic/httpboot に変更されました。
- BZ#1627041
以前のリリースでは、IPMI bootdev コマンドを送信すると、一部のハードウェアでブートデバイスの順序が意図せず変わっていました。そのため、一部のノードが正しい NIC から起動しなくなったり、PXE がどの場所からも起動しなくなったりしていました。 本リリースで、IPMI ドライバーに noop 管理インターフェースが追加されました。このインターフェースがブートコマンドを処理し、bootdev が使用されないようにします。noop インターフェースを準備するには、正しい NIC から PXE ブートモードを試みるようにノードを事前設定し、その後ローカルのハードドライブにフォールバックする必要があります。
以前のリリースでは、IPMI bootdev コマンドを送信すると、一部のハードウェアでブートデバイスの順序が意図せず変わっていました。そのため、一部のノードが正しい NIC から起動しなくなったり、PXE がどの場所からも起動しなくなったりしていました。
本リリースで、IPMI ドライバーに noop 管理インターフェースが追加されました。このインターフェースがブートコマンドを処理し、bootdev が使用されないようにします。noop インターフェースを準備するには、正しい NIC から PXE ブートモードを試みるようにノードを事前設定し、その後ローカルのハードドライブにフォールバックする必要があります。
python-virtualbmc
- BZ#1610505
今回の更新で、デバッグモードを有効にして応答をレンダリングするとサーバークラッシュを起こすデバッグメッセージの補完に関するバグが修正されています。
今回の更新で、デバッグモードを有効にして応答をレンダリングするとサーバークラッシュを起こすデバッグメッセージの補完に関するバグが修正されています。
- BZ#1624411
パッケージのインストール中、virtualbmc パッケージの RPM 仕様のバグのために、virtualbmc サービスを実行する特殊ユーザーまたはグループが作成されませんでした。今回の更新で RPM の仕様が修正され、ユーザー管理操作が正しく実施されるようになりました。パッケージがインストールされると、virtualbmc サービスが正常に開始されます。
パッケージのインストール中、virtualbmc パッケージの RPM 仕様のバグのために、virtualbmc サービスを実行する特殊ユーザーまたはグループが作成されませんでした。今回の更新で RPM の仕様が修正され、ユーザー管理操作が正しく実施されるようになりました。パッケージがインストールされると、virtualbmc サービスが正常に開始されます。
- BZ#1642466
VirtualBMC (VBMC) はサポートされなくなったので、本番環境では使用しないでください。テストの目的であれば、pip を使用して直接 VBMC をインストールすることができます。
VirtualBMC (VBMC) はサポートされなくなったので、本番環境では使用しないでください。テストの目的であれば、pip を使用して直接 VBMC をインストールすることができます。