今回のリリースの以前は、設定ファイルの更新中に、別のロックファイルが使用されていました。また、更新中には、ディレクトリーのエントリーが正しく同期されませんでした
その結果、このプロセス中にクラッシュが発生すると、それ以降に設定更新を試みた際にデッドロック問題が起こる可能性があり、またごくまれですが、設定ファイルが破損する (空になる) 場合があります。
今回の更新では、「crudini」ユーティリティー内により強固なロッキングと同期の機能が実装され、システムクラッシュの発生中における設定ファイルの更新が強化されました。

このリベースパッケージには、バージョン 5.5.42 の重要な修正が含まれています。
自動インクリメントするプライマリーキーを使用する INSERT ステートメントが、正常に機能する Galera ノード上で「DUPLICATE PRIMARY KEY」エラーで失敗する可能性がありましたが、今回のリリースで問題が解決されました。この問題は、同じテーブルに対して INSERT ステートメントを処理する異なる Galera ノードがクラスターから削除された後に発生していました。そのため、 Galera のフェイルオーバー操作の実行中には、OpenStack のアプリケーションで新規レコード作成が一時的に失敗していました。

以前のバージョンの「alarm-history」では、アラームの重大度がいつ変更されたか (例: 「低」から「クリティカル」への変更など) は示されず、変更内容に関する情報なしに提示されていました。
今回の更新では、この問題に対処するために、重大度の変更内容を表示するコードが更新されました。
その結果、「alarm-history」では、重大度の変更が出力に表示されるようになりました。

以前のリリースでは、ceilometer のポーリング拡張機能をロードすることができない場合に、ERROR メッセージがログに記録されていました。これは、たとえば拡張機能がオプションの場合や、依存関係のモジュールが利用できない場合など、モジュールのロードに失敗することが予想される際には、誤解を招く恐れがありました。今回のリリースでは、ログメッセージが WARN レベルに変更され、深刻なエラーではないことが明確にわかるようになりました。

今回の更新では、NetApp Cmode および 7mode iSCSI ドライバーに拡張ボリュームの管理/管理解除のサポートが追加されました。これらのドライバーの使用時には新機能が提供されるようになりました。

今回の更新では、NetApp E シリーズのドライバーでボリュームの管理/管理解除をサポートする新機能が実装されました。これにより、Block Storage の管理下にないボリュームの必須入力項目として「--source-name」パラメーターを使用することができるようになりました。

今回の更新により、cinder-backup サービスに NFS バックエンドが追加されました。これにより、NFS ストレージバックエンドにボリュームをバックアップできるようになりました。

今回の更新では、「cinder-manage db」に機能が追加され、古い「削除済み」のデータを Cinder データベースから安全に完全削除できるようになりました。これにより、データベースの使用領域が削減され、データベースのパフォーマンスが向上します。

今回の更新の以前は、SQLAlchemy オブジェクトが複数の「cinder-volume」プロセス間で不適切に共有されていました。 
このため、Block Storage のマルチバックエンドを使用する場合には、SQLAlchemy の接続が失敗し、ボリュームサービスで、データベース関連のエラーが発生していました。
今回の修正では、「cinder-volume」の子プロセスのフォーク時に SQLAlchemy 接続が再初期化されるようになりました。
これにより、マルチバックエンドが想定通りに機能するようになりました。

以前のバージョンでは、イメージからのボリューム作成でエラーが発生していました。セクター数の多い仮想ディスク上では、セクター数の処理が適切に行われない場合があり、QEMU イメージの変換が「invalid argument」のエラーで失敗していました。 

このバグは、QEMU-img の修正版に更新することによって解決されるようになりました。この修正版は、エラーの原因となっていた誤算問題を解決します。これにより、イメージからのボリューム作成は正常に機能するようになりました。

Image Service のロギング機能が改善され、より有用な情報がユーザーに提供されるようになりました。また、ログに機密情報が含まれないようになり、メッセージに適切なロギングレベルが使用されるようになりました。この変更は、オペレーターにのみに表示されます。

今回の更新では、SIGHUP シグナルを「glance-*」プロセスに送信することにより、Image Service の設定値を動的に再読み込みできるようになりました。このシグナルは、プロセスによる設定ファイルの再読み取りと新規設定の読み込みが確実に行われるようにします。その結果、設定の変更を適用するために、Image Service 全体を再起動する必要がなくなりました。

今回の更新では、ベースの非同期タスクエンジンが変更され、taskflow ライブラリーをベースにするようになりました。これにより、API やワークフローへの変更はありませんが、以下の新規設定オプションが追加されます。

[taskflow_executor]
engine_mode = serial # or parallel

以前のリリースでは、glance-manage ユーティリティーは、「glance-api.conf」または「glance-registry.conf」で設定されていました。今回のリリースでは、glance-manage の設定に使用できる「glance-manage.conf」という名前の新規設定ファイルが採用されました。glance-manage の設定には、「glance-api.conf」と「glance-registry.conf」を引き続き使用することも可能ですが、「glance-manage.conf」の設定が優先されます。

以前のリリースでは、Image Service の「swift」ストア実装は、単一のコンテナー上に全イメージを保管していました。この方法は適切に機能していましたが、大規模なデプロイメントにおいてパフォーマンス上のボトルネックとなっていました。

今回の更新では、「glance」イメージの保存先として複数の Object Storage コンテナーを使用できるようになりました。この機能を使用するには、「swift_store_multiple_containers_seed」の値を 0 よりも大きな値に設定する必要があります。「swift_uer_multi_tenant」パラメーターを有効化すると、これらのコンテナーがテナントベースで分割されるため、複数のコンテナーの使用を無効にすることができます。

