第4章 テクニカルノート

今回の更新では、LBaaS ダッシュボードが Horizon から移動して、別個のプラグインとなりました。
そのため、LBaaS ダッシュボードは「yum install neutron-lbaas-ui」でインストールできるようになりました。この変更を適用するには、httpd を再起動する必要があります。

今回の更新では、LBaaS ダッシュボードが Horizon から移動して、別個のプラグインとなりました。
そのため、LBaaS ダッシュボードは「yum install neutron-lbaas-ui」でインストールできるようになりました。この変更を適用するには、httpd を再起動する必要があります。

今回のリリースには、keycloak-httpd-client-install パッケージのテクノロジープレビュー版が同梱されています。このパッケージは、Apache mod_auth_mellon SAML Service Provider を Keycloak SAML IdP のクライアントとして設定するのに役立つコマンドラインツールを提供します。

今回のリリースには、keycloak-httpd-client-install パッケージのテクノロジープレビュー版が同梱されています。このパッケージは、Apache mod_auth_mellon SAML Service Provider を Keycloak SAML IdP のクライアントとして設定するのに役立つコマンドラインツールを提供します。

以前のリリースでは、「mariadb-galera」の RPM に、Galera の SSL 通信で使用するための TLS 証明書を生成するステップが含まれていましたが、インストールした RPM をコンテナーで使用して、そのコンテナーがレプリケートされると、TLS 証明書自体もレプリケートされていたため、元の TLS 証明書と全く同じ証明書がコンテナーのコピーに含まれてしまい、その証明書が実際に使用された場合にはセキュリティー上の問題が発生していました。
今回の更新では、RPM パッケージは、この証明書を生成しなくなりました。
その結果、コンテナーに含まれてしまう可能性のある証明書は生成されなくなりました。証明書は、Galera の SSL 設定で必要とされている場合に、手動で生成することができます。Red Hat OpenStack director は現在 Galera を SSL には設定しない点に注意してください。

以前のリリースでは、「mariadb-galera」の RPM に、Galera の SSL 通信で使用するための TLS 証明書を生成するステップが含まれていましたが、インストールした RPM をコンテナーで使用して、そのコンテナーがレプリケートされると、TLS 証明書自体もレプリケートされていたため、元の TLS 証明書と全く同じ証明書がコンテナーのコピーに含まれてしまい、その証明書が実際に使用された場合にはセキュリティー上の問題が発生していました。
今回の更新では、RPM パッケージは、この証明書を生成しなくなりました。
その結果、コンテナーに含まれてしまう可能性のある証明書は生成されなくなりました。証明書は、Galera の SSL 設定で必要とされている場合に、手動で生成することができます。Red Hat OpenStack director は現在 Galera を SSL には設定しない点に注意してください。

今回のリリースでは、OpenDaylight Beryllium SR2 がテクノロジープレビューとして提供されるようになりました。

今回のリリースでは、OpenDaylight Beryllium SR2 がテクノロジープレビューとして提供されるようになりました。

今回リベースされたパッケージの openstack-aodh-2.0.1-3.el7ost バージョンには、aodh の更新が含まれています。
変更事項の全一覧は、http://docs.openstack.org/releasenotes/aodh/mitaka.html#id2 でアップストリームのリリースノートを参照してください。

今回リベースされたパッケージの openstack-aodh-2.0.1-3.el7ost バージョンには、aodh の更新が含まれています。
変更事項の全一覧は、http://docs.openstack.org/releasenotes/aodh/mitaka.html#id2 でアップストリームのリリースノートを参照してください。

今回の更新により、Aodh API 用のクライアントが提供されるようになりました。このクライアントは、「aodhclient」で提供されている Python API と、「aodh」コマンドとしてインストールされるコマンドラインスクリプトで構成されます。Python API とコマンドラインスクリプトの両方で、Aodh API 全体が実装されます。

今回の更新により、Aodh API 用のクライアントが提供されるようになりました。このクライアントは、「aodhclient」で提供されている Python API と、「aodh」コマンドとしてインストールされるコマンドラインスクリプトで構成されます。Python API とコマンドラインスクリプトの両方で、Aodh API 全体が実装されます。

今回リベースされた aodh パッケージの openstack-aodh-2.0.1-1.el7ost バージョンには、重要な修正が含まれています。

* Bug 1575530: この更新で、パーティションコーディネーターの機能が修正および改善され、入力タスクがパーティションメンバー間で正しく分散されるようになりました。

今回リベースされた aodh パッケージの openstack-aodh-2.0.1-1.el7ost バージョンには、重要な修正が含まれています。

* Bug 1575530: この更新で、パーティションコーディネーターの機能が修正および改善され、入力タスクがパーティションメンバー間で正しく分散されるようになりました。

以前のリリースでは、「gnocchi_aggregation_by_metrics_threshold」の種別のアラームの作成時にエバリュエーターがエラーをスローして例外が発生していました。
今回の更新では、「needed_overlap」が常にアグリゲーションに適用されるように設定することでこの問題に対処しています。

