リリースノート Red Hat OpenStack Platform 8

互換モード

# subscription-manager repos --enable=[reponame]
# subscription-manager repos --disable=[reponame]
この機能により、デプロイしたオーバークラウドに Puppet マニフェストを再度適用することができるので、オーバークラウドには必要な設定が確保され、設定ファイルを誤って変更または削除してしまった場合に復旧することができます。

オーバークラウドノードで Puppet を再度実行するには、「--templates」オプションを省略し、デプロイメントの最初に以下の 2 つの環境ファイルを指定します。

* /usr/share/openstack-tripleo-heat-templates/overcloud-resource-registry-puppet.yaml
* /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration/rhel-registration-resource-registry.yaml

以下に例を示します。

$ openstack overcloud deploy -e ~/templates/overcloud-resource-registry-puppet.yaml -e ~/templates/extraconfig/pre_deploy/rhel-registration/rhel-registration-resource-registry.yaml [additional arguments from initial deployment]
今回の更新で、ネストされたクォータが導入されました。デプロイ担当者は、CInder で親プロジェクトから継承されたサブプロジェクトを使用することで、階層のあるクォータを管理できるようになりました。
多様なストレージバックエンドを使用するデプロイメントで管理者がより柔軟に操作を実行できるようにするために、Block Storage は QoS、圧縮、レプリケーション、帯域幅の制御、シンプロビジョニングなどのケイパビリティーの標準名を定義できるようになりました。これは、変更なしに複数のドライバーで機能するボリューム種別の仕様を定義できることを意味します。
以前のリリースでは、Dell Jetstream により RGW パッケージが Red Hat OpenStack Platform コントローラーノードにデプロイされ、この機能を利用できるようにするには、RGW パッケージを手動でコピーする必要がありました。

今回のリリースでは、RGW パッケージはオーバークラウドのフルイメージに事前にインストールされるので、RGW のコンポーネントに必要な操作は単に設定と起動するだけとなり、OpenStack のコントローラーノードへの RGW のデプロイが容易に実行できるようになりました。
OpenDaylight OpenStack neutron ドライバーは、neutron プロジェクトから分離して、新たなパッケージ python-networking-odl に移動しました。オペレーターは、このドライバーを引き続き Red Hat OpenStack Platform インストール環境の一部として使用することができます。
今回の更新で、タイムアウトを指定するための設定が追加されました。タイムアウトするまでに「Active」な状態にならなかったクラスターは自動的に削除されます。
今回の更新により Image サービス (glance) によってホストされる共通の API が追加されました。これにより、ベンダー、管理者、サービス、ユーザーは利用可能なキー/値のペアおよびタグのメタデータを意味があるように定義することができます。これは、OpenStack ユーザーのために、アーティファクト、サービス、プロジェクト全体にわたるコラボレーションを向上させることが目的です。
この定義は、異なる種別のリソース (イメージ、アーティファクト、ボリューム、フレーバー、アグリゲートなど) に利用可能なメタデータを記述します。定義には、プロパティーの種別、キー、説明、制限などが含まれます。このカタログは、特定のインスタンスのプロパティーには値を保存しません。
たとえば、多数のコアの仮想 CPU トポロジーのプロパティーの定義には、使用するキー、説明、値の制限 (整数を指定する必要があるなど) が含まれます。その結果、ユーザーは (Dashboard を使用可能) このカタログを検索し、フレーバーやイメージに追加することのできる利用可能なプロパティーを一覧表示することができます。ユーザーは、一覧に表示される仮想 CPU トポロジーのプロパティーを確認すると、整数を指定する必要があることがわかります。Dashboard の例では、ユーザーがプロパティーを追加すると、キーと値は、そのリソースを所有するサービス (フレーバーは nova、イメージは glance) に保管されます。
メンテナンス中のホストからインスタンスのコールドマイグレーションまたはライブマイグレーションができるようになりました。Dashboard の システム > ハイパーバイザー > コンピュートホストタブの新しいアクションボタンで、管理ユーザーはインスタンスのマイグレーションのオプションを設定することができます。

コールドマイグレーションのオプションを選択すると、インスタンスは別のホストに移行されて再起動します、移行先はスケジューラーによって選択されます。このタイプのマイグレーションは、管理ユーザーが Dashboard で「live_migrate」オプションを選択していない場合、または移行するインスタンスが稼働中でない場合に使用する必要があります。

ライブマイグレーションのオプションを選択すると、インスタンス ("Power state" = "active") はホスト間で移行されますが、再起動はしません。移行先は任意です (管理ユーザーによる定義またはスケジューラーによる選択が可能)。このタイプのマイグレーションは、管理ユーザーが Dashboard で「live_migrate」オプションを選択している場合、または移行するインスタンスがまだ稼働中の場合に使用する必要があります。
director では、オーバークラウドに Firewall-as-a-Service エージェントはインストールされません。この機能は director の今後のリリースで実装される予定です。
「neutron router-gateway-set」コマンドが「--fixed-ip」オプションをサポートするようになりました。このオプションにより、外部ネットワークで使用する Fixed IP アドレスとサブネットを設定することができます。この IP アドレスは、OpenStack Networking サービス (openstack-neutron) がソフトウェアレベルのインターフェースに接続して、テナントネットワークを外部ネットワークに接続するのに使用されます。
今回の機能拡張により、ノードごとに hieradata を配置して、UUID (「dmidecode」で報告される) からノードを照合できるようになりました。
これにより、異なる数および種別のディスクを搭載した複数のノードにわたって CephStorage をスケーリングすることが可能です。
その結果、CephStorage ノードは、同種でないディスクのトポロジーで設定することが可能となりました。これは、ceph::profile::params::osds パラメーターに異なる設定ハッシュをプロビジョニングして設定します。
今回のリリースでは、セキュリティーの分離を提供するために、「/usr/local」のパスがデフォルトの Block Storage の rootwrap の設定から削除されました。その結果、「/usr/local/」から「root」ユーザーとしてコマンドを実行する Block Storage サービスに依存するデプロイメントは、そのコマンドが機能するための設定を追加する必要があります。
OpenStack Dashboard のテーブルには、多数のエンティティーについての情報のサマリーが表示されます。今回の更新で、テーブルの機能が拡張され、テーブル内で情報がスライドダウン式の「ドロワー」として表示されるようになりました。これは、その行内で切り替えスイッチをクリックすると有効になります。ドロワーは追加の行として表示され (高さを設定可能)、その行のエンティティーの追加情報が含まれます (例: 追加のエンティティー情報、メトリック、グラフなど)。一度に複数のドロワーを開くことが可能です。
今回の更新により、Dashboard (horizon) が IPv6 アドレスを仮想 IP アドレスとしてロードバランシングプールに受け入れるようになりました。その結果、Dashboard を使用して、ロードバランシングプール上の IPv6 アドレスを設定することができます。
今回の更新で、Block Storage (cinder) サービスのボリューム移行がサポートされるようになりました。この操作は OpenStack Dashboard の「Volumes」パネル (プロジェクト-> コンピュート -> ボリュームと、管理-> システムパネル-> ボリューム) で、表内の「ボリューム」の行で実行できます。
このシリーズの最終パッチで、コマンドのアクション自体の問題 (以前のリリースでは、パラメーターの誤りとパラメーターカウントの問題が原因でエラーが発生していました) も解決されました。
director はオーバークラウドに Load Balancing-as-a-Service エージェントをインストールしません。この機能は、director の今後のリリースで実装される予定です。
今回の更新で「Launch Instance」のワークフローが再設計/再実装され、応答性が向上しました。

1. この更新を有効にするには、以下の値を /etc/openstack-dashboard/local_settings ファイルに追加します。

LAUNCH_INSTANCE_LEGACY_ENABLED = False
LAUNCH_INSTANCE_NG_ENABLED = True

2. 「httpd」を再起動します。
# systemctl restart httpd
再利用するためのジョブテンプレートを作成する場合には、 OpenStack Data Processing (sahara) でデータソースの URL の変数を登録することができるようになりました。この登録により、実際の URL 変更 (その場合はテンプレートの編集や、ジョブ間で実行ごとに URL の変更が必要) ではなく、実行ごとに入出力パスを容易に変更することができます。

これにより、データソースジョブが実行ごとに可変の場合 (実際の利用環境の大半が該当) に、ジョブテンプレートを容易に再利用できるようになりました。
今回のリリースでは、パネルが設定可能になりました。設定スニペットを使用して、パネルを追加/削除することができます。

たとえば、「リソースパネル」削除するには、以下のように設定します。

* 「/usr/share/openstack-dashboard/openstack_dashboard/local/enabled」にファイルを配置します。
* そのファイルに「_99_disable_metering_dashboard.py」という名前を付けます。
* 以下のコンテンツをそのファイルにコピーします。

# The slug of the panel to be added to HORIZON_CONFIG. Required.
PANEL = 'metering'
# The slug of the dashboard the PANEL associated with. Required.
PANEL_DASHBOARD = 'admin'
# The slug of the panel group the PANEL is associated with.
PANEL_GROUP = 'admin'
REMOVE_PANEL = True

* Restart the Dashboard httpd service:
# systemctl restart httpd

詳しい説明は、https://access.redhat.com/documentation/en/red-hat-enterprise-linux-openstack-platform/ で提供しているRed Hat OpenStack Platform ドキュメントスイートの『Configuration Reference Guide』の「Pluggable Dashboard Settings」のセクションを参照してください。
今回の機能拡張により、イメージ ID またはイメージ名のいずれかを指定して、Block Storage (cinder) を使用したボリューム作成ができるようになりました。
今回の機能拡張により、新たにスケーリングされたバックエンドのレプリケーション実装 (バックエンド間) が追加されました。作業の大半はドライバーに任されますが、基本的な管理 API メソッドが提供されます。この機能は、レプリケーションがボリューム種別レベルで設定されている場合に、cinder ドライバーがそのケイパビリティーを報告する際に利用することができます。以下の新規オプションが利用できるようになりました。
replication_enabled: True に設定します。
replication_type: async、sync
replication_count: レプリカ数
今回の更新で、Block Storage の「snapshots-list」および「backups-list」のコマンドでペジネーションの新機能が追加され、パラメーターを制限、マーカー、ソートして返される結果数、開始する要素、およびその順序を制御することができるようになりました。

