第3章 リリースの情報

以前のリリースでは、「nova list」コマンドを実行すると、コンピュートノードで障害が発生したインスタンスも実行中として表示されていました。今回のリリースでは、インスタンスの状態はホストするコンピュートノードが停止した場合には更新されるようになったため、ユーザーは「nova list」の出力をアップタイムのモニタリングで信頼できるようになりました。

以前のリリースでは、「nova list」コマンドを実行すると、コンピュートノードで障害が発生したインスタンスも実行中として表示されていました。今回のリリースでは、インスタンスの状態はホストするコンピュートノードが停止した場合には更新されるようになったため、ユーザーは「nova list」の出力をアップタイムのモニタリングで信頼できるようになりました。

Ceph ベースの一時ディスクのスナップショットには、RBD ベースのスナップショットとクローン作成が使用されるようになりました。今回の更新では、データがノード間で転送されるのではなく、Ceph サーバー内で操作されるため、Ceph のスナップショット作成のパフォーマンスが改善されます。

Ceph ベースの一時ディスクのスナップショットには、RBD ベースのスナップショットとクローン作成が使用されるようになりました。今回の更新では、データがノード間で転送されるのではなく、Ceph サーバー内で操作されるため、Ceph のスナップショット作成のパフォーマンスが改善されます。

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

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

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

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

今回の更新で、新たに機能が拡張され、「OS::Neutron::ProviderNet」リソースに新たなブール型プロパティー「router_external」が追加されました。このオプションにより、テンプレートの作成者は、ネットワークに外部ルーターを含むかどうかを指定することができます。

今回の更新で、新たに機能が拡張され、「OS::Neutron::ProviderNet」リソースに新たなブール型プロパティー「router_external」が追加されました。このオプションにより、テンプレートの作成者は、ネットワークに外部ルーターを含むかどうかを指定することができます。

今回の更新で、Keystone の eventlet システムがアップストリームで非推奨となりました。
Red Hat OpenStack Platform director は Keystone が Apache 下で WSGI を使用して実行するように設定するようになりました。この変更は、Keystone デプロイメントは WSGI 内で実行することを Keystone プロジェクトが推奨していることが理由で適用されました。
その結果、Keystone サービスは、Apache httpd サービス下で実行されるようになりました。

今回の更新で、Keystone の eventlet システムがアップストリームで非推奨となりました。
Red Hat OpenStack Platform director は Keystone が Apache 下で WSGI を使用して実行するように設定するようになりました。この変更は、Keystone デプロイメントは WSGI 内で実行することを Keystone プロジェクトが推奨していることが理由で適用されました。
その結果、Keystone サービスは、Apache httpd サービス下で実行されるようになりました。

今回の更新で、QoS ポリシーのロールベースアクセス制御 (RBAC) が追加され、QoS ポリシーを特定のプロジェクトに適用できるようになりました。たとえば、優先度の低いネットワークトラフィックを許可する QoS ポリシーを作成して、特定のプロジェクトにのみ適用することが可能です。

今回の更新で、QoS ポリシーのロールベースアクセス制御 (RBAC) が追加され、QoS ポリシーを特定のプロジェクトに適用できるようになりました。たとえば、優先度の低いネットワークトラフィックを許可する QoS ポリシーを作成して、特定のプロジェクトにのみ適用することが可能です。

今回の更新で、新たに機能が拡張され、Bare Metal Provisioning サービスがイメージをデプロイするのに適したディスクデバイスを名前またはパスを使用して特定できるようになりました。一部のデバイスには、永続名 (例: RAID) があります。この新機能により、オペレーターはディスクの WWN、シリアル、モデル名などを使用する代わりに、デバイスの永続名を使用することができます。

今回の更新で、新たに機能が拡張され、Bare Metal Provisioning サービスがイメージをデプロイするのに適したディスクデバイスを名前またはパスを使用して特定できるようになりました。一部のデバイスには、永続名 (例: RAID) があります。この新機能により、オペレーターはディスクの WWN、シリアル、モデル名などを使用する代わりに、デバイスの永続名を使用することができます。

今回の機能拡張で、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、その他のドライバーでインバンドクリーニングステップを実行することができるようになりました。

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

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

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

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

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 は依存関係のエラーが発生することなくインストールできるようになりました。

CDH バージョン 5.5 は CDH プラグインのパッケージ済みバージョンで利用できるようになり、デフォルトで有効化されます。

CDH バージョン 5.5 は CDH プラグインのパッケージ済みバージョンで利用できるようになり、デフォルトで有効化されます。

今回のリリースでは、Heat で「map_merge」機能がサポートされています。この機能により、ユーザーは複数のマップをマージして、その値でマージする前の値を上書きすることができます。これは、設定データを含むマップで単一の統合されたマップを構成する場合に役立ちます。

詳しい説明は、http://docs.openstack.org/developer/heat/template_guide/hot_spec.html#map-merge を参照してください。

今回のリリースでは、Heat で「map_merge」機能がサポートされています。この機能により、ユーザーは複数のマップをマージして、その値でマージする前の値を上書きすることができます。これは、設定データを含むマップで単一の統合されたマップを構成する場合に役立ちます。

詳しい説明は、http://docs.openstack.org/developer/heat/template_guide/hot_spec.html#map-merge を参照してください。

OpenDaylight OpenStack neutron ドライバーは、neutron プロジェクトから分離され、新たなパッケージ python-networking-odl に移動しました。このドライバーの最新バージョンは、引き続き Red Hat OpenStack Platform インストール環境の一部として使用することができます。