以前のリリースでは、「gnocchi_aggregation_by_metrics_threshold」の種別のアラームの作成時にエバリュエーターがエラーをスローして例外が発生していました。
今回の更新では、「needed_overlap」が常にアグリゲーションに適用されるように設定することでこの問題に対処しています。

今回の更新の前には、複合アラームは、リフレッシュする度に通知を送信し続けていました。このため、ログファイルに不要な通知が記録されていました。
今回の更新では、アラームをリフレッシュする度に通知が送られないようにすることでこの問題に対処しています。

今回の更新の前には、複合アラームは、リフレッシュする度に通知を送信し続けていました。このため、ログファイルに不要な通知が記録されていました。
今回の更新では、アラームをリフレッシュする度に通知が送られないようにすることでこの問題に対処しています。

以前のリリースでは、gnocchi-dispatcher のオプションは、デフォルトでは「ceilometer.conf」に記載されていなかったので、手動で追加する必要がありました。今回の更新では、ceilometer をインストールすると、gnocchi-dispatcher オプションがデフォルトで含まれるようになりました。

以前のリリースでは、gnocchi-dispatcher のオプションは、デフォルトでは「ceilometer.conf」に記載されていなかったので、手動で追加する必要がありました。今回の更新では、ceilometer をインストールすると、gnocchi-dispatcher オプションがデフォルトで含まれるようになりました。

今回の更新の前には、時間ベースのフィールドではイベントをフィルタリングすることはできませんでした。
そのため、「le」および「ge」クエリーは時間ベースのフィールドでは機能しませんでした。
今回の更新で新たなクエリー演算子が追加された結果、「le」および「ge」の演算子は時間ベースのクエリーで機能するようになりました。

今回の更新の前には、時間ベースのフィールドではイベントをフィルタリングすることはできませんでした。
そのため、「le」および「ge」クエリーは時間ベースのフィールドでは機能しませんでした。
今回の更新で新たなクエリー演算子が追加された結果、「le」および「ge」の演算子は時間ベースのクエリーで機能するようになりました。

Telemetry (ceilometer) dbsync は、「sqlalchemy-migrate」コードを引き続き実行しているために、古いアラームテーブルを作成します。このため、Aodh dbsync は Alembic への参照を確認できず、SQLAlchemy に必要なテーブルを作成するように要求しますが、それらのテーブルはすでに存在しているので、何も操作は行われず、データベースには Aodh Alembic の最新バージョンがスタンプされます。
この問題を回避するには、ceilometer dbsync でアラームテーブルを作成しないようにしてください。

Telemetry (ceilometer) dbsync は、「sqlalchemy-migrate」コードを引き続き実行しているために、古いアラームテーブルを作成します。このため、Aodh dbsync は Alembic への参照を確認できず、SQLAlchemy に必要なテーブルを作成するように要求しますが、それらのテーブルはすでに存在しているので、何も操作は行われず、データベースには Aodh Alembic の最新バージョンがスタンプされます。
この問題を回避するには、ceilometer dbsync でアラームテーブルを作成しないようにしてください。

今回の更新で、Google Cloud バックアップドライバーに必要な python ライブラリーがあることを確認する RPM 要件が追加されました。

今回の更新で、Google Cloud バックアップドライバーに必要な python ライブラリーがあることを確認する RPM 要件が追加されました。

以前のリリースでは、python-taskflow は適切なバージョンの python-networkx に対する依存関係がありませんでした。
そのため、「cinder create volume」が想定通りに機能しませんでした。
今回の更新で、python-taskflow パッケージに正しい依存関係が設定され、「cinder create volume」は想定通りに機能するようになりました。

以前のリリースでは、python-taskflow は適切なバージョンの python-networkx に対する依存関係がありませんでした。
そのため、「cinder create volume」が想定通りに機能しませんでした。
今回の更新で、python-taskflow パッケージに正しい依存関係が設定され、「cinder create volume」は想定通りに機能するようになりました。

今回リベースされた openstack-gnocchi パッケージの openstack-gnocchi-2.1.1-1.el7ost バージョンにより、重要な更新が追加されました。
詳しい情報は、https://launchpad.net/gnocchi/+milestone/2.1.1 でアップストリームのリリースマイルストーンを参照してください。

今回リベースされた openstack-gnocchi パッケージの openstack-gnocchi-2.1.1-1.el7ost バージョンにより、重要な更新が追加されました。
詳しい情報は、https://launchpad.net/gnocchi/+milestone/2.1.1 でアップストリームのリリースマイルストーンを参照してください。

複数の環境ファイルが指定されている場合には、クライアントの代わりにエンジンで統合されます。これにより、Heat がスタックを正しくオーケストレーションするのに十分な情報が提供されます。

複数の環境ファイルが指定されている場合には、クライアントの代わりにエンジンで統合されます。これにより、Heat がスタックを正しくオーケストレーションするのに十分な情報が提供されます。