何千にもおよびスナップショットやバックアップのある大型デプロイメントでは、データセット全体ではなく限定された数の結果を取得する方法が非常に役立ちます。
今回のリリースでは、glance イメージのイメージ署名/検証の機能をテクノロジープレビューとして提供しています。この機能は、ユーザーがイメージをアップロードした後に変更されないようにすることでイメージの整合性を保護します。この機能により、イメージに署名し、起動可能なイメージを使用する際に署名を検証することができます。
今回の更新では、neutron QoS (Quality of Service) の機能拡張により、テナントネットワークの品質と制限に対する制御が向上しました。オーバークラウドは Neutron QoS の機能拡張が有効な状態でデプロイされるようになりました。
今回の機能拡張により、Object Storage (swift) に cinder ボリュームをバックアップするのと同じユーザーインターフェースを使用して、Block Storage (cinder) ボリュームをバックアップできるようになりました。
この機能は、Ceph がすでに使用されている場合に、第 2 のオブジェクトストアの必要性を回避するために拡張されました。
以前のリリースでは、HA または DVR のどちらでもないルーターを HA ルーターに変換することはできませんでした。代わりに、新規ルーターを作成して、全リソース (インターフェース、ネットワークなど) を古いルーターから新しいルーターに再接続する必要がありました。今回の更新では、簡単なコマンドを実行して、レガシーのルーターを HA または非 HA ルーターに変換できる機能が追加されました。

# neutron router-update ROUTER --admin-state-up=False
# neutron router-update ROUTER --ha=True/False
# neutron router-upgrade ROUTER --admin-state-up=True

ROUTER は、変換するルーターの ID または名前に置き換えてください。
以前のネットワークトポロジーの UI は、ノードやネットワークの数が多くなると適切に機能しなかったため、今回の更新で、曲率ベースのグラフに変更されました。 

新しいネットワークトポロジーマップは、より多くのノードに対応できる上、外観もスタイリッシュで、ノードのレイアウトを再構成することが可能です。
以前のバージョンでは、プライベートネットワーク内の S3 バックエンドにリモートでセキュアにアクセスする方法がありませんでした。

今回の更新で、新たな機能が追加され、Image サービスの S3 ドライバーは、HTTP プロキシーを介して、別のネットワークから S3 バックエンドにセキュアに接続できるようになりました。
今回の更新では、API ワーカープロセスカウントに新たなパラメーターが追加され、オーバークラウドのメモリー使用を微調整し、処理能力を要求することができます。追加されたパラメーターは、CeilometerWorkers、CinderWorkers、GlanceWorkers、HeatWorkers、KeystoneWorkers、NeutronWorkers、NovaWorkers、SwiftWorkers です。
今回の更新で、Ceilometer がイベントを保管するためのオプションが追加されました。保管されたイベントは、後で Ceilometer API を使用して取得することができます。これは、メッセージバスをリッスンしてイベントをキャプチャーする代わりとなる機能です。設定についての簡単な説明は、https://bugzilla.redhat.com/show_bug.cgi?id=1318397 に記載しています。
Nova のインスタンス向けシリアルコンソール API が開示されるようになりました。シリアルコンソールは、VNC や SPICE をサポートしていないハイパーバイザーでも利用できます。今回の更新では、この機能がダッシュボードでサポートされるようになりました。
Block Storage サービスがイメージからボリュームを作成する場合には、イメージを Image サービスからからイメージ変換ディレクトリーにダウンロードします。このディレクトリーは、/etc/cinder/cinder.conf の「image_conversion_dir」オプション ([DEFAULT] セクション下) で定義します。デフォルトでは、「image_conversion_dir」は /var/lib/cinder/conversion に設定されます。

イメージ変換ディレクトリーが容量不足になると (一般的には、大型のイメージから複数のボリュームが同時に作成される場合など)、イメージからボリュームの作成を試みても失敗してしまいます。 さらに、イメージからのボリューム作成が必要なインスタンスの起動を試みた場合にも操作は失敗します。このようなエラーは、イメージ変換ディレクトリーに十分な空き容量ができるまで続きます。 

そのため、イメージ変換ディレクトリーには、ユーザーがイメージから同時に作成するボリュームの標準的な数に十分な容量を確保すべきです。デフォルト以外にイメージ変換ディレクトリーを定義する必要がある場合には、以下のコマンドを実行してください。

    # openstack-config --set /etc/cinder/cinder.conf DEFAULT image_conversion_dir <NEWDIR>

<NEWDIR> は新規ディレクトリーに置き換えます。この操作が完了したら、Block Storage サービスを再起動して、新しい設定を適用します。

    # openstack-service restart cinder
今回のリリースでは、Dashboard (horizon) の「Metering」パネル は、パフォーマンスの問題により無効になっています。
Open vSwitch (openvswitch) のパッケージがアップストリームのバージョン 2.4.0 にリベースされました。
swift のプロキシーポートは、アンダークラウドのファイアウォールで拒否されます。これは、swift プロキシーがローカルホストからの接続のみを受け入れることを意味します。回避策として、ファイアウォールで swift のプロキシーポートを開放します。

# sudo iptables -I INPUT -p tcp --dport 8080 -j ACCEPT

これで、リモートマシンからの swift プロキシーへの接続が有効になります。
プロビジョニングネットワークで IP アドレスの競合が確認された場合に発生する可能性のある既知の問題があります。この問題により、使用済みの IP アドレスが割り当てられたホストでは、検出やデプロイのタスクが失敗します。
この問題は、プロビジョニングネットワークのポートスキャンを実行することで、回避することができます。アンダークラウドノードから実行すると、検出で使用される IP アドレスとホストの IP アドレス範囲は割り当てのために利用可能かどうかを確認するのに役立ちます。 このスキャンは、nmap ユーティリティーを使用して実行することができます。以下に例を示します (ネットワークは、サブネットのプロビジョニングネットワークネットワークに CIDR 形式で置き換えます):
----
$ sudo yum install -y nmap
$ nmap -sn 192.0.2.0/24
----
その結果、使用中の IP アドレスが undercloud.conf の IP アドレス範囲と競合する場合には、イントロスペクションプロセスを実行する前またはオーバークラウドノードをデプロイする前に、その IP アドレスの範囲を変更するか、IP アドレスを解放する必要があります。
Glance で、glance.store.http.Store は、/etc/glance/glance.conf に known_store として設定されていないため、Glance クライアントで --copy-from 引数を使用してイメージを作成することはできません。このコマンドを実行すると、「400 Bad Request」エラーが表示されて操作が失敗します。回避策として、/etc/glance/glance-api.conf を編集して、「store」設定オプションのリストに glance.store.http.Store を追加してから、openstack-glance-api サーバーを再起動します。これにより、--copy-from 引数を使用した Glance イメージの作成を正常に実行できるようになります。
現在、特定の設定ステップにはオーバークラウドコントローラーに SSH 接続する必要があり、オーバークラウドノードに到達するには、仮想 IP を通過する必要があります。
お使いの環境で外部のロードバランサーを使用している場合には、このステップで接続は成功しない可能性が高くなります。この問題を回避するには、外部のロードバランサーがポート 22 を転送するように設定すると、仮想 IP へ正常に SSH 接続できるようになります。
アンダークラウドのインストーラーは、以下のハードコードされたファイルパスを使用します。

* undercloud.conf は ~/undercloud.conf にハードコード
* instack.answers は ~/instack.answers にハードコード
* tripleo-undercloud-passwords は ~/tripleo-undercloud-passwords にハードコード
* install-undercloud.log は ~/.instack/install-undercloud.log にハードコード

これらのファイルは必ず存在している必要があります。存在しない場合には、アンダークラウドのインストールは失敗します。
現在、director がパブリック API に接続して最終の設定のデプロイ後のステップを完了するのに必要となる既知の要件があります。この要件は、アンダークラウドノードにはパブリック API へのルートが 1 つあることと、そのルートが標準の OpenStack API ポートおよびポート 22 (SSH) で到達可能である必要があることです。
この要件に対応するには、デプロイ後のタスクで使用するコントローラー上の外部ネットワークにアンダークラウドが到達可能かをチェックしておいてください。 このような準備をしておくことにより、アンダークラウドはデプロイ後にパブリック API に正常に接続して、最終の設定タスクを実行することができます。これらのタスクは、admin アカウントを使用して新規作成したデプロイメントを管理するのに必要です。
セキュリティー上の理由により、オーバークラウドではデフォルトで SSH キーベースのアクセスのみが許可されてます。virt-customize ツールを使用すると、オーバークラウドのディスクイメージで root パスワードを設定することができます。このツールは、Red Hat Enterprise Linux Extras チャンネルで提供しています。ツールをインストールし、オーバークラウドのイメージをダウンロードした後には、以下のコマンドを実行して root パスワードを変更します。

$ virt-customize -a overcloud-full.qcow2 --root-password password:<my_root_password>

この操作は、「openstack overcloud image upload」コマンドで glance にイメージをアップロードする前に実行してください。
controller_v6.yaml テンプレートには、管理ネットワークの VLAN 用のパラメーター 1 つ含まれています。このパラメーターは、現在のバージョンの director ではサポートされていないので、管理ネットワークに関する他のコメントとともに無視しても安全です。管理ネットワークの参照は、カスタムテンプレートにコピーする必要はありません。

このパラメーターは将来のバージョンでサポートされる予定です。
番号付きの NIC のエイリアス (nic1、nic2 など) に数えられるのは、スイッチポートへの有効な接続がある NIC のみです。回避策として、director には各ノードから全インターフェース上の最初のコントローラーを ping するスクリプトが含まれています。デプロイメント時に接続されていないリンクがあるノードの場合には検出されるので、修正することが可能です。もうひとつの可能な回避策としては、各ホストに NIC 番号から物理 NIC へのマッピングが記載されたマッピングファイルを使用する方法です。1 つまたは複数のオーバークラウドノードで　リンクが停止しているため正しく設定を行わない場合には、検出されるようになり、OverCloud は再度デプロイすることが可能です。
High Availability (VRRP) ルーターと L2 Population の対話で、既知の問題が確認されました。現在、HA ルーターをサブネットに接続すると、HA ルーターは設計上、分散ポートを使用します。各ルーターには、スケジューリングされている各ノード上の同じポートの詳細が含まれています。そのポートへの IP が設定されているのはマスタールーターのみで、全スレーブルーターのポートには IP が設定されていません。
そのため、L2Population は古い情報を使用して、ルーターがノード上にあることを通知します (そのポートのポートバインド情報で示されます)。
その結果、論理ネットワーク上にポートがあるノードにはそれぞれ、ポートがバインドされることが想定されるノードに対してのみトンネルが作成されます。また、作成したトンネル経由で、そのポートに対するトラフィックが送信されるように、転送のエントリーが設定されます。
ただし、ポートバインドで指定されたノード上にマスターのルーターがある保証はないため、このアクションは失敗する可能性があります。また、マスタールーターが実際にノード上にある場合には、フェイルオーバーのイベントにより、マスタールーターが別のノードに移動されるため、ルーターとの接続性が失われてしまいます。
openstack-cinder-volume が LVM バックエンドの使用時にオーバークラウドノードが再起動すると、ファイルベースのループバックデバイスは再度作成されません。回避策として、ループバックデバイスを手動で再作成します。