glance_store ライブラリーがサポートするストレージ機能が拡張されました。これにより、特定のストアでどの操作を実行できるかなど、より粒度の高い管理が可能となります。本リリースでは、以下の機能が実装されています。

 - READ_ACCESS: 汎用読み取りアクセス 
 - WRITE_ACCESS: 汎用書き込みアクセス
 - RW_ACCESS  : READ_ACCESS および WRITE_ACCESS
 - READ_OFFSET: オフセットからの全ビット読み込み (READ_ACCESS に含まれる)  
 - WRITE_OFFSET: オフセットへの全ビット書き込み  (WRITE_ACCESS に含まれる) 
 - RW_OFFSET  : READ_OFFSET および WRITE_OFFSET
 - READ_CHUNK : 必要な長さのビット読み込み (READ_ACCESS に含まれる)  
 - WRITE_CHUNK: 必要な長さのビットの書き込み  (WRITE_ACCESS に含まれる) 
 - RW_CHUNK: READ_CHUNK および WRITE_CHUNK  
 - READ_RANDOM: READ_OFFSET および READ_CHUNK  
 - WRITE_RANDOM: WRITE_OFFSET および WRITE_CHUNK
 - RW_RANDOM: RW_OFFSET および RW_CHUNK  
 - DRIVER_REUSABLE: ドライバーはステートレスで、そのインスタンスを安全に再利用することが可能

今回の更新では、完全に新しい API が利用できるようになりました。この API により、Image Service を対象とする検索機能が追加され、一覧表示と検索の操作 (特に UI との対話) におけるパフォーマンスが向上します。

検索 API により、ユーザーは検索クエリーを実行し、そのクエリーに一致する検索結果を取得することが可能です。クエリーは、単純なクエリー文字列をパラメーターとして使用するか、要求本文を使用することによって指定することができます。検索 API はすべて、1 つのインデックス内にある複数の種別に対して、またマルチインデックス構文をサポートする複数のインデックスに対して適用することができます。

注記: この機能拡張は、RHEL OpenStack Plaform 8 (Liberty) リリースでは、Image Service から削除される予定です。

以前のリリースでは、policy.enforce への呼び出しはすべて、空のディクショナリーをターゲットとして渡していました。ターゲットが常に空のディクショナリーとなるため、オペレーターは、policy.json ファイル内のテナント固有の制限を使用することができませんでした。 一部のアクションを制限してイメージオーナー (正しいテナント ID のあるユーザー) がアクションを実行できるようにしようとすると、ターゲットが空のディクショナリーであるためにチェックが失敗していました。