ユーザーは、環境内でリソースレジストリーを使用することで、リソースに対する削除の操作を一時停止するフックを設定することができます。これにより、ユーザーはリソースの削除時に特定の操作を行って、重要な要素が削除される場合には追加の検証を実行することができます。その結果、pre-delete フックが設定されたリソースが削除される際には、そのリソースが {'unset_hook': 'pre-delete'} でデータとしてシグナルされるまで Heat は操作を一時停止します。

ユーザーは、環境内でリソースレジストリーを使用することで、リソースに対する削除の操作を一時停止するフックを設定することができます。これにより、ユーザーはリソースの削除時に特定の操作を行って、重要な要素が削除される場合には追加の検証を実行することができます。その結果、pre-delete フックが設定されたリソースが削除される際には、そのリソースが {'unset_hook': 'pre-delete'} でデータとしてシグナルされるまで Heat は操作を一時停止します。

以前のリリースでは、iPXE ドライバーに条件があり、ノードを UEFI ブートモードで設定できませんでした。そのため、iPXE ドライバーのユーザーは、ノードを UEFI に設定できず、代わりに BIOS を使わざるを得ませんでした。
今回の更新により、この条件は削除され、iPXE ドライバーのユーザーは UEFI モードでノードをデプロイできるようになりました。

以前のリリースでは、iPXE ドライバーに条件があり、ノードを UEFI ブートモードで設定できませんでした。そのため、iPXE ドライバーのユーザーは、ノードを UEFI に設定できず、代わりに BIOS を使わざるを得ませんでした。
今回の更新により、この条件は削除され、iPXE ドライバーのユーザーは UEFI モードでノードをデプロイできるようになりました。

今回の機能拡張により、手動のクリーニングが追加され、オペレーターはノードを管理可能な状態から直接クリーニングモードに切り替えることができるようになりました。
この機能は、オペレーターが RAID のビルドやデバイスの消去などのさまざまな理由でクリーニングステップを実行できるように追加されました。
その結果、オペレーターは、OpenStack Bare Metal (ironic) API を使用して、実行する必要のあるステップを具体的に選択した上で ironic ノードのクリーニングプロセスを手動で開始することができます。

今回の機能拡張により、手動のクリーニングが追加され、オペレーターはノードを管理可能な状態から直接クリーニングモードに切り替えることができるようになりました。
この機能は、オペレーターが RAID のビルドやデバイスの消去などのさまざまな理由でクリーニングステップを実行できるように追加されました。
その結果、オペレーターは、OpenStack Bare Metal (ironic) API を使用して、実行する必要のあるステップを具体的に選択した上で ironic ノードのクリーニングプロセスを手動で開始することができます。

今回の機能拡張で、iSCSI ドライバーのインバンドクリーニングがサポートされるようになりました。iSCSI ドライバーを使用して、ディスクの消去やインバンド RAID 設定などのクリーニングステップをノードで実行することができます。
クリーニングステップを実行することにより、ironic でノードをリサイクルする際にセキュリティーが強化され、以前のテナントからの全データを消去したり、マシンのセキュリティーが侵害されていないかどうかをチェックしたりすることができます。
その結果、pxe_ipmitool、pxe_drac、pxe_iboot、pxe_ilo、pxe_amt、pxe_wol、その他のドライバーでインバンドクリーニングステップを実行することができるようになりました。

今回の機能拡張で、iSCSI ドライバーのインバンドクリーニングがサポートされるようになりました。iSCSI ドライバーを使用して、ディスクの消去やインバンド RAID 設定などのクリーニングステップをノードで実行することができます。
クリーニングステップを実行することにより、ironic でノードをリサイクルする際にセキュリティーが強化され、以前のテナントからの全データを消去したり、マシンのセキュリティーが侵害されていないかどうかをチェックしたりすることができます。
その結果、pxe_ipmitool、pxe_drac、pxe_iboot、pxe_ilo、pxe_amt、pxe_wol、その他のドライバーでインバンドクリーニングステップを実行することができるようになりました。

以前のリリースでは、「ipset」は Open vSwitch (OVS) および Linux Bridge neutron エージェントの依存関係として宣言されていませんでしたが、ipset は openstack-neutron パッケージの依存関係であるため、ノードで Open vSwitch または Linux Bridge エージェントのパッケージがインストールされても「openstack-neutron」はインストールされませんでした。ipset は、L2 エージェントのセキュリティーグループ設定に必要です。
今回の更新で ipset は openstack-openvswitch-agent の依存関係となり、openstack-linuxbridge-agent パッケージは ipset に依存するようになりました。

以前のリリースでは、「ipset」は Open vSwitch (OVS) および Linux Bridge neutron エージェントの依存関係として宣言されていませんでしたが、ipset は openstack-neutron パッケージの依存関係であるため、ノードで Open vSwitch または Linux Bridge エージェントのパッケージがインストールされても「openstack-neutron」はインストールされませんでした。ipset は、L2 エージェントのセキュリティーグループ設定に必要です。
今回の更新で ipset は openstack-openvswitch-agent の依存関係となり、openstack-linuxbridge-agent パッケージは ipset に依存するようになりました。