$ sudo losetup /dev/loop2 /var/lib/cinder/cinder-volumes

次に、openstack-cinder-volume を再起動します。openstack-cinder-volume はオーバークラウドコントローラーノードの高可用性クラスター内では、一回に 1 つのノードでしか実行できません。ただし、ループバックデバイスは、全ノード上に存在します。
director はデプロイメントの前または実行中にネットワークの検証を提供しません。そのため、ネットワーク設定が適切でないデプロイメントが数時間実行されて、何も出力が表示されずに結果的に失敗する可能性があります。ネットワーク検証のスクリプトは現在開発中で、将来のリリースで実装される予定です。
今回のリリースでは、Red Hat OpenStack Platform director は、コントローラーノード 3 台で構成される高可用性 (HA) のオーバークラウドデプロイメントのみをサポートしています。
Red Hat OpenStack Platform 8 (Liberty) では、Red Hat はエンドツーエンドのストレージソリューションとして、Ceph との統合をさらに緊密化するための開発を進めており、今後のサポートのための取り組みはすべて、この方針に応じて方向付けされます。

現在、Red Hat Ceph Storage は、Block Storage と Object Storage の両サービスのバックエンドとして完全にサポートされています。次のメジャーリリースでは、Ceph はストレージを使用する OpenStack の全コンポーネントでサポートされる予定です。このサポートにより、コモディティーストレージハードウェアの使用を望むユーザーに向けた統合ストレージソリューションが提供されます。

この方針に沿って、Red Hat Gluster Storage は本リリースで非推奨となり、今後のリリースでは、Gluster 関連のドライバーはすべて削除される予定です。 将来の更新でコモディティーストレージハードウェアを引き続き使用する場合には、Gluster バックエンドのサービスを適宜に移行する必要があります。

さらに、Red Hat Gluster Storage と File Share サービス (Manila) の併用も本リリース以降ではサポートされないので、そのための各 Gluster ドライバーも削除されます。

Red Hat OpenStack Platform は、Image サービスのバックエンド (SwiftOnFile) としてのGlusterFS ボリュームの使用は引き続きサポートします。
今回のリリースでは、PolarSSL/mbedtls に伴う既知のセキュリティー問題が原因で、PowerDNS (pdns) はサポートされていません。

Designate は BIND9 をバックエンドとして使用できるようになりました。
diskimage-builder パッケージは、アップストリームのバージョン 1.10.0 に更新されました。このバージョンでは、多数のバグが修正され、以前のバージョンよりも機能が拡張されています。python-devel パッケージがデフォルトで削除されなくなったのは注目すべき点です。以前のバージョンでは、これが原因で、その他のパッケージも削除されていました。
以前のリリースでは、memcached は IPv6 アドレスをバインディングできなかったため、IPv6 環境で memcached は起動に失敗していました。
今回の更新では、この問題に対処するために、memcached-1.4.15-9.1.el7ost が IPv6 対応となりました。
今回のリベースパッケージにより、範囲クエリーのパフォーマンスが向上されました。特に、「$or」演算子を使用するクエリーが 2.4 リリースで影響を受けていました。これらのリグレッションは 2.6 で修正されました。
以前のリリースでは、Block Storage コンポーネントのバグにより、クォータを使用している場合には Identity API v2 との互換性がありませんでした。このため、Block Storage のクォータに関する情報を管理する際にエラーが発生していました。今回の更新により、Block Storage は Identity API v2 との互換性があるように更新され、Dashboard がボリュームのクォータに関する情報を正しく取得できるようになりました。
以前のリリースでは、cinder API サーバーのクォータコードにバグがあり、「auth_uri」を使うべきところで「encryption_auth_url」を使用していたため、cinder がクォータ情報を問い合わせると、keystone との通信に失敗し、cinder はクライアントに HTTP 500 エラーを返していました。
この問題は 7.0.1 で解決されました。
7.0.1 の Cinder API サービスが修正され、cinder quota コマンドが想定通りに動作するようになりました。
今回の機能拡張により、Object Storage (swift) に cinder ボリュームをバックアップするのと同じユーザーインターフェースを使用して、Block Storage (cinder) ボリュームをバックアップできるようになりました。
この機能は、Ceph がすでに使用されている場合に、第 2 のオブジェクトストアの必要性を回避するために拡張されました。
以前のリリースでは、Block Storage (cinder) のバッキングストアとして Ceph を使用すると、大型のボリュームの削除やフラット化などの操作により、他のドライバースレッドがブロックされてしまう可能性がありました。
このため、スレッドを削除したりフラット化したりすると、その処理が完了するまで cinder は他の操作を実行できなくなる場合がありました。
今回の修正により、スレッドの削除およびフラット化は同じプロセスのグリーンスレッドとしてではなくサブプロセスで実行されるようになりました。
その結果、削除およびフラット化の操作はバックグラウンドで実行されるようになり、その他の cinder の操作 (ボリュームの作成やアタッチなど) を同時に実行できるようになりました。
今回のリリースでは、セキュリティーの分離を提供するために、「/usr/local」のパスがデフォルトの Block Storage の rootwrap の設定から削除されました。その結果、「/usr/local/」から「root」ユーザーとしてコマンドを実行する Block Storage サービスに依存するデプロイメントは、そのコマンドが機能するための設定を追加する必要があります。
今回の機能拡張により、新たにスケーリングされたバックエンドのレプリケーション実装 (バックエンド間) が追加されました。作業の大半はドライバーに任されますが、基本的な管理 API メソッドが提供されます。この機能は、レプリケーションがボリューム種別レベルで設定されている場合に、cinder ドライバーがそのケイパビリティーを報告する際に利用することができます。以下の新規オプションが利用できるようになりました。
replication_enabled: True に設定します。
replication_type: async、sync
replication_count: レプリカ数
多様なストレージバックエンドを使用するデプロイメントで管理者がより柔軟に操作を実行できるようにするために、Block Storage は QoS、圧縮、レプリケーション、帯域幅の制御、シンプロビジョニングなどのケイパビリティーの標準名を定義できるようになりました。これは、変更なしに複数のドライバーで機能するボリューム種別の仕様を定義できることを意味します。
今回の更新で、ネストされたクォータが導入されました。デプロイ担当者は、CInder で親プロジェクトから継承されたサブプロジェクトを使用することで、階層のあるクォータを管理できるようになりました。
今回の更新により Image サービス (glance) によってホストされる共通の API が追加されました。これにより、ベンダー、管理者、サービス、ユーザーは利用可能なキー/値のペアおよびタグのメタデータを意味があるように定義することができます。これは、OpenStack ユーザーのために、アーティファクト、サービス、プロジェクト全体にわたるコラボレーションを向上させることが目的です。
この定義は、異なる種別のリソース (イメージ、アーティファクト、ボリューム、フレーバー、アグリゲートなど) に利用可能なメタデータを記述します。定義には、プロパティーの種別、キー、説明、制限などが含まれます。このカタログは、特定のインスタンスのプロパティーには値を保存しません。
たとえば、多数のコアの仮想 CPU トポロジーのプロパティーの定義には、使用するキー、説明、値の制限 (整数を指定する必要があるなど) が含まれます。その結果、ユーザーは (Dashboard を使用可能) このカタログを検索し、フレーバーやイメージに追加することのできる利用可能なプロパティーを一覧表示することができます。 ユーザーは、一覧に表示される仮想 CPU トポロジーのプロパティーを確認すると、整数を指定する必要があることがわかります。Dashboard の例では、ユーザーがプロパティーを追加すると、キーと値は、そのリソースを所有するサービス (フレーバーには nova、イメージには glance) に保管されます。
今回のリベースパッケージは、https://launchpad.net/gnocchi/+milestone/1.3.0 にリストされているバグに対処しました。
#1511656: gnocchi-metricd が空のメジャーリストをトレース
#1496824: Gnocchi の更新のアラームで 400 が返される場合がある
#1500646: Ceph とgnocchi-metricd でのデータ破損により、Ceph プール全体が削除され全データを失う
#1503848: instance_disk および network_interfaces にコントローラーがない
#1505535: py34 + tooz + PG で断続的なゲートエラー
#1471169: MySQL のインデクサーがデッドロックで停止する場合がある
#1486079: メトリックの削除は非同期にすべき
#1499372: Metricd は破損した新規メジャーファイルの対応を改善すべき
#1501344: archive_policy_rules の評価が指定されていない
#1504130: ミドルウェア設定の調整
#1506628: メジャーの取得に粒度別のフィルターを追加
#1499115: api.workers = 2 と Ceph で gnocchi-api がハング
#1501774: gate 内で "sudo: .tox/py27-gate/bin/testr: command not found" のエラーで機能テストが失敗
以前のリリースでは、heat は最新のプロパティーの定義に基づいて、古いプロパティーの検証を試みていました。そのため、director のアップグレード中に、プロパティーの定義が種別を変更すると、heat が以前のプロパティー値の検証を試みる際に、「TypeError」でプロセスが失敗していました。
今回の修正により、heat は古いプロパティー値の検証は試みないようになりました。
その結果、heat は新しいプロパティー値のみを検証するので、プロパティースキーマ定義の変更を正常に処理できるようになりました。
以前のリリースでは、クラウドの更新時に director はパッチ更新を使用していたので、作成時に渡された全パラメーターが再利用されていました。更新で削除されたパラメーターは、検証に失敗していました。そのため、パッチ更新を使用して、削除されたパラメーターを使用するスタックを更新すると、そのパラメーターを明示的に消去しない限りは操作は失敗していました。
今回の修正により、heat によるパッチ更新の処理が変更され、新規テンプレートに存在しないパラメーターは無視されるようになりました。
その結果、最上位のパラメーターを削除して、修正プログラムで更新を行うことができるようになりました。
以前のリリースでは、heat は保管されているコンテキストを読み込む際に、コンテキストロールは空のままにしていました。シグナル化の際には、heat は保管されていたコンテキスト (trust scoped token) を使用し、そのコンテキストにロールがなかった場合には、動作は失敗していました。そのため、「trustee has no delegated roles」のエラーでプロセスは失敗していました。 今回の修正では、保管されているコンテキストの読み込み時にロールを追加することによってこの問題に対処しています。その結果、auth ref を読み込み、トークンからロールが追加されると、コンテキストロールに対して実行される RBAC が想定通りに機能することが確認され、スタックの更新が成功します。
以前のリリースでは、heat でいくつかの neutron リソースのプロパティー名が変更されました。heat はリソースの作成時には古い名前をサポートするメカニズムを使用していましたが、以前のバージョンで作成したリソースの検証で失敗していました。そのため、Red Hat OpenStack Platform 8 を使用して、バージョン 7 (またはそれ以前のバージョン) で作成した、neutron ポートリソースを使用するスタックを更新すると、「None」オブジェクトのルックアップの試行で失敗していました。
今回の修正では、heat がリソースを更新すると、古いプロパティーにも変換メカニズムが使用されるようになり、その結果、非推奨となったプロパティーのサポートは、以前のバージョンで作成したリソースで想定されるように機能します。
以前のリリースでは、デプロイメントの ramdisk 実行時に間に合うようにハードドライブが利用できないことがありました。そのため、ramdisk が必要なルートデバイスを見つけられない場合には、デプロイメントが失敗していました。今回の更新では、ramdisk 内のディスクを列挙する前に「udev settle」コマンドが実行されるようになり、ルートデバイスが見つからないことが原因でデプロイメントが失敗することはなくなりました。
Identity サービス (keystone) で、「enabled emulation」機能を使用している場合には、ユーザーが有効かどうかを確認する際に、ハードコードされた LDAP メンバーシップ属性が使用されていました。
そのため、予想外の LDAP メンバーシップ属性が使用されている場合には、「enabled」のユーザーが「disabled」として表示される場合がありました。
今回の修正により、「enabled emulation」のメンバーシップのチェックで、グループリソースに使用される設定可能な LDAP メンバーシップ属性を使用するようになりました。
その結果、異なる LDAP メンバーシップ属性が設定されている場合に、ユーザーの「enabled」ステータスが正しく表示されるようになりました。
Identity サービスの今回のリベースパッケージでは、以下の問題に対処しました。