OpenDaylight OpenStack neutron ドライバーは、neutron プロジェクトから分離され、新たなパッケージ python-networking-odl に移動しました。このドライバーの最新バージョンは、引き続き Red Hat OpenStack Platform インストール環境の一部として使用することができます。

今回の機能拡張により、エージェントドライバー (「agent_」というプレフィックスが付いたドライバー) でパーティションイメージをデプロイすることができるようになりました。
この機能は、OpenStack Bare Metal Provisioning (ironic) 内の全ドライバーが完全なディスクイメージ (ブートローダーおよびその他のプロパティーを含むパーティションテーブルを格納するイメージ) をデプロイ可能にする必要があるために追加されました。これには、root ファイルシステムを使用するイメージであるパーティションイメージも含まれます。
その結果、エージェントドライバーはパーティションイメージと完全なディスクイメージをデプロイすることができるようになりました。

今回の機能拡張により、エージェントドライバー (「agent_」というプレフィックスが付いたドライバー) でパーティションイメージをデプロイすることができるようになりました。
この機能は、OpenStack Bare Metal Provisioning (ironic) 内の全ドライバーが完全なディスクイメージ (ブートローダーおよびその他のプロパティーを含むパーティションテーブルを格納するイメージ) をデプロイ可能にする必要があるために追加されました。これには、root ファイルシステムを使用するイメージであるパーティションイメージも含まれます。
その結果、エージェントドライバーはパーティションイメージと完全なディスクイメージをデプロイすることができるようになりました。

OpenStack Data Processing サービス (sahara) が OSP director  でデプロイできるようになりました。現在のリリースは、Sahara を全コントローラーノードにデプロイして利用できるようにします。OSP director に Sahara が統合されている最初のリリースであるため、サービスの設定は最小限ですが、インストーラーに追加の負担がかからないようにもなっています。Sahara はオーバークラウドのコントローラーノードでデフォルトで有効化されます。

OpenStack Data Processing サービス (sahara) が OSP director  でデプロイできるようになりました。現在のリリースは、Sahara を全コントローラーノードにデプロイして利用できるようにします。OSP director に Sahara が統合されている最初のリリースであるため、サービスの設定は最小限ですが、インストーラーに追加の負担がかからないようにもなっています。Sahara はオーバークラウドのコントローラーノードでデフォルトで有効化されます。

今回の更新で、アベイラビリティーゾーンは、DHCP やルーターなどのサービスを実行するネットワークノードをグループ化するようになりました。これは、ネットワークノード上のエージェントの属性として定義され、ネットワークリソースを高可用性に設定するのに使用されます。オペレーターは、異なるアベイラビリティーゾーン下の異なる電源に接続されたノードをグループ化して、 リソースのスケジューリングを高可用性で設定すると、それらのリソースは異なるアベイラビリティーゾーンに対してスケジュールされます。これにより、ユーザーは 1 つのアベイラビリティーゾーンを複数のルーターおよびネットワークに関連付けして、複数のゾーンにリスクを分散することができます。

今回の更新で、アベイラビリティーゾーンは、DHCP やルーターなどのサービスを実行するネットワークノードをグループ化するようになりました。これは、ネットワークノード上のエージェントの属性として定義され、ネットワークリソースを高可用性に設定するのに使用されます。オペレーターは、異なるアベイラビリティーゾーン下の異なる電源に接続されたノードをグループ化して、 リソースのスケジューリングを高可用性で設定すると、それらのリソースは異なるアベイラビリティーゾーンに対してスケジュールされます。これにより、ユーザーは 1 つのアベイラビリティーゾーンを複数のルーターおよびネットワークに関連付けして、複数のゾーンにリスクを分散することができます。

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 は依存関係のエラーが発生することなくインストールできるようになりました。

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

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

今回の機能拡張で、Orchestration (heat) の API コールを使用して、リソースを unhealthy としてマークして、その後のスタックの更新で置き換えられるようにすることができるようになりました。
たとえば、「ResourceGroup」内のサーバーでエラーが発生した場合にはブラックリストする (インデックスは不連続で、置き換えられたリソースには新しい名前が付けられる) のではなく、サーバーが unhealthy としてマークされ、Heat がそのサーバーをグループ内の同じ名前とインデックスの新しいサーバーに置き換えます。
「mark-unhealthy」コマンドを実行すると、リソースは CHECK_FAILED の状態になります。その後にスタックの更新が実行されると、unhealthy なリソースは (*_FAILED の状態の全リソースで実行するのと同様に) 置き換えられます。

今回の機能拡張で、Orchestration (heat) の API コールを使用して、リソースを unhealthy としてマークして、その後のスタックの更新で置き換えられるようにすることができるようになりました。
たとえば、「ResourceGroup」内のサーバーでエラーが発生した場合にはブラックリストする (インデックスは不連続で、置き換えられたリソースには新しい名前が付けられる) のではなく、サーバーが unhealthy としてマークされ、Heat がそのサーバーをグループ内の同じ名前とインデックスの新しいサーバーに置き換えます。
「mark-unhealthy」コマンドを実行すると、リソースは CHECK_FAILED の状態になります。その後にスタックの更新が実行されると、unhealthy なリソースは (*_FAILED の状態の全リソースで実行するのと同様に) 置き換えられます。

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

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

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

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