以前のリリースでは、openstack-neutron-common パッケージには shadow-utils パッケージは必要ありませんでした。このため、openstack-neutron-common パッケージのインストール時に「neutron」ユーザーが作成されず、neutron はハイパーバイザー上でコマンドを実行できませんでした。今回の更新により、openstack-neutron-common パッケージには shadow-utils パッケージが必須となり、「neutron」ユーザーが正しく作成されるようになりました。

以前のリリースでは、openstack-neutron-common パッケージには shadow-utils パッケージは必要ありませんでした。このため、openstack-neutron-common パッケージのインストール時に「neutron」ユーザーが作成されず、neutron はハイパーバイザー上でコマンドを実行できませんでした。今回の更新により、openstack-neutron-common パッケージには shadow-utils パッケージが必須となり、「neutron」ユーザーが正しく作成されるようになりました。

以前のリリースでは、エージェントの起動時に br-int および br-tun 用のブリッジポートがない場合には、「int-br-ex」および「phy-br-ex」のパッチポートがあるかどうかをチェックしてからそれらのブリッジを追加していましたが、ポートの有無のチェックに使用されていた get_port_ofport() の関数は、@_ofport_retry デコレーションが原因でチェックを再試行していました。
そのため、再起動に余分な時間がかかっていました。
今回の更新により、ポートの有無は get_port_ofport() の代わりに port_exists() でチェックされるようになったので、br-int および br-tun 用のブリッジポートがない場合にも起動が遅くなることはなくなりました。

以前のリリースでは、エージェントの起動時に br-int および br-tun 用のブリッジポートがない場合には、「int-br-ex」および「phy-br-ex」のパッチポートがあるかどうかをチェックしてからそれらのブリッジを追加していましたが、ポートの有無のチェックに使用されていた get_port_ofport() の関数は、@_ofport_retry デコレーションが原因でチェックを再試行していました。
そのため、再起動に余分な時間がかかっていました。
今回の更新により、ポートの有無は get_port_ofport() の代わりに port_exists() でチェックされるようになったので、br-int および br-tun 用のブリッジポートがない場合にも起動が遅くなることはなくなりました。

今回の更新により、openstack-nova パッケージはアップストリームのバージョン 13.1.0 にリベースされました。

今回の更新により、openstack-nova パッケージはアップストリームのバージョン 13.1.0 にリベースされました。

以前のリリースでは、インスタンスのブート時に、セキュリティーグループが指定されていなかった場合には、nova API がデフォルトのセキュリティーグループを自動的に追加していました。この操作は、オプションが 「port_security_enabled=False」に指定されているネットワークには実行されるべきではありません。
そのため、ポートセキュリティーが無効になっているネットワークに接続されたインスタンスをユーザーが起動しようとすると、ブートプロセスが失敗していました。
今回の更新により、nova は port_security_enabled=False に設定されたネットワーク上のインスタンス用に作成されたポートには、デフォルトのセキュリティーグループを追加しなくなりました。
その結果、ブートプロセスは想定通りに機能するようになり、インスタンスにアタッチされるポートにはデフォルトのセキュリティーグループはアタッチされなくなりました。

注記: Dashboard の既知のバグが原因で、デフォルトのセキュリティーグループがインスタンスにアタッチされているように表示されますが、これはインスタンスの起動を初めて試みた時にだけに生じる問題です。

以前のリリースでは、インスタンスのブート時に、セキュリティーグループが指定されていなかった場合には、nova API がデフォルトのセキュリティーグループを自動的に追加していました。この操作は、オプションが 「port_security_enabled=False」に指定されているネットワークには実行されるべきではありません。
そのため、ポートセキュリティーが無効になっているネットワークに接続されたインスタンスをユーザーが起動しようとすると、ブートプロセスが失敗していました。
今回の更新により、nova は port_security_enabled=False に設定されたネットワーク上のインスタンス用に作成されたポートには、デフォルトのセキュリティーグループを追加しなくなりました。
その結果、ブートプロセスは想定通りに機能するようになり、インスタンスにアタッチされるポートにはデフォルトのセキュリティーグループはアタッチされなくなりました。

注記: Dashboard の既知のバグが原因で、デフォルトのセキュリティーグループがインスタンスにアタッチされているように表示されますが、これはインスタンスの起動を初めて試みた時にだけに生じる問題です。

serial_console が有効化されている場合には、インスタンスの起動と停止を繰り返すと、最終的には Compute サービスでポートが足りなくなります。この問題が起こると、インスタンスの起動を試みた時に「SocketPortRangeExhaustedException」エラーが発生して、インスタンスは起動できなくなります。これは、Compute サービスがインスタンスの作成時ではなく起動時にポートを作成し、また、インスタンスの停止時ではなく削除時にだけポートを解放することが原因です。

今回の更新では、libvirt の視点からゲストを破棄する方法でシリアルポートも解放されるようになりました。これにより、シリアルポートはインスタンスが必要としなくなるとすぐに解放されるので、そのポートは再度利用できるようになります。