今回の更新では、イメージをラップする ImageTarget インスタンスを enforcer に渡して、それらのルールを使用し、適切に有効化できるようになりました。テナントをベースとしたイメージオーナー (例: owner:%(tenant) にアクセスを適切に許可することが可能です。この修正がなければ、Image Service で機能するチェックは、 RoleCheck (例: role:admin) のみです。

今回の更新では、一覧表示の操作に複数のフィルターオプションと複数の並べ替え方向を使用してフィルタリングできるようになりました。以下に例を示します。

  /images?sort=status:asc,name:asc,created_at:desc

この例では、イメージの一覧が返され、ステータスは昇順、名前は昇順、作成日は降順の並べ替え方向でソートされます。

今回の変更では、複数のフィルターと複数の並べ替え方向を使用して一覧表示の操作をフィルタリングできるようになりました。以下に例を示します。

  /images?sort=status:asc,name:asc,created_at:desc

この例では、イメージの一覧が返され、ステータスは昇順、名前は昇順、作成日は降順の並べ替え方向でソートされます。

Orchestration Service に「OS::Heat::Stack」リソースタイプが追加されました。この OpenStack ネイティブリソースは、テンプレート内に子スタックを明示的に作成するのに使用されます。「OS::Heat::Stack」リソースタイプには「コンテキスト」プロパティーに「region_name」サブプロパティーが含まれています。これにより、Orchestration Service が異なるリージョンでスタックを管理することができます。

AWS::EC2::SecurityGroup のリソースタイプのルールが変更された場合に、インプレース更新ができるようになりました。これは、CloudFormation 内のAWS::EC2::SecurityGroup の動作と一致しています。以前は、ルールの変更時にはセキュリティーグループが置き換えられていました。

Heat でユーザーフックがサポートされるようになりました。このフックにより、ユーザーが指定の時点でスタック操作の実行を一時停止して、Heat のワークフローに独自のアクションを挿入することができます。フックはスタックの環境ファイル内のリソースにアタッチされます。現在、サポートされているフックのタイプは「pre-create」と「pre-update」です。

OS::Nova::Server のリソースタイプに「console_urls」プロパティーが含まれるようになりました。これにより、ユーザーはリソースからサーバーのコンソール (VNC コンソールなど) の URL を取得することができます。

Orchestration API 内のリソースに対するクエリーを実行する際には、ユーザーは単一または複数のリソース属性の値を出力に追加するように要求できるようになりました。これにより、ユーザーはスタックのテンプレートを変更して出力のセクションに対象のデータを追加しなくても、任意のリソースから随時データを取得することができるようになるので、デバッグに役立ちます。

OS::Cinder::Volume のリソースタイプに「scheduler_hints」プロパティーが追加され、ボリュームの作成時に、スケジューラーのヒントを Block Storage Service に渡すことができるようになりました。これには、Storage API の v2 が必要です。

heat-manage コマンドに、サブコマンド「heat-manage service-list」が追加されました。このサブコマンドは、アクティブな「heat-engine」プロセスが実行されている場所と現在のステータスに関する情報を表示します。

OS::Neutron::Port リソースタイプで「binding:vnic_type」プロパティーがサポートされるようになりました。このプロパティーにより、適切なパーミッションのあるユーザーは、OpenStack Networking ポートの仮想 NIC の種別を指定することができます。

AWS::AutoScaling::AutoScalingGroup リソースタイプで「InstanceId」プロパティーがサポートされるようになりました。これにより、AWS::AutoScaling::LaunchConfiguration リソースからではなく既存のサーバーから自動スケーリンググループの起動設定をクローン作成できます。

AWS::AutoScaling::LaunchConfiguration リソースタイプで「InstanceId」プロパティーがサポートされるようになりました。これにより、既存のサーバーから自動スケーリンググループの起動設定をクローン作成することができます。

以前のリリースでは、スタック更新で環境の「files」セクションが変更されると、Orchestration Service は新規ファイルを古いスタック定義と統合して、以前の状態を算出していました。これは、以前の状態を新規ファイルおよび新規テンプレートと比較するのを目的としていました。
その結果、Orchestration Service は追加されたファイルでの変更を認識せず、ファイルへの変更のみに基づいた更新は行われませんでした。また、以前に参照したファイルは、スタックの更新で環境から削除され、スタックの更新が失敗していました (ただし、同じデータを使用して更新を後で行うと正常に更新することができました)。

今回のリリースでは、Orchestration Service が古いスタックを古いファイルに統合して、新規テンプレートと新規ファイルと比較するようになりました。更新は、環境に含まれるファイルを編集する際に、想定通りに機能するようになりました。

以前のリリースでは、テンプレートリソース (スタックによって暗黙的にバッキングされるリソース) のテンプレートの絶対パスに変更が加えられても、Orchestration Service によって認識されませんでした。これにより、リソースのテンプレートの名前が変更されたり、移動されたりした際に、テンプレートリソースをバッキングするスタックでネストされたものは更新されませんでした。

今回のリリースでは、Orchestration Service がこのような変更を検出できるようになり、それによって、ネストされたスタックは、適宜更新されるようになりました。

Bare Metal は、iLO クライアントの Python ライブラリーを使用する HP ProLiant Service の管理インターフェースをサポートするようになりました。これにより、Bare Metal が管理操作 (ブートデバイスの取得や設定など) を実行できます。

Bare Metal Service は、インスタンス上でユーザーデータを挿入するための cloud-init および同様の早期初期化ツールを使用できるようになりました。以前のリリースでは、この操作を行うには、メタデータサービスを設定してこの機能を実行する必要がありました。

今回の新たな更新により、Bare Metal はインスタンスのメタデータをデプロイメント上のローカルディスク (具体的には、「config-2」というラベルの付いたデバイス) に挿入することができます。その後に、早期初期化ツールを設定して、そのデバイスを検出し、そこからデータを抽出することができます。

Bare Metal Service は、UEFI (http://www.uefi.org) のセキュアブート機能を使用してノードをデプロイできるようになりました。セキュアブートにより、ノードは信頼済みのソフトウェアのみを起動するようになります。

この更新により、ブート時にブートチェーン全体を検証してから、承認済みのイメージのみを起動するようにノードを設定し、セキュリティーを強化することができます。

 Bare Metal のインスタンスに「maintenance_reason」という名前の新しいフィールドが追加されました。このフィールドには、ノードがメンテナンスモードに切り替えられた理由を提示することができます。

Bare Metal Service が Fujitsu iRMC (integrated Remote Management Controller) ハードウェアに対応するようになりました。これにより、Bare Metal は Fujitsu iRMC マシンの電源状態を管理することができます。

Ironic のドライバーはすべて IPA ramdisk を介したデプロイメントをサポートするようになりました。IPA は Python で書かれおり、BASH ramdisk よりも多くの機能をサポートし、サービスとして実行されます。このような理由により、IPA を介してデプロイされるノードは、通常デプロイメント、デバッグ、管理を容易に行うことができます。

以前のリリースでは、11g と 12g のハードウェアで使用する DRAC カードの WSMAN インターフェースが異なりました。
このため、11g ハードウェア上で DRAC ドライバーを使用した場合には、OpenStack Bare Metal Provisioning (Ironic) における「get_boot_device」と「set_boot_device」の呼び出しが失敗していました。
今回の更新により、DRAC ドライバーはライフサイクルコントローラーのバージョンをチェックし、バージョンによって異なるメソッドを適用することでブートデバイスを管理するようになりました。
その結果、「get_boot_device」および「set_boot_device」の操作は、11g ノード上で正常に実行されるようになりました。

Compute Service では、インスタンスの削除を随時実行可能であることが想定されていますが、Bare Metal インスタンスは、特定の段階 (「DEPLOYWAIT」状態の時) でしか停止することができません。このため、Compute Service が DEPLOYWAIT 状態以外の Bare Metal インスタンスの削除を試みると必ず Compute の動作でエラーが発生していました。この操作によって、インスタンスが特定の状態でスタックしてしまう場合があり、問題を解決するにはデータベースの変更が必要でした。

今回のリリースでは、Compute が Bare Metal インスタンスの削除を試みても、デプロイメント中にスタックしなくなりました。ただし、Bare Metal Service は DEPLOYWAIT 状態でなければ、インスタンスを停止しない点は変わりません。

以前のリリースでは、OpenStack Bare Metal Provisioning (Ironic) の DRAC ドライバーが「completed with errors」のジョブステータスを「in-progress」のステータスとして誤認識していたため、「in-progress」のジョブが存在しないことを要件とする「get_boot_device」および「set_boot_device」のタスクは失敗していました。
今回の更新では、「completed with errors」を完了済みステータスの一覧に追加することによりこの問題に対処しました。その結果、「get_boot_device」および「set_boot_device」のタスクは DRAC カード上で「completed with errors」のジョブがある場合でも続行されるようになりました。

以前のリリースでは、「pass_bootloader_install_info」メソッドが DRAC の「vendor_passthru」インターフェースに含まれていませんでした。このため、ローカルブートが有効化されている場合には、PXE デプロイメントタスクが失敗していました。
今回の修正により、標準の PXE インターフェースから DRAC の「vendor_passthru」インターフェースに「pass_bootloader_install_info」が追加されました。その結果、ローカルブートが有効化されていてもデプロイメントが想定通り正常に実行されるようになりました。

今回の更新の以前は、OpenStack Bare Metal Provisioning (Ironic) の操作 (例: 「電源オフ」など) によりノードのロック状態が予想よりも長く続いていました。 
このため、ノードがまだロックされていると見なされている間には、特定の操作が失敗してしまいました。
今回の更新により、再試行のタイムアウトが 2 分間に調整され、ノードのロックによるエラーが発生しなくなりました。

Identity Service (keystone) でトラストの再委任ができるようになりました。これにより、トラストトークンを持つトラスティーが別のトラストを作成して、そのロールを別のトラスティーに委任することができます。また、カウンターにより、トラストが再委任できる回数が列挙されます。
この機能により、トラスティーは、トラストトークンに含まれているロールを他のトラスティーに再委任することが可能です。初期トラストを作成するユーザーは、必要な場合にはトラストを再委任可能とするかどうかを制御することができます。
したがって、元のトラストによって許可されている場合には、再委任が可能となります。

Identity Service (keystone) でスコープなしトークンを明示的に要求できるようになりました。
この機能が追加される以前は、デフォルトプロジェクトが割り当てられたユーザーがスコープなしトークンを取得できませんでした。そのため、このようなユーザーがスコープを定義せずにトークンを要求すると、自動的にデフォルトプロジェクトがスコープに設定されていました。
今回の更新の結果、デフォルトプロジェクトが定義されている場合でも、すべてのユーザーにスコープなしトークンを発行することが可能となりました。

今回の更新では、Identity Service (keystone) でプロジェクトリソース内の「parent_id」を指定することにより、プロジェクトの階層化が可能となりました。
以前のリリースでは、Identity Service はフラットなプロジェクトモデルのみに対応していました。プロジェクトの階層化により、プロジェクトの構造がより柔軟となり、組織構造を模倣するのに使用することができます。
その結果、プロジェクトに親プロジェクトを定義して、プロジェクトの階層を構築することができます。

Identity Service では、「トークン」による認証メソッドでスコープ付きのトークンを取得するのに、スコープなしのフェデレーショントークンを使用できるようになりました。 

Identity Service のフェデレーション拡張機能を使用すると、初回の認証でスコープなしのフェデレーショントークンが返されてから、そのトークンがスコープ付きトークンと交換されます。以前のリリースでは、スコープなしのフェデレーショントークンは、スコープ付きトークンの取得に「saml2」または「mapped」認証を使用する必要がありました。これは、「token」メソッドを使用して、標準のスコープなしトークンをスコープ付きトークンと交換する方法との一貫性がありませんでした。

スコープなしのフェデレーショントークンとスコープ付きトークンの交換には、「token」認証メソッドが使用されるようになり、標準のスコープなしトークンの場合の動作との一貫性が保たれるようになりました。

Identity Service では、トークンの再スコープを制限して、スコープなしのトークンをスコープ付きトークンと交換する操作のみが可能となりました。

Identity Service では、「token」認証メソッドで新規トークンを取得するのに既存のトークンを使用することができます。以前のリリースでは、対象のプロジェクトのスコープが付いた有効なトークンのあるユーザーは、そのトークンを使用して、承認されている別のプロジェクト用にもう 1 つのトークンを取得することができました。このため、ユーザーのトークンの所有者がアクセスできるのは、そのトークンに付いたスコープのプロジェクトのみではなく、そのユーザーがアクセス可能な任意のプロジェクトへのアクセスも可能でした。しかし、スコープ付きトークンのセキュリティープロパティーを改善するためには、この操作を不可にすることが適切でした。
 
新しい「allow_rescope_scoped_token」設定オプションにより、トークンの再スコープを制限することが可能となりました。このオプションを有効にすると、トークンの再スコープは、認証にスコープなしトークンを使用しなければ実行できません。

Identity Service は、「fernet」という新規トークンフォーマットを試験的にサポートするようになりました。

Identity Service が現在サポートしているトークンフォーマットでは、発行されるトークンがデータベーステーブル内で永続化される必要があります。このテーブルは、非常に大きなサイズに拡大する可能性があり、その場合には、Identity Service の良好な稼働状態を保つために、適切なチューニングとフラッシュジョブが必要となります。新しい「fernet」トークンフォーマットは、テーブルによってスケーラビリティーが制限されるのを回避するために、トークンデータベーステーブルを排除できる設計となっています。「fernet」トークンフォーマットは、試験的な機能として現在利用可能です。

今回の更新の以前は、Open vSwitch (OVS) エージェント上のトンネルの送信元 IP アドレスを手動で切り替えると、別のエージェントがそのエージェントに対して 2 つのトンネルを (1 つは古い IP アドレス、もう 1 つは新しい IP アドレスに) 開放した状態を維持していました。
その結果、OVS エージェントを実行するクラウド内の全ハイパーバイザー上で余分なメタデータが蓄積していました。
この問題に対処するために、ネットワークノードはホスト上で IP アドレスの変更を検出し、新しい情報を保持して、IP アドレスの変更を他のエージェントにも通知するようになりました。

以前のリリースでは、OpenStack Dashboard LBaaS プールの詳細ページは、LBaaS プールにアタッチされたサブネットが削除されるという予期せぬ状況が発生した場合に正しく処理されませんでした。
そのため、ネットワーク、ルーター、ロードバランサーを作成してから、ネットワーク、サブネット、ルーターを削除し、ロードバランサーを維持した場合、OpenStack Dashboard LBaaS の詳細ページはエラー 500 を返していました。
今回の更新では、このシナリオを確認して、代わりに警告のメッセージを表示することでこの問題に対処するようになりました。その結果、LBaaS の詳細ページが正しくレンダリングされ、必要に応じて警告が表示されるようになりました。

今回の更新では、管理者が各ノード上の高可用性ルーターの状態 (具体的には、アクティブなインスタンスのホスト先) を確認できるようになりました。
以前のリリースでは、高可用性ルーターの状態に関する情報は、管理者に表示されませんでした。このため、メンテナンスを容易に行うことができませんでした。たとえば、エージェント間で HA ルーターのインスタンスを移行する場合やノードをメンテナンスモードに切り替えることによって受ける影響を評価する場合などです。 
この新機能は、サニティーテストとしての役割も果たし、ルーターが必ず 1 つのノードでのみアクティブとなることを保証します。その結果、管理者は、高可用性ルーターに対して「neutron l3-agent-list-hosting-router <router_id>」コマンドを実行して、アクティブなインスタンスの現在のホスト先を確認できるようになりました。

分散ルーターを使用する OpenStack Networking のデプロイメントで、テナントに、仮想 LAN セグメンテーションに対応した独自のネットワークを作成できるようになりました。
以前のリリースでは、分散ルーターは、トンネルネットワークのみをサポートしていました。 多くのデプロイメントが仮想 LAN を推奨しているため、この制限が導入の妨げとなる場合がありました。 
今回の更新により、分散ルーターがトンネルネットワークと仮想 LAN ネットワークのサービスを提供できるようになりました。

Red Hat Enterprise Linux OpenStack Platform 7 では、openswan の代わりに libreswan を採用していますが、OpenStack Networking (neutron) openswan VPNaaS ドライバーは、libreswan では機能しません。
今回の更新では、vpnagent.ini で libreswan 固有のドライバーを有効化することができるようになりました。
[vpnagent]
vpn_device_driver=neutron_vpnaas.services.vpn.device_drivers.libreswan_ipsec.LibreSwanDrive

その結果、VPNaaS は想定通り機能するようになりました。

「python-neutron-fwaas」パッケージの既知の問題が原因で、Firewall-as-a-Service (FWaaS) が正常に機能しない場合があります。これは、「python-neutron-fwaas」パッケージにデータベースアップグレードの「バージョン」ディレクトリーが含まれていないことが原因です。
また、現時点では、バージョンリリース間でのデータベーススキーマのアップグレードが正常に機能しない可能性があります。

「python-neutron-fwaas」パッケージの既知の問題が原因で、Firewall-as-a-Service (FWaaS) が正常に機能しない場合があります。これは、「python-neutron-fwaas」パッケージにデータベースアップグレードの「バージョン」ディレクトリーが含まれていないことが原因です。
また、現時点では、バージョンリリース間でのデータベーススキーマのアップグレードが正常に機能しない可能性があります。

以前のリリースでは、dnsmasq がリース情報を永続ストレージに保存せず、再起動時にはそのリース情報は失われていました。この動作は、BZ#1202392 で dnsmasq の「--dhcp-script」オプションが削除されたことが原因でした。
その結果、インスタンスはネットワークブートプロセス中に長時間スタックしていました。また、NAK メッセージが dnsmasq ログに記録されてしまいました。
今回の更新では、優先するオプションを削除することによってこの問題に対処し、他のサーバーへの DHCPREQUEST に対する応答で NAK が送信されないようになりました。この変更により、 dnsmasq が再起動/再スケジュールされる前に発行されたリースの更新をするクライアントに NAK が送信されるのが防がれ、DHCPNAK メッセージがログファイルに記録されなくなります。

Kilo では、Neutron のサービスが rootwrap とよばれるデーモンに依存して「ip」や「sysctl」などの外部コマンドを実行できるようになりました。このデーモンは、rootwrap フィルターを事前キャッシュして、エージェントのパフォーマンスを大幅に改善します。

RHEL-OSP7 では、rootwrap デーモンはデフォルトで有効化されています。このデーモンを有効にせず、「sudo」などの別の root 権限分離メカニズムを引き続き使用する場合は、neutron.conf ファイルの [agent] セクションで「root_helper_daemon =」を設定して、デーモンの無効化も必ず行ってください。

今回の更新の以前は、「neutron-lbaasv2-agent」に .service ファイルがありませんでした。
このため、systemd の管理下ではエージェントを起動する方法がありませんでした。
今回の更新で、パッケージに .service ファイルが追加されました。 
これにより、「systemctl start neutron-lbaasv2-agent」コマンドでサービスを起動できるようになりました。

VMware vSAN データストアを使用できるようになりました。このストアにより、インスタンスにハイパーバイザーのローカルストレージを使用するのと同時に vMotion を使用できます。

VMware のストレージポリシーを使用して、異なるインスタンスにストレージを割り当てる方法を管理できるようになりました。これにより、コストとパフォーマンスのプロパティーが異なる複数のデータストアが VMware インフラストラクチャーにアタッチされた環境で、最も適切なストレージにインスタンスを割り当てることができます。

以前のリリースでは、Compute のデータベースに virtual_interfaces テーブルのインデックスがありませんでした。このため、テーブルが拡大すると、そのテーブルに対する操作に著しく時間がかかり、タイムアウトが発生する原因となっていました。

今回のリリースでは、virtual_interfaces テーブルに欠如していたインデックスが追加され、virtual_interfaces テーブル内のデータが増大しても、パフォーマンスに大きな悪影響を及ぼさないようになりました。

ホスト PCI デバイスが割り当てられたゲストにインテリジェントな NUMA ノードを配置するサポートが追加されました。ネットワークインターフェースカード (NIC) などの PCI I/O デバイスは、他のプロセッサーと比べ、1 つのプロセッサーとの関連付けをより密接にすることができます。1 つのプロセッサーに直接接続されているメモリーにアクセスする場合と、同じサーバー内にある別のプロセッサーに直接接続されているメモリーにアクセスする場合とでは、メモリーのパフォーマンスやレイテンシーの特性が異なるため、この機能は重要です。今回の更新では、ゲストの物理 CPU とメモリーの確保が関連付けられた NUMA ノード上で、PCI デバイスにバインドされたゲストが実行されるようにスケジューリングすることで、OpenStack のゲストの配置を最適化することができます。たとえば、ゲストのリソース要件が単一の NUMA ノードに適合する場合には、すべてのゲストリソースが同じ NUMA ノードに関連付けられるようになりました。

Red Hat Enterprise Linux OpenStack Platform バージョン 6 から 7 に完全にアップグレードした後 (全ノードがバージョン 7 のコードを実行している場合) には、PCI デバイスの NUMA ノードの情報を古い場所から新しい場所に移動するバックグラウンド移行を開始する必要があります。バージョン 7 のコンダクターノードは、必要な場合にこの操作を自動的に行いますが、それ以外のアイドルデータはバックグラウンドで移行する必要があります。バージョン 8 リリースでは、古い場所がサポートされなくなるので、その前に移行を完了しておくことが極めて重要です。この移行の操作を実行するには、「nova-manage migrate-rhos-6-pci-device-data」を使用します。
これは、Compute の PCI パススルー機能を利用するユーザーのみに該当する点に注意してください。

以前のリリースでは、staypuft/openstack-foreman-installer で設定された nova-network のコンピュートノード上でインスタンスの起動を試みるとエラーが発生していました。この問題は、インストーラーにパッケージ conntrack-tools が含まれていなかったことが原因でした。

今回のリリースではこのバグが修正され、nova-network サービス用の conntrack-tools パッケージをインストールするための行を openstack-nova.spec に追加することによって修正されました。nova-network はネットワークの設定ができるようになり、エラーは発生しなくなりました。

以前のリリースでは、Cinder iSCSI ボリュームのプライマリーパスが停止していると、Compute および Block Storage バックエンドのドライバーでマルチパス機能が有効化されている場合でも、ボリュームをインスタンスにアタッチできませんでした。このため、クラウドシステムのユーザーがボリュームのアタッチ(またはボリュームから起動するサーバーのブート) に失敗する可能性がありました。

今回の修正により、ブロックトラフィックが別のネットワーク上にある場合には、ホストが別の設定を使用できるようになったため、ボリュームはセカンダリーパスを使用してアタッチされるようになりました。

IPv6 を使用する OpenStack 環境をデプロイする際には、VNC コンソールが読み込みに失敗し、クライアントに対して例外が発生していました。これは、websocketproxy が「handler exception: Origin header does not match this host.」という origin ヘッダーを検証できないことが原因でした。

今回のリリースでは、websocketproxy 内のコードが更新され、IPv6 に対応するようになりました。その結果、IPv6 を使用するように全サービスが設定されている場合でも、ユーザーが VNC コンソールに正常に接続できるようになりました。

以前のリリースでは、neutron と併用している場合に、nova 内の仮想マシンの退避を試みると、ポートバインディングの更新が失敗するため、エラーが発生していました。nova-network 用に設定した Floating IP の設定でも同様の問題が発生していました。このため、必要な仮想インターフェースの作成が失敗し、仮想マシンを退避することができませんでした。 

今回の修正で、nova はいずれタイプのネットワーク構成でも、仮想マシンを正しく設定できるようになり、仮想マシンの退避が正常に実行できるようになりました。

libvirt ドライバーは、libguestfs を使用して特定のゲストの検査や変更のタスクを行っていましたが、libguestfs は外部ライブラリーなので、eventlet のモンキーパッチでは更新されませんでした。このため、libguestfs の API 呼び出し中には、eventlet のグリーンスレッドが実行されず、openstack-nova-compute サービスは、呼び出しの間中、完全にハングしていました。インストールまたはシステム更新後の libguestfs への初回の呼び出しは数秒かかり、その間 openstack-nova-compute は応答なしの状態となっていました。

今回のリリースで、libguestfs への呼び出しは別の非 Eventlet スレッドプールにプッシュされるようになりました。それらのコールは非同期で実行され、openstack-nova-compute の応答状態には影響を及ぼさないようになりました。

以前のリリースでは、正しいデータバージョン管理が使用されていなかったため、PCI デバイスのデータモデルが誤った形式で送信されていました。このため、PCI パススルーデバイスが許可リストに含まれている場合には、openstack-nova-compute サービスが起動できませんでした。

今回のリリースでは、正しいデータバージョン管理が採用されたため、openstack-nova-compute は起動可能となり、許可リストに任意の PCI デバイスを登録することができます。

この機能により、Packstack に IPv6 サポートが追加され、Packstack は CONFIG_COMPUTE_HOSTS、CONFIG_NETWORK_HOSTS などのネットワーク関連のパラメーターの値に IPv6 アドレスを使用できるようになりました。

以前のリリースでは、puppet-neutron で neutron の dhcp_domain 設定のカスタマイズはできませんでした。このため、オーバークラウドノードには、アンダークラウドの DHCP により、無効なドメインサフィックスが提供されていました。今回の更新では、neutron の dhcp_domain 設定が構成可能となり、ドメインサフィックスのデフォルトは空となりました。

以前のリリースでは、Telemetry Service の HAProxy 設定に誤ったチェックが使用されていました。そのため、Telemetry Service は HA デプロイメントに失敗していました。具体的な原因は、HAProxy 設定に可用性チェックが含まれず、TCP の代わりに SSL チェックを誤って使用していたことでした。

今回のリリースでは、チェックが修正されたので、Telemetry Service は正しくバランスを取れて、HA デプロイメントを起動できるようになりました。

director は、アンダークラウドで SSL を有効化して Bare Metal Service および Telemetry Service をデプロイする際に、誤った HAProxy 設定を使用します。このため、一部のノードが登録できません。 

この問題を回避するには、アンダークラウドのインストール後に /etc/haproxy/haproxy.cfg の Bare Metal および Telemetry のセクションで「option ssl-hello-chk」をコメントアウトしてください。

今回の機能拡張で、HDP 2.0.6 プラグインでサポートされるオプションとして、namenode の高可用性が追加されました。
ユーザーは、クラスターが HA モードで生成される必要があることを通知することができます。これは、zookeeper サーバーと journalnodes の定足数と最小で 2 つの namenode を備えたクラスターを渡すことによって可能となります。以下に例を示します。
"cluster_configs": {
   "HDFSHA": {
      "hdfs.nnha": true
   }
}

今回の機能拡張により、Sahara API で HTTPS プロトコルが完全にサポートされるようになりました。

今回の更新の以前は、Sahara の「分散」モード機能はアルファテスト中でした。このため、Red Hat Enterprise Linux OpenStack Platform では、「sahara-api」や「sahara-engine」のプロセスの個別のパッケージとサポートは提供していませんでした。
今回の更新では、「分散」モード機能が安定した状態であると判断され、RHEL OpenStack Platform は「sahara-api」および「sahara-engine」サービスの systemd のユニットファイルを提供するようになりました。 
その結果、ユーザーは、API とエンジンノードクラスターを分離して、Sahara を分散モードで実行することができます。

Sahara のオブジェクトは、任意のフィールド名でクエリーできるようになりました。これは、List メソッドに表示される API フィールド名と一致する GET パラメーターを使用して実行します。

今回の機能拡張により、各主要プラグインでデフォルトのクラスターテンプレートの設定が可能な CLI が追加されました。デフォルトテンプレートを提供することにより、エンドユーザーによる Sahara の導入が迅速化/円滑化されます。
この更新の結果、管理者は共有デフォルトテンプレートを追加して、顧客がそれを適用し、直接使用することができるようになりました。

Integration tests for Sahara の統合テストは、不安定で単純な python テストからリファクターされ、容易な YAML ベースの設定で「シナリオ」を定義できるようになりました。

今回の更新の以前は、Cloudera はどの Linux ディストリビューションにも cm_api ライブラリーを同梱していませんでした。CDH プラグインはこのパッケージに依存していたため、以前のリリースでは、CDH をデフォルトのプラグインとして有効化することはできませんでした。今回のリリースでは、Sahara のコードベースに cm_api ライブラリーのサブセットが追加されて CDH が機能するようになり、デフォルトで有効化されるようになりました。

以前のリリースでは、クラスターの作成で多数のプロセスが無限にポーリングされていました。今回のリリースでは、クラスターの作成と操作の多数の段階にタイムアウトが追加され、十分な時間が経過してもクラスターの操作が完了しない場合には、ユーザーにエラーメッセージが表示されます。

Sahara に新しいエンドポイントが追加され、Sahara インストールがサポートするプラグインとバージョンごとに利用可能なジョブタイプをクエリーできるようになりました。この情報は、UI の提示とフィルタリング、ならびにCLI および REST API ユーザーに有用です。

今回のリリースの以前は、Sahara の「分散」モードがアルファテスト中だったため、Red Hat Enterprise Linux OpenStack Platform は sahara-api と sahara-engine プロセスを個別のパッケージとサポートは提供していませんでした。今回の更新では、この機能が安定し、RHEL OpenStack Platform は sahara-api および sahara-engine サービスの systemd ユニットファイルを提供するようになり、ユーザーは API とエンジンノードクラスターを分離して、Sahara を分散モードで使用することができます。

以前のリリースでは、HDP プラグインと saraha-image-elements パッケージは、Extra Packages for Enterprise Linux (EPEL) リポジトリーを何の目的にも使用していないにもかかわらず、クラスターの作成時に、HDP プラグインにより、このリポジトリーがインストールされていました。このため、潜在的にエラーが発生しやすい不要なステップが HDP のクラスター作成に組み込まれ、更新時には、それらのクラスターでサポート対象外のパッケージが更新されてしまう可能性がありました。今回のリリースでは、このリポジトリーは、HDP プラグインによりインストールされなくなりました。

Red Hat での OpenStack の現在の基準内でサイズ制限を強制する logrotate ファイルが追加され、ローテーションされる前にログファイルのサイズが大きくなり過ぎないようになりました。

今回の更新の以前は、HDP の NameNode HA は、アップストリームでの機能完成後に正常に機能していましたが、 Sahara が引き続き、全ジョブで Oozie を単一の NameNode IP アドレスにポイントしていました。
そのため、Oozie と Sahara の EDP は、1 つの任意のノードが (A/P HA モデルで) アクティブに指定されている場合にのみ成功していました。
今回の更新では、Oozie を 1 つの任意の namenode にではなく、nameservice にダイレクトすることによって、この問題に対処しました。
その結果、どの NameNode がアクティブかにかかわらず、Oozie および EDP のジョブが正常に実行されるようになりました。

今回の更新の以前は、Neutron は使用を許可されていないポートへのバインディングを試みていました。そのため、SELinux によって Neutron の動作が妨げられていました。今回の更新により、Neutron は確保されていないポートに接続できるようになり、問題なく稼働するようになりました。

以前のリリースでは、Neutron の VPN エージェントが誤ったコンテキストで起動されていました。そのため、VPN エージェントの動作が SELinux によって妨げられていました。今回の更新では、Neutron VPN エージェントは適切なコンテキストを使用するようになり、その結果、Enforcing モードで稼働できるようになりました。

OpenStack Trove のインスタンスは、OpenStack Dashboard のユーザーインターフェースでそのインスタンス用の新規フレーバーを選択することによって、リサイズできるようになりました。

ダッシュボードの「API Access」のページ (「プロジェクト> コンピュート > アクセスとセキュリティー > API アクセス」) にユーザーの認証情報の詳細が表示されるようになりました。この情報を表示するには、「認証情報を表示」をクリックします。ポップアップウィンドウにユーザー名、プロジェクト名、プロジェクト ID、認証 URL、S3 URL、EC2 URL、EC2 アクセス、および秘密鍵が表示されます。

OpenStack Dashboard の「ボリューム」タブに Block Storage (cinder) ボリュームの譲渡を作成するオプションが追加されました。ボリュームの譲渡により、プロジェクト間で所有権が移行します。譲渡元はボリュームの譲渡を作成し、生成される譲渡 ID と秘密の認証キーを取得して、その情報をアウトオブバンドで認証先に渡します (例: メールやテキストメッセージなどを利用)。譲渡先は譲渡 ID と認証キーを提供して譲渡を受理します。ボリュームの所有権は譲渡元から譲渡先に譲渡され、ボリュームは譲渡元に対しては表示されなくなります。

ボリュームの譲渡において Block Storage API には以下のような制限事項があり、UI 設計に影響を及ぼしている点に注意してください。
1. ボリュームの譲渡を作成する際には、譲渡先を指定することはできず、譲渡 ID と認証キーがあれば、誰でもそのボリュームを要求することができます。そのため、ダッシュボードの UI は、譲渡先の入力は求めません。
2. 現行のボリューム譲渡は、譲渡元にのみ表示されます。他のプロジェクトのユーザーは、譲渡を表示することはできません。そのため、現行の譲渡は表示されないので、UI には、ボリュームの譲渡を表示して受理するためのプロジェクトの表はありません。その代わりに、譲渡情報はボリュームの詳細に追加され、譲渡元には表示されます。ボリュームの状態には、譲渡が作成されたことが明確に反映されます。また、UI では、受理する譲渡のプルダウンリストも譲渡先に表示されません。
3. 譲渡の作成からの応答でのみ、承認キーが譲渡元に表示されます。作成後には、譲渡元でもその情報を取り戻すことはできません。譲渡元は譲渡 ID と承認キーを取得して譲渡先に送信する必要があるため、この情報を譲渡作成直後に譲渡元に対して表示するための追加のフォームが作成されました。

OpenStack Dashboard は、Block Storage (cinder) バージョン 2 を推奨バージョンとして使用するようになりました。
Block Storage クライアントが要求されると、指定がない場合には、cinder バージョン 2 を使用してアクセスが提供されます。

さまざまなリソースタイプ (イメージ、アーティファクト、ボリューム、フレーバー、アグリゲーションなど) に使用できるメタデータの定義を表示、インポート、関連付けすることができるようになりました。

OpenStack Dashboard では、インスタンスの詳細ページにホストノードが表示されるようになりました。このデータは、問題の診断に役立てることを目的としています。

今回の更新では、 OpenStack Dashboard にドメイン管理者が部分的にサポートされるようになりました。また、Identity Service (keystone) バージョン 3 を使用する場合には、新規作成するユーザーにプライマリープロジェクトを指定する必要はありません。

Dashboard を使用してコンピュートホストの有効化/無効化ができるようになりました。この機能は、「管理 > ハイパーバイザー > コンピュートホスト」で各コンピュートホストの「アクション」コラムから実行することができます。

コンピュートホストを無効にすると、スケジューラーがそのホストを使用してインスタンスを起動するのを防ぐことができます。

OpenStack Dashboard の「ボリューム」タブに「管理/管理解除」のオプションが追加されました。「管理」を選択すると、OpenStack の外部で作成された既存のボリュームを取得して利用できるようになります。「管理解除」を選択すると、OpenStack 内でボリュームが表示されなくなりますが、実際ボリュームが削除されるわけではありません。

Dashboard で利用できる OpenStack Orchestration Service (heat) のユーザーインターフェースのオプションが改善されました。たとえば、ユーザーはスタックのチェック、一時停止、再開、プレビューを行うことができます。

Data Processing Service のテーブルに表示される結果のフィルタリングが可能となり、ユーザーは該当する結果のみを表示できるようになりました。

Dashboard でボリュームが「起動可能」かどうかのフラグが表示されるようになりました。

OpenStack Dashboard はカスタムのテーマを使用できるようになりました。新しい設定「CUSTOM_THEME_PATH」が /etc/openstack_dashboard/local_settings ファイルに追加されました。このテーマフォルダーには、 _variables.scss ファイルが 1 つと、_styles.scss ファイルが 1 つ含まれているはずです。_variables.scss ファイルには、ブートストラップとグラフィカルユーザーインターフェースのスタイル指定に必要な Horizon 固有の変数がすべて含まれています。また、_styles.scss ファイルには、追加のスタイル指定が含まれます。

OpenStack Dashboard で SRIOV を設定できるようになりました。オプションには「ポートの詳細」タブにさらなる情報を表示する機能や、ポート作成/更新時にポートの種別を選択する機能が含まれます。

今回の機能拡張により、OpenStack Dashboard (horizon) で暗号化されたボリュームのメタデータを表示できるようになりました。暗号化メタデータを表示するための機能が追加され、ユーザーは暗号化のコラムで「はい」をクリックすると、暗号化メタデータを確認できるページが開きます。

Dashboard を使用してイメージをアップロードする場合には、形式に OVA を選択できるようになりました。以前のリリースでは、このオプションで OVA は選択できませんでした。

Dashboard は、OpenStack Data Processing 機能に必要なコンポーネントの作成および設定を行うためのウィザードを提供するようになりました。このウィザードは、クラスターの作成やジョブの実行などの手順をユーザーに順を追って案内するのに役立ちます。ウィザードを使用するには、「プロジェクト > データ処理 > ガイド」の順でクリックしてください。

今回の機能拡張により、OpenStack Dashboard に、ceilometer IPMI メーターが追加されました。 
 ipmi メーターは、ceilometer からエクスポートされたもので、メソッド「list_ipmi」および「_get_ipmi_meters_info」を使用して計測データを取得します。

Dashboard で Orchestration Service のホストについての詳細情報を確認できるようになりました。「管理 > システム > システム情報 > Orchestration Service」の順で進むと表示することができます。このページは、Orchestration Service がデプロイされている場合にのみ利用できます。

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

以前のリリースでは、ノードがロックされた状態で OpenStack Bare Metal Provisioning (Ironic) の特定の操作を実行するとエラーが発生していました。
今回の更新では、Ironic クライアントに「再試行」の機能が実装されました。その結果、特定の操作には時間が長くかかりますが、ノードがロックされているためにエラーが発生することはなくなりました。

python-openstackclient パッケージがアップストリームのバージョン 1.0.3 にリベースされました。今回のリベースは、Identity Service の v3 API のサポートに関連した機能の修正と拡張を特長とします。

セクター数の多い仮想ディスク上では、セクター数の処理が適切に行われない場合があり、QEMU イメージの変換が「invalid argument」のエラーで失敗していました。今回の更新では、エラーの原因となっていた誤算問題が解決され、操作が失敗することはなくなりました。

ポータブルメモリーバリアが正しく実装されていなかったため、仮想ディスクに対する I/O 負荷が高くなると、QEMU エミュレーターが予期せずに終了する場合がありました。今回の更新では、この実装が修正され、QEMU スレッド間で正しく同期が行われるようになりました。その結果、そのようなクラッシュが発生することはなくなりました。

このパッケージより、ユーザーは RHEL OpenStack Platform 7 で使用する HDP 2.0.6 および CDH 5.3.0 イメージを作成できます。

以前のリリースでは、イメージ作成ラッパースクリプトが指定する領域がシステムによっては CDH イメージの生成には小さすぎることが理由で、CDH イメージの生成でエラーが発生することがありました。今回のリリースでは、CDH イメージ用のイメージ生成のスペースが拡大され、イメージの生成を正常に行うことができるようになりました。

Pacemaker ノードで sosreport ユーティリティーを使用する際には、MariaDB MySQL サーバーのログファイルが正しく収集されませんでした。今回の更新では、基になるコードが修正され、ログファイルは想定どおりに収集されるようになりました。

以前のリリースでは、 sosreport ユーティリティー用のさまざまな OpenStack プラグインがパスワードの収集を誤ってプレーンテキストで行っていました。そのため、sosreport を使用した後に作成された圧縮ファイルには、人間が判読可能なパスワードが記載されている可能性がありました。今回の更新により、sosreport OpenStack プラグインに全パスワードの難読化が実装され、sosreport tarball 内の対象のパスワードは人間による判読は不可能になりました。