* Identity サービス (keystone) で、「enabled emulation」機能を使用している場合には、ユーザーが有効かどうかを確認する際に、ハードコードされた LDAP メンバーシップ属性が使用されていました。そのため、予想外の LDAP メンバーシップ属性が使用されている場合には、「enabled」のユーザーが「disabled」として表示される場合がありました。今回の修正により、「enabled emulation」のメンバーシップのチェックで、グループリソースに使用される設定可能な LDAP メンバーシップ属性を使用するようになりました。異なる LDAP メンバーシップ属性が設定されている場合に、ユーザーの「enabled」ステータスが正しく表示されるようになりました。(Launchpad バグ #1515302、Red Hat BZ#1282944)

* Fernet トークンプロバイダーを使用すると、user_id の長さが 16 文字だった場合には、Identity サービスが UUID を処理していると誤って仮定する可能性がありました。これにより、Identity サービスのログに「Could not find user」(ユーザーは見つかりません) のエラーが記録されていました。今回のリリースではこの問題は修正され、16 文字のユーザー ID が適切に処理されるようになりました。(Launchpad バグ #1497461)
以前のリリースでは、Identity サービス (keystone) で、管理者が Passlib python モジュールで使用されている上限を超えるパスワードの最大長を設定することが可能でした。
そのため、パスワードの最大長を Passlib の上限を超える値に設定した場合、Passlib の上限を超えるユーザーパスワードの設定を試みても、HTTP 500 の応答とキャッチされない例外のエラーが発生して操作は失敗していました。 
今回の更新で、Identity サービスは「max_password_length」の設定値が Passlib の最大長以下であることを検証するようになりました。
その結果、Identity サービスの「max_password_length」が大きすぎる場合には、設定検証エラーで起動が失敗するようになりました。
以前のリリースでは、「iproute2」の最近のバージョンの「ip netns list」コマンドは予想外の ID データを返していたため、neutron は名前空間を解析できませんでした。
今回の修正では、neutron で使用するパーサーを更新することによってこの問題に対処しました。その結果、neutron は名前空間を想定通りに解析することが可能となりました。
今回の更新の前には、Keepalived の親プロセスが停止すると、L3 エージェントは Keepalived プロセスの再起動に失敗していました。これは、Keepalived の子プロセスがまだ実行中だったためでした。
そのため、L3 エージェントは、Keepalived の親プロセスの停止から復旧できず、このプロセスがサービスを提供する HA ルーターが機能しなくなっていました。
今回の更新により、L3 エージェントが Keepalived の子プロセスを認識し、Keepalived を再起動する前にクリーンアップするようになりました。
その結果、L3 エージェントは、Keepalived プロセスが停止した後に HA ルーターを復旧できるようになりました。
Red Hat OpenStack Platform 8 では、新たな RBAC 機能が導入され、neutron ネットワークをグローバルに共有する代わりに、特定のテナントリストと共有できるようになりました。この機能の一部として、ネットワークの所有者がそのネットワークに属する全ポートを一覧表示できるようにすることを試みて、neutron のデフォルトのポリシー .json ファイルは I/O のトリガーを開始し、ポートをフェッチするたびにデータベースフェッチを消費していました。
そのため、ポートの一覧表示の操作により複数の不要なデータベースフェッチがトリガーされて、操作のパフォーマンスに大幅な影響を及ぼしていました。
今回にの更新では、I/O 操作は、たとえば、ポリシーエンジンによって検証されるポートが一覧表示の操作を呼び出すテナントに属していない場合など、実際に必要な時にだけ実行することにより、この問題に対処しました。その結果、一覧表示の操作は、再び正常にスケーリングするようになりました。
今回の更新の前には、BZ#1215177 の修正により、Keepalived の設定に「garp_master_repeat 5」と「garp_master_refresh 10」のオプションが追加されました。
しかしながら、その結果、Keepalived は Gratuitous ARP (GARP) ブロードキャストで継続的に大量のデータをネットワークに送り込んでいました。また、インスタンスは IPv6 のデフォルトゲートウェイ設定を失っていました。これらの問題が原因で、IPv6 ルーターは VRRP では機能を停止していました。
今回の更新では、Keepalived の「repeat」と「refresh」オプションが廃止されました。これにより、IPv6 のバグが修正されましたが、BZ#1215177 に記載されているバグが発生しました。
この問題を解決するには、「delay」オプションを代わりに使用すると、Keepalived は MASTER に移行するときに GARP を送信してから、遅延のオプションによって決定される秒数を待った後に別の GARP を送信します。ノードがブートして L3/L2 エージェントが起動する際に L2 エージェントがポートを配線するための十分な時間があるようにするには、アグレッシブな「delay」設定を使用してください。
今回の更新の前には、Open vSwitch エージェントに加えられた変更が原因でバグが発生し、エージェントが起動時にフラットネットワークのセグメンテーション ID 値を処理する方法で問題が生じていました。
そのため、エージェントがフラットネットワークにサービスを提供する際に再起動に失敗していました。
今回の更新により、エージェントのコードが修正され、フラットネットワークのセグメンテーションプロパティーを処理するようになりました。その結果、エージェントはフラットネットワークにサービスを提供する際に正常に再起動するようになりました。
以前のリリースでは、HA または DVR のどちらでもないルーターを HA ルーターに変換することはできませんでした。代わりに、新規ルーターを作成して、全リソース (インターフェース、ネットワークなど) を古いルーターから新しいルーターに再接続する必要がありました。今回の更新では、簡単なコマンドを実行して、レガシーのルーターを HA または非 HA ルーターに変換できる機能が追加されました。

# neutron router-update ROUTER --admin-state-up=False
# neutron router-update ROUTER --ha=True/False
# neutron router-upgrade ROUTER --admin-state-up=True

ROUTER は、変換するルーターの ID または名前に置き換えてください。
High Availability (VRRP) ルーターと L2 Population の対話で、既知の問題が確認されました。現在、HA ルーターをサブネットに接続すると、HA ルーターは設計上、分散ポートを使用します。各ルーターには、スケジューリングされている各ノード上の同じポートの詳細が含まれています。そのポートへの IP が設定されているのはマスタールーターのみで、全スレーブルーターのポートには IP が設定されていません。
そのため、L2Population は古い情報を使用して、ルーターがノード上にあることを通知します (そのポートのポートバインド情報で示されます)。
その結果、論理ネットワーク上にポートがあるノードにはそれぞれ、ポートがバインドされることが想定されるノードに対してのみトンネルが作成されます。また、作成したトンネル経由で、そのポートに対するトラフィックが送信されるように、転送のエントリーが設定されます。
ただし、ポートバインドで指定されたノード上にマスターのルーターがある保証はないため、このアクションは失敗する可能性があります。また、マスタールーターが実際にノード上にある場合には、フェイルオーバーのイベントにより、マスタールーターが別のノードに移動されるため、ルーターとの接続性が失われてしまいます。
以前のリリースでは、neutron-server サービスは、セキュリティーグループの更新をリッスンする L2 エージェントから、新しい RPC エントリーポイントのバージョンを誤って要求することがありました。
そのため、Red Hat OpenStack Platform 7 neutron L2 エージェントは、Red Hat OpenStack Platform 8 neutron-server サービスによって送信される特定のセキュリティーグループの通知を処理できなかったため、特定のセキュリティーグループの更新がデータプレーンに反映されませんでした。
今回の更新では、エージェントからの RPC エンドポイントバージョンの要求しないようにすることによってこの問題に対処しました。これは、 RHEL OpenStack Platform 7 と Red Hat OpenStack Platform 8 の間のローリングアップグレードに役立つことが理由です。
その結果、RHEL OpenStack Platform 7 neutron L2 エージェントは、Red Hat OpenStack Platform 8 neutron-server サービスによって送信されたセキュリティーグループの更新通知を正しく処理するようになりました。
今回の更新の以前は、テナントの最後の HA ルーターが削除されると、そのテナントに属する HA ネットワークが削除されていました。これは、ルーターが削除されたために例外を発生させる「router delete」API コールなどの特定のシナリオで発生していました。このシナリオは、HA ルーターの「create」と「delete」の操作の間の競合状態が原因で発生する可能性がありました。この問題のために、HA ネットワークテナントは削除されませんでした。
今回の更新により、競合状態の問題は解決され、ユーザーが最後の HA ルーターを削除する時や、HA ネットワークを移動して「ha_network exist」チェックブロック下のプロシージャーを削除する時にも、「ObjectDeletedError」および「NetworkInUse」の例外を検出するようになりました。また、今回の修正により、HA ルーターの存在の有無がチェックされ、最後の HA ルーターが削除されると HA ネットワークが削除されるようになりました。
neutron-openvswitch-agent が停止している時に作成された neutron ポートのステータスは「DOWN, binding:vif_type=binding_failed」となることが想定されていましたが、今回の更新の以前は、neutron-openvswitch-agent がオンライン状態に戻っても、それらのポートを復旧させる方法はありませんでした。今回の修正により、「_bind_port_if_needed」の関数は、渡されたポートのバインディングステータスがすでに「binding_failed」の場合に、少なくとも 1 回バインディングを実行するようになったため、neutron-openvswitch-agent がオンライン状態に戻った時にバインディングを繰り返し試行することによって、ポートはエラーのバインディングステータスから復旧できるようになりました。
今回の更新の以前は、Floating IP アドレスが HA ルーターによって割り当てらる際に、その Floating IP アドレスのステータスが設定されませんでした。
そのため、「neutron floatingip-show <floating_ip>」は更新されたステータスを出力しませんでした。
今回の更新では、HA ルーターによって Floating IP アドレスが割り当てられた時と、L3 エージェントによってルーターが設定された時に、その Floating IP アドレスのステータスが更新されます。
その結果、HA ルーターによって割り当てられた Floating IP アドレスのステータスフィールドには、L3 エージェントによって Floating IP が設定されると、ステータスが「ACTIVE」に更新されます。
libvirt ドライバーで admin パスワードを設定する機能が追加されました。この機能を使用するには、「nova root-password [server]」のコマンドを実行してください。
以前のリリースでは、奇数の 仮想 CPU を選択すると、ゲストインスタンスで 1 CPU につき 1 コア、1 スレッドが割り当てられ、パフォーマンスに影響がありました。
今回の更新で、この問題は修正され、奇数の 仮想 CPU が割り当てられた場合には、1 CPU につきスレッドのペアと独立したスレッドが 1 つ割り当てられるようになりました。
以前のリリースでは、移行元のコンピュートノードが移行後に稼動状態に戻っても、そのノードが停止している間に正常に退避されていたインスタンスは削除されませんでした。削除されなかったインスタンスがあるために、退避されていたインスタンスを元に戻すことができませんでした。

今回の更新では、インスタンスを退避させる際の移行成功のステータスが検証され、コンピュートノードが稼動状態に再び戻った時に削除すべきインスタンスを確認するようになりました。その結果、インスタンスは以前の場所に拘らず、1 台のホストから別のホストに退避することが可能となりました。
今回のパッケージで、Compute (nova) はバージョン 12.0.2 にリベースされ、以下のような更新が含まれています。
- compute manager への qemu-img エラーの伝達
- Nova セル v1 の退避サポートの修正
- libvirt: virt ドライバーのテストのための libvirt.sysinfo_serial='none' の設定
- XenAPI: 6.5 iSCSI バグの回避策
- 移行のコンテキストがない場合に警告をデバッグログに変更
- Zanata からの翻訳インポート
- libvirt: RBD-backed イメージの revert (元に戻す) および resize (サイズ変更) の修正/実装
- Glance イメージの「size」属性を「None」ではなく「0」とする
- LibVirt を使用するデバイスのデタッチに再試行のロジックを追加
- Fixed IP アドレスの割り当て分散
- Exact* フィルターにスケジューラーの制限を適用
- eventlet ベースの raw ソケットクライアントをリクエストに置き換え
- VMware: OVA および streamOptimized イメージサイズを正しく処理
- XenAPI: より多くの Cinder バックエンドへの対応
- ポートとネットワークの収集で存在を検証すべき
- ブリッジデバイス上での IPv6 の無効化
- 翻訳の検証
- 退避が成功した後にインスタンスが破棄されない問題を修正
今回の更新で、「openstack-nova」パッケージがアップストリームのバージョン 12.0.1 にリベースされました。

今回のリベースの主要な変更点は以下のとおりです。

- リリースノートのビルド時に、sphinx の警告をエラーとして処理
- 12.0.1-cve-bugs-7b04b2e34a3e9a70.yaml リリースノートの警告を修正
- libvirt ライブスナップショットでのバッキングファイルの検出を修正
- 12.0.1 のリリースノートにセキュリティーの修正を追加
- libvirt スナップショットのフォーマット変換を修正
- libvirt スナップショットのフォーマット検出を修正
- VMware: イメージデータ読み込み時のチャンクサイズの指定
- 「Fixes Python 3 str issue in ConfigDrive creation」を元に戻す
- 削除済みインスタンスを読み込まない
- scheduler_hintsスキーマで ID の一覧表示を可能にする
- CI ジョブの -constraints セクションを追加
- TestRemoteObject クラスを削除
- グローバルの要件からの更新
- VMware: インベントリーフォルダー使用時のコンフィグドライブのバグを修正
- Omnibus 安定版でアップストリームの要件の問題を修正
- terminate_connection で古いボリュームの BDM をリフレッシュ
- Neutron 使用時のメタデータサービスのセキュリティーグループの問題を修正
- サンプルの nova.conf ファイルに「vnc」オプショングループを追加
- スケジューラー: glance のハイパーバイザー情報のメタデータを適用
- reno: サービス状態レポートの問題についてのドキュメントを修正
- servicegroup: 例外を原因とするゾンビサービスを停止
- Zanata から翻訳をインポート
- xen: ボリュームの connection_data dict 内のパスワードをマスキング
- image_ref が未設定の場合の is_volume_backed_instance() の動作を修正
- test_is_volume_backed_instance() を 5 つの関数に分割
- servicegroup DB ドライバーの DB エラー処理
- ConfigDrive の作成における Python 3 str の問題を修正
- Nova のインダイレクションフィクスチャーのオーバーライドを修正
- グローバル要件から更新
- 最初の reno ベースのリリースノートを追加
- 「未リリース」のリリースノートページを追加
- リリースノートの管理に reno を追加
- test_schedule_to_all_nodes test は現在正常に機能せずブラックリストされている
- libvirt: スナップショットの削除で、仮想マシンが停止している場合には qemu-img を使用して blockRebase
- Ceph で raw イメージをクローンする際の属性エラーを修正
- セルの全 BDM チェックを除外
- Image メタ: レガシーの VMware アダプタータイプの値を適切に処理
以前のリリースでは、Packstack は、CONFIG_NEUTRON_VPNAAS パラメーターが「y」に設定されていても、Dashboard で VPNaaS タブを有効にしなかったため、VPNaaS のタブは Dashboard に表示されませんでした。

今回の更新で、VPNaaS が有効化されているかどうかを確認するチェックのプロセスが設定されました。このチェックの後に Puppet マニフェストで Dashboard のタブが有効化されます。その結果、Packstack で設定されると、VPNaaS タブが Dashboard に表示されるようになりました。
以前のリリースでは、Packstack は /etc/lvm/lvm.conf ファイルを編集して、スナップショットの自動拡張のための特定のパラメーターを設定していましたが、使用されていた regexp は、ファイルで使用されているのと同じように、タブの代わりに空白スペースのみが可能でした。その結果、ファイルの終端に数行追加され、書式がくずれてしまっていました。

今回の更新で、Packstack の regexp が更新されて、パラメーターを正しく設定するようになりました。その結果、LVM コマンドの実行中にエラーメッセージは表示されなくなりました。
以前のリリースでは、haproxy は、全プロキシーを合わせた「maxconn」パラメーターに 10000 の値を許可するように設定されていましたが、各プロキシーの個別の「maxconn」値は 2000 がデフォルトとなっていました。MySQL に使用する特定のプロキシーが上限の 2000 に達すると、それ以降のデータベース接続はすべて解除され、クライアントが再試行しなかったため、API タイムアウトが発生し、その後のコマンドが失敗していました。

今回の更新で、「maxconn」パラメーターのデフォルト値は実稼働環境への対応を向上させるためにより大きな値となりました。その結果、データベース接続がタイムアウトとなることは大幅に低減しました。
以前のリリースでは、Facter 2 には netmask6 および netmask6_<ifce> のファクトがなかたため、IPv6 はサポートされませんでした。

今回の更新で、IPv6 インターフェースのチェックをサポートする関連のカスタムファクトが追加され、IPv6 インターフェースがサポートされるようになりました。
以前のリリースでは、デフォルトのタイムアウトがなかったため、Ceph クラスター設定の一部の段階で、デフォルトの 5 分 (300 秒) よりも長くかかっているように見えました。

今回の更新で、関連操作にタイムアウトのパラメーターが追加され、デフォルトのタイムアウト値は 600 秒に設定されました。必要な場合にはこのデフォルト値を変更することが可能です。その結果、特に Ceph の設定操作で平均よりも時間が長くかかっている場合に、インストールでエラーが発生しにくくなりました。
今回の更新で、タイムアウトを指定するための設定が追加されました。タイムアウトするまでに「Active」な状態にならなかったクラスターは自動的に削除されます。
再利用するためのジョブテンプレートを作成する場合には、OpenStack Data Processing (sahara) でデータソースの URL の変数を登録することができるようになりました。この登録により、実際の URL 変更 (その場合はテンプレートの編集や、ジョブ間で実行ごとに URL の変更が必要) ではなく、実行ごとに入出力パスを容易に変更することができます。

これにより、データソースジョブが実行ごとに可変の場合 (実際の利用環境の大半が該当) に、ジョブテンプレートを容易に再利用できるようになりました。
今回の更新で、Sahara への CDH 5.4 統合が完了し、プラグインバージョン CDH 5.3 でデフォルトで有効化されていたオプションは削除されました。
以前のリリースでは、古いクラスターをクリーンアップ機能を果たす定期タスクには、テナントのコンテキスト情報が提供されませんでした。

今回の更新で、tenant と admin 間の一時的なトラストが確立されるようになり、定期ジョブはそのトラストを利用して、古いクラスターを削除することができるようになりました。
以前のリリースでは、「nova_t」のラベルが付いたディレクトリー内の検索に httpd は使用できませんでした。そのため、nova-novncproxy が HA オーバークラウドのデプロイに失敗していました。今回の更新では、それらのディレクトリー内を httpd で検索ができるようになり、nova-novncproxy を正常に実行できるようになりました。
以前のリリースでは、Open vSwitch が tun ソケットの作成を試みても SELinux によって妨げられていました。今回の更新では、Open vSwitch が tun ソケットを作成できるようになり、Open vSwitch でエラーが発生しなくなりました。
以前のリリースでは、SELinux によって ovsdb-server の実行がブロックされていたため、単純なネットワーク操作が失敗していました。

今回の更新では、Open vSwitch が自らのポートに接続可能となり、ovsdb-server は問題なく実行できるので、ネットワーク操作が正常に完了するようになりました。
以前のリリースでは、redis が自らのポートに接続するのを、SELinux が妨げていたので、redis は再起動時に失敗していました。

今回の更新で、「redis」のラベルが付いたポートに接続するためのパーミッションが redis に付与されたので、redis は正常に実行され、リソースの再起動も正常にできるようになりました。
以前のリリースでは、nova が公開鍵をオーバークラウドにアップロードするのを SELinux が妨げていましたが、今回のリリースでは新たなルールが追加されて、nova が鍵をアップロードできるようになりました。
以前のリリースでは、nova が glance イメージの一覧を取得を試みると、SELinux がその操作を妨げていましたため、nova は「Unexpected API Error」で操作が失敗していました。今回の更新では、nova が glance と通信可能となり、nova は glance イメージの一覧表示ができるようになりました。
以前のリリースでは、SELinix によって dhclient、vnc、redis の機能が妨げられていました。今回のリリースでは、新たなルールが追加され、これらのソフトウェアツールが正常に実行できるようになりました。
Open vSwitch (openvswitch) のパッケージがアップストリームのバージョン 2.4.0 にリベースされました。
今回の更新では、Block Storage の「snapshots-list」および「backups-list」のコマンドのペジネーションの新機能が追加され、パラメーターを制限、マーカー、ソートして返される結果数、開始する要素、およびその順序を制御することができるようになりました。

何千にもおよびスナップショットやバックアップのある大型デプロイメントでは、データセット全体ではなく限定された数の結果を取得する方法が非常に役立ちます。
今回の更新で「Launch Instance」のワークフローが再設計/再実装され、応答性が向上しました。

1. この更新を有効にするには、以下の値を /etc/openstack-dashboard/local_settings ファイルに追加します。

LAUNCH_INSTANCE_LEGACY_ENABLED = False
LAUNCH_INSTANCE_NG_ENABLED = True

2. 「httpd」を再起動します。
# systemctl restart httpd
OpenStack Dashboard のテーブルには、多数のエンティティーについての情報のサマリーが表示されます。今回の更新で、テーブルの機能が拡張され、テーブル内で情報がスライドダウン式の「ドロワー」として表示されるようになりました。これは、その行内で切り替えスイッチをクリックすると有効になります。ドロワーは追加の行として表示され (高さを設定可能)、その行のエンティティーの追加情報が含まれます (例: 追加のエンティティー情報、メトリック、グラフなど)。一度に複数のドロワーを開くことが可能です。
以前のネットワークトポロジーの UI は、ノードやネットワークの数が多くなると適切に機能しなかったため、今回の更新で、曲率ベースのグラフに変更されました。 

新しいネットワークトポロジーマップは、より多くのノードに対応できる上、外観もスタイリッシュで、ノードのレイアウトを再構成することが可能です。
今回の更新で、Block Storage (cinder) サービスのボリューム移行がサポートされるようになりました。この操作は OpenStack Dashboard の「Volumes」パネル (プロジェクト-> コンピュート -> ボリュームと、管理-> システムパネル-> ボリューム) で、表内の「ボリューム」の行で実行できます。
このシリーズの最終パッチで、コマンドのアクション自体の問題 (以前のリリースでは、パラメーターの誤りとパラメーターカウントの問題が原因でエラーが発生していました) も解決されました。
python-django-horizon パッケージがアップストリームのバージョン 8.0.1 にアップグレードされました。このバージョンでは、多数のバグが修正され、以前のバージョンよりも機能が拡張されています。特に、ローカリゼーションの更新、イタリア語翻訳の追加、job_binaries 削除の修正、LB プールの仮想 IP アドレスでの IPv6 の受け入れのサポート追加などがこのバージョンの注目すべき点です。
今回のリリースでは、パネルが設定可能になりました。設定スニペットを使用して、パネルを追加/削除することができます。

たとえば、「リソースパネル」削除するには、以下のように設定します。

* 「/usr/share/openstack-dashboard/openstack_dashboard/local/enabled」にファイルを配置します。
* そのファイルに「_99_disable_metering_dashboard.py」という名前を付けます。
* 以下のコンテンツをそのファイルにコピーします。

# The slug of the panel to be added to HORIZON_CONFIG. Required.
PANEL = 'metering'
# The slug of the dashboard the PANEL associated with. Required.
PANEL_DASHBOARD = 'admin'
# The slug of the panel group the PANEL is associated with.
PANEL_GROUP = 'admin'
REMOVE_PANEL = True

* Restart the Dashboard httpd service:
# systemctl restart httpd

詳しい説明は、「Pluggable Dashboard Settings」を参照してください。
今回のリリースでは、Dashboard (horizon) の「Metering」パネル は、パフォーマンスの問題により無効になっています。
以前のリリースでは、Horizon の httpd の systemd スニペットでタイムアウトが指定されていなかったため、httpd が完全に起動するのを待つ際のタイムアウトには、標準の 1 分が使用されていましたが、仮想化された環境や、負荷の高い環境で実行する場合には特に、起動に時間が長くかかることがありました。そのため、httpd がすでに実行中でも systemd からエラーが出ていました。今回の更新では、タイムアウトが 2 分間に設定され、この問題は解決されました。
以前のリリースでは、Object Storage サービスは Image サービスのバックエンドストレージとして使用され、イメージデータは Object Storage サービス内で複数の「チャンク」データとして保管されていました。Image サービスの APIv2 を使用する時には、クライアントが最終のサイズ が 0 の「チャンク」をサーバーに送信すると、アップロードの操作が失敗する場合がありました。この失敗は、サイズが 0 の「チャンク」を保管する操作とその「チャンク」の削除のクリーンアップ間で競合状態が関与していました。その結果、Object Storage サービスに Image サービスのイメージを保管する間には、断続的なエラーが発生していました。

今回の更新で、削除操作のクリーンアップおよび最初のイメージアップロードは失敗するのではなく再試行されるようになり、Image サービスの APIv2 はこのまれな状況に適切に対応し、イメージのアップロードは失敗しなくなりました。
以前のバージョンでは、プライベートネットワーク内の S3 バックエンドにリモートでセキュアにアクセスする方法がありませんでした。

今回の更新で、新たな機能が追加され、Image サービスの S3 ドライバーは、HTTP プロキシーを介して、別のネットワークから S3 バックエンドにセキュアに接続できるようになりました。
以前のリリースでは、Image サービスのクライアントは Image サービスサーバーへ特定の形式 (例: raw、ami、iso など) でのみイメージのアップロードを許可するようにしか設定できませんでした。また、クライアントは設定済みの形式のイメージでなければサーバーからダウンロードできませんでした。このような制限があったため、ユーザーは以前別の形式でアップロードしていたイメージをダウンロードできなくなる場合がありました。

今回の更新により、Image サービスのサーバーは、イメージのインポート時に形式すでに検証するので、Image サービスクライアントがダウンロード時にイメージの形式を検証する必要はなくなりました。イメージのダウンロード時にイメージの形式を検証するステップは省略されるようになり、クライアント側でそれらの形式のイメージのアップロードのサポートが設定されなくなっても、適正な形式のイメージを使用することができます。
以前のリリースでは、「heat resource-list --nested-depth ...」コマンドに「parent_resource」というコラムが含まれていましたが、その出力には、その後に「heat resource-show ...」を実行するために必要な情報が含まれていませんでした。今回の更新では、「heat resource-list --nested-depth ...」の出力に「stack_name」というコラムが追加され、「heat resource-show [stack_name] [resource_name]」コールで使用する値が提供されるようになりました。
OpenDaylight OpenStack neutron ドライバーは、neutron プロジェクトから分離して、新たなパッケージ python-networking-odl に移動しました。オペレーターは、このドライバーを引き続き Red Hat OpenStack Platform インストール環境の一部として使用することができます。
「neutron router-gateway-set」コマンドが「--fixed-ip」オプションをサポートするようになりました。このオプションにより、外部ネットワークで使用する Fixed IP アドレスとサブネットを設定することができます。この IP アドレスは、OpenStack Networking サービス (openstack-neutron) がソフトウェアレベルのインターフェースに接続して、テナントネットワークを外部ネットワークに接続するのに使用されます。
今回のリリースでは、python-openstackclient パッケージがアップストリームのバージョン 1.7.2 にリベースされました。これにより、「find_resource」の例外処理の改善をはじめとする複数のバグ修正や機能拡張が適用されました。
Oslo Messaging は「シャッフル」ストラテジーを使用して RabbitMQ サーバーの一覧から RabbitMQ ホストを選択していました。RabbitMQ を実行するクラスターのノードが再起動されると、このサーバーに接続されていた各 OpenStack サービスは新しい RabbitMQ サーバーに再接続していました。あいにく、このストラテジーは動作が停止している RabbitMQ サーバーを適切に処理しないため、停止中のサーバーに何度も続けて接続を試みていました。また、このストラテジーにより、再接続の時間が長くなり、接続の処理時間に対する保証がなかったため、RPC 操作でタイムアウトが発生することもありました。

今回の更新で、Oslo Messaging は RabbitMQ ホストの選択に「ラウンドロビン」式のストラテジーを使用するようになりました。このストラテジーにより、再接続の時間は可能な限り短縮され、ノードの再起動時に RPC タイムアウトを回避することができます。また、N 個中 K 個の RabbitMQ ホストが稼働中の場合には、RabbitMQ クラスターへの再接続が成功するまでの再試行は最大でも「N - K + 1 」回行うことが保証されるようにもなりました。
RabbitMQ サービスが OpenStack サービスから他のサービスへの AMQP メッセージの配信に失敗した場合には、再接続して配信を再度試みます。「rabbit_retry_backoff」オプション (デフォルトで 2 秒) は、本来、再試行のペースを制御するはずですが、以前のリリースでは、このオプションの設定値に拘らず、再試行は毎秒実行されていました。この問題が原因で、エンドポイントが利用できない場合などに再試行が必要以上に実行されていました。今回のリリースではこの問題は修正され、「rabbit_retry_backoff」オプションを明示的に設定した場合、またはデフォルトの 2 秒を使用する場合にメッセージ配信の再試行が適切に制御されるようになりました。
今回のリリースで、oslo.middleware が SSL/TLS をサポートするようになり、OpenStack サービスが HTTPS トラフィックをリッスンして、やり取りを暗号化できるようになりました。以前のリリースでは、OpenStack サービスは HTTP しかリッスンできず、すべてのやり取りがクリアテキストで行われていました。
SIGTERM と SIGINT のシグナルハンドラー間での競合状態により、ワーカープロセスが SIGTERM の受信シグナルを無視する可能性がありました。OpenStack サービスの子プロセスで 2 つの SIGTERM シグナルを「迅速に」受信すると、一部のワーカープロセスが SIGTERM の受信シグナルの処理に失敗する場合があり、それらのプロセスがアクティブな状態のままとなりました。このような状態が発生すると、以下のような AssertionError 例外のメッセージがログに表示されていました。
    Cannot switch to MAINLOOP from MAINLOOP

今回のリリースにはこの競合問題を修正する oslo.service が実装され、SIGTERM シグナルが正しく処理されるようになりました。
以前のリリースでは、一部のベースイメージコンテキストで、保存の前に iptables が初期化されませんでした。このため、「disable-firewall」要素の「iptables save」が失敗していました。今回のリリースでは、非破壊的なコマンド「iptables -L」が実装され、全コンテキストで iptables が正常に初期化されるようになったので、イメージの生成が正常に実行されます。
Liberty リリースでは、OpenStack のバージョニングスキームがメジャーリリース番号をベースとするようになりました (以前は年がベースでした)。この更新で、現行の sahara-image-elements パッケージにエポックが追加され、古いバージョンがアップグレードされるようになりました。
今回の更新で、OpenStack の通知が提供されるようになりました。以前は、通知が有効化されていないために、OpenStack の通知の外部コンシューマーが director によってデプロイされたクラウドに接続できない場合がありました。今回のリリースでは、director は外部コンシューマーに対しても通知を有効化するようになりました。
アンダークラウドで Ceilometer の設定が誤っていたため、ハードウェアの計測機能が正しく機能しませんでした。今回の修正により、有効なデフォルトの Ceilometer 設定が提供され、Ceilometer のハードウェア計測機能は想定通りに機能するようになりました。
以前のリリースでは、「openstack undercloud install」を実行すると、サブネットに変更が必要でない場合にも、アンダークラウドの neutron サブネットの削除と再作成が試行されていました。オーバークラウドがすでにデプロイされている場合には、サブネットにポートが割り当てられているため、そのサブネットの削除は失敗し、「openstack undercloud install」コマンドが失敗していました。今回の修正により、この動作は、「openstack undercloud install」コマンドでサブネットに設定の変更を適用する場合にのみサブネットの削除と再作成を試みるようになりました。オーバークラウドがデプロイ済みの場合には、director はサブネットを削除できないため、同じエラーメッセージが表示されますが、デプロイ済みのオーバークラウドでのサブネットの設定変更は推奨していないため、これは想定される動作です。サブネットの設定に変更がない場合には、「openstack undercloud install」コマンドでエラーメッセージがでて操作が失敗することはなくなりました。
以前のリリースでは、アンダークラウドをインストールする Puppet のマニフェストが間違ったリソース名を参照して Heat 用の keystone ドメインを作成していたため、以下のようなメッセージが表示されて、アンダークラウドのインストールに失敗していました。

puppet apply exited with exit code 1

今回の修正により、 Puppet のマニフェストがリソースの正しい名前を使用するようになったため、アンダークラウドのインストールがエラーなしで終了するようになりました。
以前のリリースでは、LANG を ja_JP.UTF-8 に設定すると、date コマンドの「dib-run-parts」に日本語の文字が含まれていたため、「_run_live_command()」で unicode エラーが発生していました。アンダークラウドのインストールは以下のエラーで失敗していました。

UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 18: ordinal not in range(128)
Command 'instack-install-undercloud' returned non-zero exit status 1

今回の修正により、アンダークラウドのインストール中に utf-8 の文字エンコーディングを使用する文字列がデコードされるようになり、LANG を ja_JP.UTF-8 に指定した場合のアンダークラウドのインストールは、正常に成功するようになりました。
今回の更新により、Red Hat OpenStack Platform director 8 から Tuskar API サービスが削除されました。以前のリリースでは、Tuskar はアンダークラウドにインストール/設定され、 Keystone サービスカタログ内に存在するエンドポイントが含まれていました。Tuskar の RPM は設定されなくなり、サービスカタログにエンドポイントは作成されなくなりました。
director に新たな機能が追加され、プロファイルの自動照合が可能となりました。ユーザーはイントロスペクションのステップで利用可能なデータに基づいてノードとデプロイメントロール間の自動照合を指定することができます。ユーザーは ironic-inspector イントロスペクションルールと新しい python-tripleoclient コマンドを使用してプロファイルをノードに割り当てることができます。
以前のリリースでは、Ironic Inspector により定期的に実行される iptables コールには、xtables がロックされるまで iptable に待機するように指示する「-w」オプションが含まれていませんでした。そのため、iptables の定期的な更新が失敗することがありました。今回の更新により、iptables コールに「-w」オプションが追加され、iptables の定期的な更新は失敗しないようになりました。
以前のリリースでは、イントロスペクションの ramdisk のログ処理で Latin 以外の文字は考慮されませんでした。そのため、「ログ」コレクターはイントロスペクション中に失敗していました。今回の更新では、ログ処理が修正され、どのエンコーディングも適切に処理できるようになりました。
director はイントロスペクションとデプロイメントに新しい ramdisk を使用します。この ramdisk には、ルートデバイスヒントを使用していないユーザー向けにデフォルトのルートデバイスを選択する新たなアルゴリズムが実装されていますが、再デプロイメントで選択可能なルードデバイスが変更されると、エラーが発生してしまいます。今回の修正で、ramdisk デバイスロジックを OpenStack Platform director 7 と同じロジックに戻しました。デバイス名は信頼できないため、デフォルトのルートデバイスが同じということではない点に注意してください。この動作は、将来のリリースでは変更される予定です。お使いのノードが複数のハードドライブを使用している場合には、ルートデバイスヒントを使用するようにしてください。
以前のリリースでは、Pacemaker は、サービスリソースに 100 秒のタイムアウトを使用していましたが、systemd のタイムアウトには、最初のタイムアウトの後に SIGTERM と SIGKILL に対応するための追加のタイムアウト時間が必要でした。今回の修正により Pacemaker のタイムアウトが 200 秒に延長され、2 つの systemd タイムアウト時間が完全に収まるようになり、そのタイムアウト時間では systemd が SIGTERM と SIGKILL を実行するために十分な時間が残るようになりました。
以前のリリースでは、RabbitMQ Pacemaker リソースには「notify=true」パラメーターがなかったため、RabbitMQ のインスタンスは RabbitMQ クラスターに再度参加できませんでした。今回の更新では、RabbitMQ の Pacemaker リソースエージェントで「notify=true」がサポートされるようになり、OpenStack director に「notify=true」が追加されました。その結果、RabbitMQ のインスタンスは RabbitMQ クラスターに再度参加できるようになりました。
「ceilometer」ユーザーには、一部の機能に必要なロールが割り当てられていなかったため、Ceilometer 計測機能が正しく動作していませんでした。今回の修正により必要なロールが「ceilometer」ユーザーに割り当てられるようになり、ceilometer の計測機能はすべて正しく動作するようになりました。
今回の更新の前は、swift ringbuilder と swift proxy memcache サーバーに使用されていた swift_device および swift_proxy_memcache の URI は IPv6 アドレス用の正しい形式ではなく、想定されている「[]」でIPv6 アドレスが区切られていませんでした。そのため、オーバークラウド向けに  IPv6 を有効化してデプロイする場合には、「Error: Parameter name failed on Ring_object_device ...」のエラーで操作が失敗していました。本リリースでは、IPv6 が有効化されると、swift_device および swift_proxy_memcache の URI の一部に使用される IP アドレスは「[]」で正しく区切られるようになりました。その結果、IPv6 を使用するデプロイメントは swift_device または swift_proxy_memcache の形式の間違いによって操作が失敗することはなくなりました。
今回の機能拡張により、ノードごとに hieradata を配置して、UUID (「dmidecode」で報告される) からノードを照合できるようになりました。
これにより、異なる数および種別のディスクを搭載した複数のノードにわたって CephStorage をスケーリングすることが可能です。
その結果、CephStorage ノードは、同種でないディスクのトポロジーで設定することが可能となりました。これは、ceph::profile::params::osds パラメーターに異なる設定ハッシュをプロビジョニングして設定します。
以前のリリースでは、os-collect-config ユーティリティーは、Puppet の実行終了後にのみ Puppet のログが出力されていました。そのため、実行中の Puppet run の Puppet ログは提供されませんでした。今回の更新では、Puppet run のログは、実行中でも出力されるようになりました。/var/run/heat-config/deployed/ ディレクトリーで確認することができます。
今回の更新では、neutron QoS (Quality of Service) の機能拡張により、テナントネットワークの品質と制限に対する制御が向上しました。オーバークラウドは Neutron QoS の機能拡張が有効な状態でデプロイされるようになりました。
Red Hat OpenStack Platform 8 の Orchestration サービス (heat) の検証がより厳格となり、アップグレードされたアンダークラウドからオーバークラウドスタックを更新しようとすると、以下のようなエラーメッセージが表示されて操作が失敗するようになりました。

ERROR heat.engine.resource ResourceFailure: resources.Compute: "u'1:1000'" is not a list. 

今回の修正で、NeutronVniRanges パラメーターが正しい形式となり、必要な「[]」が OpenStack Platform 7 openstack-tripleo-heat-templates パッケージにバックポートされ、openstack-tripleo-heat-templates-kilo-0.8.14-5.el7ost.noarch の時点で利用可能となっているはずです。アップグレードしたアンダークラウドで既存のオーバークラウドを管理する一方でバージョン 7 のテンプレート (/usr/share/openstack-tripleo-heat-templates/kilo に配置されている) を使用している場合に、オーバークラウドのスタック更新がエラーで失敗することはなくなりました。
今回の更新で、Neutron L2 population の機能を有効にできるようになりました。この機能は、テナントネットワークのブロードキャストトラフィックの量を低減するのに役立ちます。Neutron L2 population を有効にするには、環境ファイルの「default_parameter」セクションで NeutronEnableL2Pop パラメーターを設定してください。
director は外部コンシューマー向けの通知を適切に有効化するようになりました。
オーバークラウドノードのドメイン名はデフォルトで「localdomain」に設定されていました (例: overcloud-compute-0.localdomain)。今回の機能拡張により、ドメイン名をカスタマイズするためのパラメーター (CloudDomain) が提供されるようになりました。「parameter_defaults」セクションに CloudDomain パラメーターを記載した環境ファイルを作成します。ドメイン名が定義されていない場合には、Heat テンプレートによりデフォルトの「localdomain」が使用されます。
director は OpenStack Networking の「enable_isolated_metadata」オプションをサポートするようになりました。このオプションにより、外部のルータまたは分離されたネットワーク上の仮想マシンのインスタンスメタデータにアクセスすることが可能です。
以前のリリースでは、/etc/nova/nova.conf の [neutron] セクションの admin_auth_url 設定の末尾に「/v2.0」が記載されていませんでした。このため、Nova は Keystone カタログに接続して Neutron サービスエンドポイントをクエリーしてインスタンス用のポートを作成/バインドできなかったため、インスタンスをブートすることができませんでした。今回のリリースでは、admin_auth_url で指定される URL の末尾に「/v2.0」が正しく追加され、director を使用してオーバークラウドをデプロイした後でインスタンスが正常に起動できるようになりました。
director は、以下の OpenStack Networking サービスの無効化/有効化を制御する新しいパラメーターをサポートするようになりました。

* dhcp_agent
* l3_agent
* ovs_agent
* metadata_agent

今回の機能拡張により、上記のサービスのいずれかを置き換える Neutron プラグインのデプロイメントが可能となりました。これらのサービスをすべて無効にするには、環境ファイルで以下のパラメーターを使用してください。

  NeutronEnableDHCPAgent: false
  NeutronEnableL3Agent: false
  NeutronEnableMetadataAgent: false
  NeutronEnableOVSAgent: false
director は、Dell EqualLogic または Dell Storage Center アプライアンスをバックエンドとして使用する Block Storage サービスをデプロイできるようになりました。詳しい情報は、以下のリンクを参照してください。

https://access.redhat.com/documentation/en/red-hat-openstack-platform/version-8/dell-equallogic-back-end-guide/
https://access.redhat.com/documentation/en/red-hat-openstack-platform/8/dell-storage-center-back-end-guide/dell-storage-center-back-end-guide
以前のリリースでは、Identity サービスのエンドポイント登録コードのバグで、Telemetry サービスを SSL 対応としてマークする操作が失敗していました。この問題により、Telemetry サービスを HTTPS として登録することができませんでした。今回の更新でこのバグは修正され、Identity サービスは Telemetry を正しく登録し、Telemetry のトラフィックは想定通りに暗号化されるようになりました。
以前のリリースでは、ブリッジおよびボンディングに (Open vSwitch を使用する代わりに) Linux カーネルモードを使用する場合に、VLAN インターフェースの物理デバイスが検出されなかったため、VLAN インターフェースが正しく機能しませんでした。

今回のリリースでは、VLAN が物理ブリッジのメンバーである (つまり、VLAN がブリッジの「members:」セクションで指定されている) 限りは、os-net-config ユーティリティーが VLAN 用の物理インターフェースが自動検出されるようになりました。そのため、VLAN インターフェースは、OVS ブリッジおよび Linux カーネルブリッジの両方で適切に機能するようになりました。
以前のリリースでは、VLAN インターフェースは Linux カーネルのボンディングにブリッジなしで直接配置されていたので、VLAN がボンディングよりも先に起動する可能性がありました。そのような状況が発生すると、VLAN は起動に失敗していました。今回のリリースでは、os-net-config ユーティリティー が VLAN よりも先に物理ネットワーク (ブリッジ、ボンディング、インターフェースの順) を起動するようになりました。これにより、VLAN が適切に起動するために必要なインターフェースが確実に使用できるようになりました。
以前のリリースでは、バグにより、エラーが発生したノードが使用可能とマークされる可能性がありました。このような問題が発生すると必ず、ノードは適切な状態でなかったため、デプロイメントは失敗していました。今回の更新で、このバグを修正するアップストリームのパッチがバックポートされました。
以前のリリースでは、バルクイントロスペクションでは、オンスクリーンエラーのみが出力され、エラーのステータスコードは一切返されませんでした。この問題により、イントロスペクションのエラーが検出されるのが妨げられていました。 今回の更新により、エラーのステータスコードが 0 以外に変更され、イントロスペクションが失敗した場合には、ステータスコードで検出できるようになりました。
以前のリリースでは、メンテナンスモード中のノードにバルクイントロスペクションの操作が行われていたので、イントロスペクションが失敗したり、ノードのメンテナンスが中断したりしてしまうこともありました (ノードのメンテナンスの理由によって異なります)。今回のリリースでは、バルクイントロスペクションはメンテナンスモードのノードを無視するようになりました。
オーバークラウドのデプロイに (python-tripleoclient ではなく) python-rdomanager-oscplugin を使用する古いデプロイメントでは、HA ではない単一コントローラーのデプロイメントでも neutron の dhcp_agents_per_network パラメーターが最小で 3 に設定されていました。これは、1 コントローラーのみでデプロイする場合に、dhcp_agents_per_network が 3 に設定されていたことを意味します。今回の修正で、単一コントローラーのケースが考慮されるようになり、director は dhcp_agents_per_network を最大で 3 に設定し、コントローラーよりも多い数には設定しないようになりました。コントローラーノードが 3 台以上の HA でデプロイする場合には、それらのコントローラーノード上の neutron.conf 内のdhcp_agents_per_network の設定パラメーターは「3」に設定されます。また、コントローラーが 1 台のみの非 HA でデプロイする場合には、同じ dhcp_agents_per_network パラメーターは「1」に設定されます。
アンダークラウド上でパッケージを更新すると、アンダークラウドは不確定な状態になります。これは、パッケージ更新後にアンダークラウドのサービスの一部が無効になり、再度起動できなくなることを意味します。回避策として、「openstack undercloud install」を実行し、全アンダークラウドを再設定してください。コマンドが終了した後には、アンダークラウドサービスは通常通りに動作するようになります。
以前のリリースでは、Ramdisk およびカーネルのイメージは、特定のインターフェースを指定しなくてもブートしていました。これは、任意のネットワークアダプターからシステムが起動していたことになり、複数のインターフェースがプロビジョニングネットワーク上にある場合に問題が発生する原因となっていました。そのような場合には、システムがブートに使用するインターフェースを指定する必要がありました。指定するインターフェースは、MAC address from the instackenv.json ファイルからの MAC アドレスを保持するインターフェースに対応する必要があります。

回避策として、root ユーザーとして以下のテキストブロックをコピーし、director のターミナルに貼り付けます。これにより、ブート時に毎回、systemd の起動スクリプトが作成され、これらのパラメーターを設定します。

スクリプトには「net0/mac」を含む sed コマンドが記載されています。これにより、director が 1 番目の Ethernet インターフェースを使用するように設定されます。2 番目のインターフェースを使用するには、この値を「net1/mac」に変更してください。

#####################################
cat << EOF > /usr/bin/bootif-fix
#!/usr/bin/env bash

while true;
        do find /httpboot/ -type f ! -iname "kernel" ! -iname "ramdisk" ! -iname "*.kernel" ! -iname "*.ramdisk" -exec sed -i 's|{mac|{net0/mac|g' {} +;
done
EOF

chmod a+x /usr/bin/bootif-fix

cat << EOF > /usr/lib/systemd/system/bootif-fix.service
[Unit]
Description=Automated fix for incorrect iPXE BOOFIF

[Service]
Type=simple
ExecStart=/usr/bin/bootif-fix

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable bootif-fix
systemctl start bootif-fix

#######################################

bootif-fix スクリプトは、全ノードで実行されます。これにより、プロビジョニングネットワークに複数の NIC がある場合に、指定した NIC からブートできるようになります。サービスを無効にして以前の動作に戻すには、「systemctl disable bootif-fix」を実行してリブートします。
OpenStack Bare Metal (ironic) は、UEFI モードのノードのデプロイをサポートするようになりました。これは、UEFI ブートのみをサポートするサーバーをお使いのお客様からの要求によって実装されました。
以前のリリースでは、Nova EC2 API のヘルスチェックの設定が誤っていたため、HAProxy は API が停止しているものと判断していました。このため、API には HAProxy を介して到達できませんでした。今回の修正により、ヘルスチェックの設定が正しく変更され、API サービスの状態のクエリーを適正に実行できるようになったので、Nova EC2 API は HAProxy を介して到達可能となりました。
「baremetal」フレーバーは、director が使用していない場合でも必要なフレーバーです。このフレーバーがない場合には、デプロイメントはエラーが発生して失敗してしまいます。今回のリリースでは、アンダークラウドのインストールで「baremetal」フレーバーが自動的に作成されるようになりました。フレーバーが配置されると、director はエラーを報告しません。
以前のリリースでは、Ceilometer の設定で os_tenant_name の変数が「service」テナントではなく「admin」テナントに誤って指定されていたため、ceilometer-central-agent の操作は「ERROR ceilometer.agent.manager Skipping tenant, keystone issue: User 739a3abf8504498e91044d6d2a6830b1 is unauthorized for tenant d097e6c45c494c2cbef4071c2c273a58」のエラーで失敗していました。今回のリリースでは、Ceilometer が「service」テナントを使用するように正しく設定されました。
以前のリリースでは、アンダークラウドのアップグレード後に、openstack-nova-api サービスが再起動されなかったため、オーバークラウドでタイムアウトが発生して「ERROR: Timed out waiting for a reply to message ID 84a44ca3ed724eda991ba689cc364852」のエラーが報告され、操作が失敗していました。今回のリリースでは、アンダークラウドのアップグレードプロセスの一環で openstack-nova-api サービスが正しく再起動されるようになり、オーバークラウドのアップグレードプロセスはこのようなタイムアウトが発生することなく続行されるようになりました。

チャンネル	リポジトリー名
Red Hat Enterprise Linux 7 Server (RPMS)	`rhel-7-server-rpms`
Red Hat Enterprise Linux 7 Server - RH Common (RPMs)	`rhel-7-server-rh-common-rpms`
Red Hat Enterprise Linux High Availability (for RHEL 7 Server)	`rhel-ha-for-rhel-7-server-rpms`
Red Hat OpenStack Platform 8.0 (RPMS)	`rhel-7-server-openstack-8.0-rpms`
Red Hat OpenStack Platform Director 8.0 (RPMS)	`rhel-7-server-openstack-8.0-director-rpms`

チャンネル	リポジトリー名
Red Hat Enterprise Linux 7 Server - Optional	`rhel-7-server-optional-rpms`
Red Hat OpenStack Platform 8.0 Files	`rhel-7-server-openstack-8.0-files`
Red Hat OpenStack Platform 8.0 Operational Tools	`rhel7-server-openstack-8.0-optools-rpms`

チャンネル	リポジトリー名
Red Hat CloudForms Management Engine	`"cf-me-*"`
Red Hat Enterprise Virtualization	`"rhel-7-server-rhev*"`
Red Hat Enterprise Linux 7 Server - Extended Update Support	`"*-eus-rpms"`

Language and Page Formatting Options

Red Hat Training

リリースノート

Red Hat OpenStack Platform 8 リリースの詳細

OpenStack Documentation Team

第1章 はじめに

1.1. 本リリースについて

1.2. 要件

1.3. デプロイメント制限事項

1.4. データベースサイズの管理

1.5. 認定済みのドライバーとプラグイン

1.6. 認定済みゲストオペレーティングシステム

1.7. ハイパーバイザーのサポート

1.8. コンテンツ配信ネットワーク (CDN) チャンネル

1.9. 製品サポート

第2章 最も重要な新機能

2.1. Red Hat OpenStack Platform Director

2.2. Block Storage

2.3. Compute

2.4. Identity

2.5. Image サービス

2.6. Object Storage

2.7. OpenStack Networking

2.7.1. QoS

2.7.2. Open vSwitch の更新

2.7.3. ネットワークの RBAC

2.8. テクノロジープレビュー

2.8.1. 新規テクノロジープレビュー

2.8.2. 以前にリリースされたテクノロジープレビュー

第3章 リリースの情報

3.1. 機能拡張

3.2. リリースノート

3.3. 既知の問題

3.4. 非推奨の機能

第4章 テクニカルノート

4.1. RHEA-2016:0603 - Red Hat OpenStack Platform 8 機能拡張アドバイザリー

4.2. RHEA-2016:0604 - Red Hat OpenStack Platform 8 director 機能拡張アドバイザリー

付録A 改訂履歴

法律上の通知

Quick Links

Help

Site Info

Related Sites

Systems Status

About

Red Hat legal and privacy links

Red Hat legal and privacy links

第1章はじめに

第2章最も重要な新機能

第3章リリースの情報

第4章テクニカルノート