serial_console が有効化されている場合には、インスタンスの起動と停止を繰り返すと、最終的には Compute サービスでポートが足りなくなります。この問題が起こると、インスタンスの起動を試みた時に「SocketPortRangeExhaustedException」エラーが発生して、インスタンスは起動できなくなります。これは、Compute サービスがインスタンスの作成時ではなく起動時にポートを作成し、また、インスタンスの停止時ではなく削除時にだけポートを解放することが原因です。

今回の更新では、libvirt の視点からゲストを破棄する方法でシリアルポートも解放されるようになりました。これにより、シリアルポートはインスタンスが必要としなくなるとすぐに解放されるので、そのポートは再度利用できるようになります。

スナップショットの作成時に Compute API は、イメージ API 要求からディスクおよびコンテナーの形式についての情報を省略するようになりました。これで、ドライバーは正しいスナップショットイメージの形式を使用することになります。また、これにより、ベースイメージが使用しているのとは異なる形式に変換された場合にスナップショットが BadRequest で失敗しないようになりました。

スナップショットの作成時に Compute API は、イメージ API 要求からディスクおよびコンテナーの形式についての情報を省略するようになりました。これで、ドライバーは正しいスナップショットイメージの形式を使用することになります。また、これにより、ベースイメージが使用しているのとは異なる形式に変換された場合にスナップショットが BadRequest で失敗しないようになりました。

以前のリリースでは、BZ#1332599 に報告されているように、ハードリブートの後にインスタンスはシリアルポートを失うという問題の再発が発見されていました。そのため、シリアルコンソールでインスタンスを接続するのは不可能でした。この問題は、ホスト上のシリアルポートは解放されているのに、ドメイン XML がそれらのポートを定義しているままの状態で、ブート中にホストでポートを取得するプロセスが実行されなかったことが原因となって、ハードリブートプロセス中に発生していました。
この問題に対処するために、nova はドメインを破棄した後に libvirt からそのドメインの定義を解除するようになりました。

以前のリリースでは、BZ#1332599 に報告されているように、ハードリブートの後にインスタンスはシリアルポートを失うという問題の再発が発見されていました。そのため、シリアルコンソールでインスタンスを接続するのは不可能でした。この問題は、ホスト上のシリアルポートは解放されているのに、ドメイン XML がそれらのポートを定義しているままの状態で、ブート中にホストでポートを取得するプロセスが実行されなかったことが原因となって、ハードリブートプロセス中に発生していました。
この問題に対処するために、nova はドメインを破棄した後に libvirt からそのドメインの定義を解除するようになりました。

SR-IOV の Virtual Function (VF) デバイスをインスタンスに割り当てる際に、対応する Physical Function (PF) デバイスは、データベースで利用不可として正しくマスキングされますが、以前のリリースでは、インスタンスを削除しても PF が利用可能な状態に更新されませんでした。その結果、インスタンスが削除された後に、そのインスタンスが使用していた PCI デバイスはデータベースから全く解放されませでした。

今回の更新により、nova は PCI デバイスのインメモリーツリーを維持管理して、その情報を定期的にデータベースにフラッシュするようになりました。これは、利用可能なデバイスに関するデータベースの情報を更新するのに役立ちます。

SR-IOV の Virtual Function (VF) デバイスをインスタンスに割り当てる際に、対応する Physical Function (PF) デバイスは、データベースで利用不可として正しくマスキングされますが、以前のリリースでは、インスタンスを削除しても PF が利用可能な状態に更新されませんでした。その結果、インスタンスが削除された後に、そのインスタンスが使用していた PCI デバイスはデータベースから全く解放されませでした。

今回の更新により、nova は PCI デバイスのインメモリーツリーを維持管理して、その情報を定期的にデータベースにフラッシュするようになりました。これは、利用可能なデバイスに関するデータベースの情報を更新するのに役立ちます。

以前のリリースでは、openstack-nova-compute 用の systemd ユニットファイルが libvirtd の必要な依存関係に含まれていませんでした。そのため、libvirtd が実行済みでない場合に openstack-nova-compute を再起動すると操作が失敗していました。今回の更新で依存関係が追加されました。

以前のリリースでは、openstack-nova-compute 用の systemd ユニットファイルが libvirtd の必要な依存関係に含まれていませんでした。そのため、libvirtd が実行済みでない場合に openstack-nova-compute を再起動すると操作が失敗していました。今回の更新で依存関係が追加されました。

今回の機能拡張により、CPU が固定されているインスタンスを退避すると、すでに同じピニング設定のインスタンスを処理しているハイパーバイザーでホストされるようになりました。
この機能は、リソーストラッカーではホスト上の CPU ピニングがトラッキングされないために追加されました。
その結果、NUMATopologyFilter フィルターには、退避させるインスタンスと同じ CPU ピニング設定のインスタンスをすでに管理するホストを渡すという条件が追加されました。

今回の機能拡張により、CPU が固定されているインスタンスを退避すると、すでに同じピニング設定のインスタンスを処理しているハイパーバイザーでホストされるようになりました。
この機能は、リソーストラッカーではホスト上の CPU ピニングがトラッキングされないために追加されました。
その結果、NUMATopologyFilter フィルターには、退避させるインスタンスと同じ CPU ピニング設定のインスタンスをすでに管理するホストを渡すという条件が追加されました。

以前のリリースでは、ceilometer のインストールが無効になっている場合に、Packstack は gnocchi データベースの作成を試みました。その際に、gnocchi データベースの作成に必要なパラメーターの一部が渡されなかったため、ceilometer を無効にすると Packstack のインストールが失敗していました。今回のリリースでは、Packstack は ceilometer が無効な場合でも、gnocchi データベースの作成を試みなくなりました。

以前のリリースでは、ceilometer のインストールが無効になっている場合に、Packstack は gnocchi データベースの作成を試みました。その際に、gnocchi データベースの作成に必要なパラメーターの一部が渡されなかったため、ceilometer を無効にすると Packstack のインストールが失敗していました。今回のリリースでは、Packstack は ceilometer が無効な場合でも、gnocchi データベースの作成を試みなくなりました。

以前のリリースでは、HTTP ダウンロード中に iPXE がフリーズして、Bare Metal Provisioning (ironic) サービスがハングしていました。

今回の更新では、エラーが発生した場合に iPXE がネットワークからブートを再試行するようになりました。「--timeout」オプションを使用して、フリーズが無限に続かないようにすることができ、HTTP ダウンロード中にはフリーズが発生しなくなりました。

以前のリリースでは、HTTP ダウンロード中に iPXE がフリーズして、Bare Metal Provisioning (ironic) サービスがハングしていました。

今回の更新では、エラーが発生した場合に iPXE がネットワークからブートを再試行するようになりました。「--timeout」オプションを使用して、フリーズが無限に続かないようにすることができ、HTTP ダウンロード中にはフリーズが発生しなくなりました。

VPNaaS および LBaaS の設定を行うサービスプロバイダーは、サービスの起動には決して含まれないファイルを追加で作成していました。このため、LBaaS が有効化されている場合には、neutron-server が起動できませんでした。

以前のリリースでは、サービスプロバイダーが直接 /etc/neutron/neutron.conf に追加されるように LBaaS サービス設定プロバイダーが更新されましたが、これと同じように動作するように VPNaaS を更新しても、LBaaS によって設定された「service_provider」の値が上書きされてしまいました。また、逆の場合も、VPNaaS によって設定された「service_provider」の値は LBaaS により上書きされてしまいました。この問題に対処するために、今回の更新では「neutron_config」プロバイダーを ini_setting から openstackconfig に移動して、サービスプロバイダーを管理するための変数を neutron::server に追加しました。これにより、VPNaaS および LBaaS がお互いの「service_provider」の値を上書きしないようになり、LBaaS を有効にしても neutron-server の起動は妨げられなくなりました。

VPNaaS および LBaaS の設定を行うサービスプロバイダーは、サービスの起動には決して含まれないファイルを追加で作成していました。このため、LBaaS が有効化されている場合には、neutron-server が起動できませんでした。

以前のリリースでは、サービスプロバイダーが直接 /etc/neutron/neutron.conf に追加されるように LBaaS サービス設定プロバイダーが更新されましたが、これと同じように動作するように VPNaaS を更新しても、LBaaS によって設定された「service_provider」の値が上書きされてしまいました。また、逆の場合も、VPNaaS によって設定された「service_provider」の値は LBaaS により上書きされてしまいました。この問題に対処するために、今回の更新では「neutron_config」プロバイダーを ini_setting から openstackconfig に移動して、サービスプロバイダーを管理するための変数を neutron::server に追加しました。これにより、VPNaaS および LBaaS がお互いの「service_provider」の値を上書きしないようになり、LBaaS を有効にしても neutron-server の起動は妨げられなくなりました。

Ceph の puppet モジュール (puppet-ceph) では、key の caps パラメーターの変更時に、CephX キーリングが更新されませんでした。そのため、新しい「メトリック」のプールで動作する caps が CephX キーリングに追加されなかったので、オーバークラウドのアップグレードに失敗しました。

今回の更新では、「rbd_keyring」または「linvirt_rbd_secret_uuid」のいずれかが変更された場合に、puppet-ceph が virsh のシークレットを再生成するか、そのキーを更新するようになりました。これにより、シークレットまたは caps の変更時には CephX キーリングが必要に応じて更新されます。

Ceph の puppet モジュール (puppet-ceph) では、key の caps パラメーターの変更時に、CephX キーリングが更新されませんでした。そのため、新しい「メトリック」のプールで動作する caps が CephX キーリングに追加されなかったので、オーバークラウドのアップグレードに失敗しました。

今回の更新では、「rbd_keyring」または「linvirt_rbd_secret_uuid」のいずれかが変更された場合に、puppet-ceph が virsh のシークレットを再生成するか、そのキーを更新するようになりました。これにより、シークレットまたは caps の変更時には CephX キーリングが必要に応じて更新されます。

以前のリリースでは、Compute API が Apache を使用して WSGI で起動できるようにするための SELinux ポリシーが設定されていない場合には、audit.log に AVC が記録されていました。

今回の更新で、Compute は HTTP のポートとボンディングできるようになり、Apache を使用して WSGI で起動する際にエラーが発生することなく実行できるようになりました。

以前のリリースでは、Compute API が Apache を使用して WSGI で起動できるようにするための SELinux ポリシーが設定されていない場合には、audit.log に AVC が記録されていました。

今回の更新で、Compute は HTTP のポートとボンディングできるようになり、Apache を使用して WSGI で起動する際にエラーが発生することなく実行できるようになりました。

以前のリリースでは、Apache を使用して WSGI で Block Storage API を実行する際に、SELinux が「enforce」モードの場合には、AVC がログ記録され、SELinux は「/usr/sbin/httpd」が「/var/log/cinder/cinder-api.log」ファイルへのアクセスを妨げていました。

今回の更新により、「httpd」は Block Storage API ログファイルへのアクセスが許可されるようになりました。その結果、WSGI で Block Storage API は AVC がログ記録されることなく実行できるようになりました。

以前のリリースでは、Apache を使用して WSGI で Block Storage API を実行する際に、SELinux が「enforce」モードの場合には、AVC がログ記録され、SELinux は「/usr/sbin/httpd」が「/var/log/cinder/cinder-api.log」ファイルへのアクセスを妨げていました。

今回の更新により、「httpd」は Block Storage API ログファイルへのアクセスが許可されるようになりました。その結果、WSGI で Block Storage API は AVC がログ記録されることなく実行できるようになりました。

今回の機能拡張により、レプリカの配置が改善され、割り当てが重複しないように保護されるようになりました。
この機能は、従来の Swift レイアウトでは、単一のパーティションの 2 つのレプリカを同じデバイスに間違って割り当てると、耐久性が暗黙のうちに損なわれていたために追加されました。
その結果、割り当ての重複は防がれるようになり、計算済みの耐久性保証が守られるようになりました。ただし、そのためにはデバイスの数がレプリカの数よりも少なくならないようにする必要があるため、特定の誤った古いリングを無効と見なすことができるので、レプリカの数よりもゾーン数を少なくすることが引き続き可能です。

今回の機能拡張により、レプリカの配置が改善され、割り当てが重複しないように保護されるようになりました。
この機能は、従来の Swift レイアウトでは、単一のパーティションの 2 つのレプリカを同じデバイスに間違って割り当てると、耐久性が暗黙のうちに損なわれていたために追加されました。
その結果、割り当ての重複は防がれるようになり、計算済みの耐久性保証が守られるようになりました。ただし、そのためにはデバイスの数がレプリカの数よりも少なくならないようにする必要があるため、特定の誤った古いリングを無効と見なすことができるので、レプリカの数よりもゾーン数を少なくすることが引き続き可能です。

今回の機能拡張により、コンテナーまたはアカウントサーバーにオブジェクトのリストを逆の順序にするように指示する機能が追加されました。この機能により、ミドルウェア内のバージョン付きのオブジェクトを特定することができます。
その結果、内部のアーキテクチャーが安全上の理由で再編成されるのに加えて、必要な場合にはクライアントアプリケーションに逆順のリストを提供できます。

今回の機能拡張により、コンテナーまたはアカウントサーバーにオブジェクトのリストを逆の順序にするように指示する機能が追加されました。この機能により、ミドルウェア内のバージョン付きのオブジェクトを特定することができます。
その結果、内部のアーキテクチャーが安全上の理由で再編成されるのに加えて、必要な場合にはクライアントアプリケーションに逆順のリストを提供できます。

以前のリリースでは、「gnocchi-resource-threshold」の種別で作成したアラームには、「project_id」と「user_id」用のフィールドが空欄でした

今回の更新では、「gnocchi-resource-threshold」の種別のアラームの「project_id」と「user_id」のフィールドには、データが自動的に設定されるようになりました。

以前のリリースでは、「gnocchi-resource-threshold」の種別で作成したアラームには、「project_id」と「user_id」用のフィールドが空欄でした

今回の更新では、「gnocchi-resource-threshold」の種別のアラームの「project_id」と「user_id」のフィールドには、データが自動的に設定されるようになりました。

Red Hat OpenStack Platform 9 に python-colorama パッケージが追加されました。
このパッケージは、ptyhon-gabbi のインストールの依存関係にあり、同様にopenstack-gnocchi には ptyhon-gabbi が必要です。
その結果、openstack-gnocchi と python-gabbi は依存関係のエラーが発生することなくインストールできるようになりました。

Red Hat OpenStack Platform 9 に python-colorama パッケージが追加されました。
このパッケージは、ptyhon-gabbi のインストールの依存関係にあり、同様にopenstack-gnocchi には ptyhon-gabbi が必要です。
その結果、openstack-gnocchi と python-gabbi は依存関係のエラーが発生することなくインストールできるようになりました。

Time Series Database-as-a-Service (gnocchi) の Ceph Storage ドライバーは、「python-cradox」ライブラリーに対する依存関係があったため、Ceph バックエンドを使用する gnocchi は失敗していました。

今回の更新で、「python-cradox」は「openstack-puppet-modules」パッケージによってインストールされるようになりました。「python-cradox」は Ceph librados ライブラリー向けの Python ライブラリーで、「ctypes」の代わりに「cython」を使用します。その結果、Ceph バックエンドを使用する Time Series Database-as-a-Service はエラーが発生することなく実行されるようになりました。

Time Series Database-as-a-Service (gnocchi) の Ceph Storage ドライバーは、「python-cradox」ライブラリーに対する依存関係があったため、Ceph バックエンドを使用する gnocchi は失敗していました。

今回の更新で、「python-cradox」は「openstack-puppet-modules」パッケージによってインストールされるようになりました。「python-cradox」は Ceph librados ライブラリー向けの Python ライブラリーで、「ctypes」の代わりに「cython」を使用します。その結果、Ceph バックエンドを使用する Time Series Database-as-a-Service はエラーが発生することなく実行されるようになりました。

今回の更新で、Ceilometer アラーム API を使用するための API が Horizon に追加されました。これにより、今後 API を使用する開発が可能になります。ただし、現在はこの API の GUI フロントエンドはありません。

今回の更新で、Ceilometer アラーム API を使用するための API が Horizon に追加されました。これにより、今後 API を使用する開発が可能になります。ただし、現在はこの API の GUI フロントエンドはありません。

今回の更新により、Cinder ボリュームの暗号化のサポートが Horizon に追加されました。この機能により、管理者は暗号化されたボリューム種別を GUI から管理することができます。その結果、Horizon を使用してボリューム種別を追加、変更、削除できるようになりました。

今回の更新により、Cinder ボリュームの暗号化のサポートが Horizon に追加されました。この機能により、管理者は暗号化されたボリューム種別を GUI から管理することができます。その結果、Horizon を使用してボリューム種別を追加、変更、削除できるようになりました。

今回の更新で、「python-django-horizon」パッケージはバージョン 9.0.1 にリベースされました。

このリベースで修正された主要な問題には以下が含まれます。
* 「Create Network」のワークフローのバグ
* メタデータウィジェットでの既存のメタデータ表示の問題
* ローカリゼーションに関連したさまざまな問題

今回の更新で、「python-django-horizon」パッケージはバージョン 9.0.1 にリベースされました。

このリベースで修正された主要な問題には以下が含まれます。
* 「Create Network」のワークフローのバグ
* メタデータウィジェットでの既存のメタデータ表示の問題
* ローカリゼーションに関連したさまざまな問題

「stack-delete」コマンドを実行すると、削除を要求した直後に、Heat スタックに関する情報が表示されていました。Heat スタックの削除は、非同期の操作なので、表示されるステータスは「DELETE_IN_PROGRESS」には変わってない可能性があり、ユーザーの混乱を招く場合がありました。

今回のリリースでは、「stack-delete」コマンドは情報を表示しないようになりました。この動作は、OpenStack の各種サービスの delete コマンドと一貫しています。

「stack-delete」コマンドを実行すると、削除を要求した直後に、Heat スタックに関する情報が表示されていました。Heat スタックの削除は、非同期の操作なので、表示されるステータスは「DELETE_IN_PROGRESS」には変わってない可能性があり、ユーザーの混乱を招く場合がありました。

今回のリリースでは、「stack-delete」コマンドは情報を表示しないようになりました。この動作は、OpenStack の各種サービスの delete コマンドと一貫しています。

今回のリリースには、oslo.concurrency 3.7.1 からの更新が含まれています。これにより、CVE-2015-5162 のセキュリティーの脆弱性の対処に必要とされる新たなプロセスの制限が設けられます。この脆弱性と修正に関する詳しい情報は、https://bugs.launchpad.net/ossa/+bug/1449062 を参照してください。

今回のリリースには、oslo.concurrency 3.7.1 からの更新が含まれています。これにより、CVE-2015-5162 のセキュリティーの脆弱性の対処に必要とされる新たなプロセスの制限が設けられます。この脆弱性と修正に関する詳しい情報は、https://bugs.launchpad.net/ossa/+bug/1449062 を参照してください。

Red Hat OpenStack Platform 9 に python-wsgi_intercept パッケージが追加されました。
このパッケージは、ptyhon-gabbi のインストールの依存関係にあり、同様にopenstack-gnocchi には ptyhon-gabbi が必要です。
その結果、openstack-gnocchi と python-gabbi は依存関係のエラーが発生することなくインストールできるようになりました。

Red Hat OpenStack Platform 9 に python-wsgi_intercept パッケージが追加されました。
このパッケージは、ptyhon-gabbi のインストールの依存関係にあり、同様にopenstack-gnocchi には ptyhon-gabbi が必要です。
その結果、openstack-gnocchi と python-gabbi は依存関係のエラーが発生することなくインストールできるようになりました。