6.2. RHEA-2015:1549 — Red Hat Enterprise Linux OpenStack Platform director リリース

diskimage-builder で PyYAML の依存関係にあるパッケージが不足していたため、イメージのビルドの失敗の原因となっていました。今回の修正で依存関係が追加され、イメージのビルドが正常に実行できるようになりました。

diskimage-builder で PyYAML の依存関係にあるパッケージが不足していたため、イメージのビルドの失敗の原因となっていました。今回の修正で依存関係が追加され、イメージのビルドが正常に実行できるようになりました。

デプロイメントプロセスで deploy-baremetal-overcloudrc ファイルが使用されなくなりました。デプロイメントには「openstack overcloud deploy」コマンドと関連するコマンドライン引数が使用されるようになりました。

デプロイメントプロセスで deploy-baremetal-overcloudrc ファイルが使用されなくなりました。デプロイメントには「openstack overcloud deploy」コマンドと関連するコマンドライン引数が使用されるようになりました。

RabbitMQ の設定に重複行があったため、アンダークラウドのインストールに失敗していました。今回の修正により、重複行が削除され、アンダークラウドのインストールが正常に実行できるようになりました。

RabbitMQ の設定に重複行があったため、アンダークラウドのインストールに失敗していました。今回の修正により、重複行が削除され、アンダークラウドのインストールが正常に実行できるようになりました。

openstack-ironic-discoverd サービスは起動時に openstack-ironic-api の有無を確認していました。再起動時には、ブート順が原因で openstack-ironic-discoverd は openstack-ironic-api の検出に失敗していました。今回の修正により、openstack-ironic-discoverd の起動コード更新され、openstack-ironic-api の有無をチェックする必要がなくなり、再起動時には全サービスが正常に起動するようになりました。

openstack-ironic-discoverd サービスは起動時に openstack-ironic-api の有無を確認していました。再起動時には、ブート順が原因で openstack-ironic-discoverd は openstack-ironic-api の検出に失敗していました。今回の修正により、openstack-ironic-discoverd の起動コード更新され、openstack-ironic-api の有無をチェックする必要がなくなり、再起動時には全サービスが正常に起動するようになりました。

Ironic/Heat systemd サービスファイルの一時的なエラーにより、ログが誤ってリダイレクトされていました。今回の修正により、Ironic/Heat のサービスファイルが修正され、ログが正しいファイルにリダイレクトされるようになりました。

Ironic/Heat systemd サービスファイルの一時的なエラーにより、ログが誤ってリダイレクトされていました。今回の修正により、Ironic/Heat のサービスファイルが修正され、ログが正しいファイルにリダイレクトされるようになりました。

ironic-discoverd の edeploy プラグインは、過剰な情報を収集して SQL blob に保管していました。Ironic に edeploy データがポストされると、コラムがオーバーフローしてしまうため、検出が失敗していました。今回の修正により、edeploy プラグインはアンダークラウド上の Swift オブジェクトにデータを格納し、edeploy プラグインを使用しても検出は失敗しないようになりました。

ironic-discoverd の edeploy プラグインは、過剰な情報を収集して SQL blob に保管していました。Ironic に edeploy データがポストされると、コラムがオーバーフローしてしまうため、検出が失敗していました。今回の修正により、edeploy プラグインはアンダークラウド上の Swift オブジェクトにデータを格納し、edeploy プラグインを使用しても検出は失敗しないようになりました。

オーバークラウドノードでホスト名が適切に設定されていなかったため、Pacemaker がクラスターメンバーの名前を解決できませんでした。今回の修正では、ホスト名が短くなり、Nova と Neutron は無効なドメイン名を追記しなくなりました。

オーバークラウドノードでホスト名が適切に設定されていなかったため、Pacemaker がクラスターメンバーの名前を解決できませんでした。今回の修正では、ホスト名が短くなり、Nova と Neutron は無効なドメイン名を追記しなくなりました。

今回のリリースでは、新な機能拡張により、分離されたネットワークに特定の IP アドレス範囲を確保することができます。 

その結果、オーバークラウドの Orchestration のテンプレートで以下のパラメーターを設定して、IP アドレスを確保できるようなりました。

InternalApiAllocationPools
StorageAllocationPools
StorageMgmtAllocationPools
TenantAllocationPools
ExternalAllocationPools

今回のリリースでは、新な機能拡張により、分離されたネットワークに特定の IP アドレス範囲を確保することができます。 

その結果、オーバークラウドの Orchestration のテンプレートで以下のパラメーターを設定して、IP アドレスを確保できるようなりました。

InternalApiAllocationPools
StorageAllocationPools
StorageMgmtAllocationPools
TenantAllocationPools
ExternalAllocationPools

今回のリリースでは、Compute VNC プロキシーネットワークを設定できるようになりました。これにより、さまざまなネットワークを分離して、どこでどのサービスを実行するかを指定できます。

その結果、オーバークラウドの Orchestration のテンプレートで  ServiceNetMap -> NovaVncProxyNetwork のパラメーターを設定して Compute VNC プロキシーに使用するネットワークを指定できるようになりました。

今回のリリースでは、Compute VNC プロキシーネットワークを設定できるようになりました。これにより、さまざまなネットワークを分離して、どこでどのサービスを実行するかを指定できます。

その結果、オーバークラウドの Orchestration のテンプレートで  ServiceNetMap -> NovaVncProxyNetwork のパラメーターを設定して Compute VNC プロキシーに使用するネットワークを指定できるようになりました。

今回の機能拡張により、Heat のテンプレートに VLAN 識別子と OVS ボンディングのオプションが追加され、設定の重複が少くなりました。Heat のテンプレートには、次のパラメーターが含まれるようになりました。BondInterfaceOvsOptions、StorageNetworkVlanID、StorageMgmtNetworkVlanID、InternalApiNetworkVlanID、TenantNetworkVlanID、ExternalNetworkVlanID

今回の機能拡張により、Heat のテンプレートに VLAN 識別子と OVS ボンディングのオプションが追加され、設定の重複が少くなりました。Heat のテンプレートには、次のパラメーターが含まれるようになりました。BondInterfaceOvsOptions、StorageNetworkVlanID、StorageMgmtNetworkVlanID、InternalApiNetworkVlanID、TenantNetworkVlanID、ExternalNetworkVlanID

HAProxy が Horizon のリスナーの設定に失敗するため、パブリックの仮想 IP アドレスで Horizon が利用できなくなっていました。今回の修正で、HAProxy Horizon リスナーが有効化され、Horizon Dashboard はパブリックの仮想 IP アドレスで利用できるようになりました。

HAProxy が Horizon のリスナーの設定に失敗するため、パブリックの仮想 IP アドレスで Horizon が利用できなくなっていました。今回の修正で、HAProxy Horizon リスナーが有効化され、Horizon Dashboard はパブリックの仮想 IP アドレスで利用できるようになりました。

Ceilometer が backend_url に誤った redis の仮想 IP アドレスを使用していました。今回の修正では、Ceilometer の backend_url は、Heat が提供する値に設定され、デプロイメント中には構築されないようになったため、Ceilometer は正しい IP アドレスを使用するようになりました。

Ceilometer が backend_url に誤った redis の仮想 IP アドレスを使用していました。今回の修正では、Ceilometer の backend_url は、Heat が提供する値に設定され、デプロイメント中には構築されないようになったため、Ceilometer は正しい IP アドレスを使用するようになりました。

ソケットバインディングの競合が原因で、novncproxy サービスの起動が失敗していました。このため、novncproxy サービスが利用できませんでした。今回の修正により、novncproxy サービスはコントローラーの internal_api アドレスでのみバインディングするように設定されるようになり、novncproxy が正常に起動するようになりました。

ソケットバインディングの競合が原因で、novncproxy サービスの起動が失敗していました。このため、novncproxy サービスが利用できませんでした。今回の修正により、novncproxy サービスはコントローラーの internal_api アドレスでのみバインディングするように設定されるようになり、novncproxy が正常に起動するようになりました。

以前のリリースでは、neutron-server の初回実行時には、neutron データベースの初期化中に競合状態が発生していました。このエラーは、2 つのコントローラーが偶然に neutron-server を同時に起動しようとした場合に発生していました。このため、競合に負けたコントローラーでは neutron-server とエージェントの起動でエラーが発生し、その影響を受けたコントローラーノードで、Neutron のサービスの起動が失敗していました。ログには以下のようなエラーが記録されていました。

 DBDuplicateEntry: (IntegrityError) (1062, "Duplicate entry 'datacentre-1' for key 'PRIMARY'") 'INSERT INTO ml2_vlan_allocations (physical_network, vlan_id, allocated) VALUES (%s, %s, %s)' (('datacentre', 1, 0),

今回のリリースでは、Neutron サーバーは一時的に起動してから 1 つのノード (pacemaker master) で停止し、データベースの初期設定が実行されてから残りのpuppet や pacemaker の設定が実行されるようになりました。その結果、Neutron のサービスは全コントローラーノードで正常に起動されるようになりました。

以前のリリースでは、neutron-server の初回実行時には、neutron データベースの初期化中に競合状態が発生していました。このエラーは、2 つのコントローラーが偶然に neutron-server を同時に起動しようとした場合に発生していました。このため、競合に負けたコントローラーでは neutron-server とエージェントの起動でエラーが発生し、その影響を受けたコントローラーノードで、Neutron のサービスの起動が失敗していました。ログには以下のようなエラーが記録されていました。

 DBDuplicateEntry: (IntegrityError) (1062, "Duplicate entry 'datacentre-1' for key 'PRIMARY'") 'INSERT INTO ml2_vlan_allocations (physical_network, vlan_id, allocated) VALUES (%s, %s, %s)' (('datacentre', 1, 0),

今回のリリースでは、Neutron サーバーは一時的に起動してから 1 つのノード (pacemaker master) で停止し、データベースの初期設定が実行されてから残りのpuppet や pacemaker の設定が実行されるようになりました。その結果、Neutron のサービスは全コントローラーノードで正常に起動されるようになりました。

mongodb ノードの一覧は、1 つのコントローラーノードでしか構築できず、他の全コントローラーノードでは mongodb ノードの空の一覧を使用して Ceilometer が設定されていました。今回の修正で、mongodb ノードは全コントローラーノード上で一覧表示できるようになり、Ceilometer は、適切に作成された mongodb ノードの一覧を使用して設定されます。

mongodb ノードの一覧は、1 つのコントローラーノードでしか構築できず、他の全コントローラーノードでは mongodb ノードの空の一覧を使用して Ceilometer が設定されていました。今回の修正で、mongodb ノードは全コントローラーノード上で一覧表示できるようになり、Ceilometer は、適切に作成された mongodb ノードの一覧を使用して設定されます。

HAProxy バックエンドの設定が誤っていたため、HAProxy は glance-registry サービスの要求をオフラインのノードに送信していました。今回の修正により、glance-registry サービスの更新をモニタリングしてオフラインのノードを確実に検出するようになりました。

HAProxy バックエンドの設定が誤っていたため、HAProxy は glance-registry サービスの要求をオフラインのノードに送信していました。今回の修正により、glance-registry サービスの更新をモニタリングしてオフラインのノードを確実に検出するようになりました。

Galera の HAProxy リスナーは ctlplane アドレスにバインディングしていたため、ネットワークを分離したオーバークラウドを使用している場合にはクライアントが Galera サービスに到達できませんでした。今回の修正では、HAProxy Galera リスナーがバインディングするアドレスが  internal_api network 内の仮想 IP アドレスに変更され、クライアントはネットワークを分離したオーバークラウド上で Galera サービスに到達できるようになりました。

Galera の HAProxy リスナーは ctlplane アドレスにバインディングしていたため、ネットワークを分離したオーバークラウドを使用している場合にはクライアントが Galera サービスに到達できませんでした。今回の修正では、HAProxy Galera リスナーがバインディングするアドレスが  internal_api network 内の仮想 IP アドレスに変更され、クライアントはネットワークを分離したオーバークラウド上で Galera サービスに到達できるようになりました。

HAProxy は、MariaDB のバックエンドのステータスチェックに clustercheck を使用していませんでした。このため、HAProxy は、TCP チェックに応答して MariaDB ノードに要求を送信していまいたが、Galera クラスターとは同期されていませんでした。今回の修正により、HAProxy は clustercheck を使用して MariaDB のバックエンドのステータスをチェックし、MariaDB ノードに対して要求を正しく送信します。

HAProxy は、MariaDB のバックエンドのステータスチェックに clustercheck を使用していませんでした。このため、HAProxy は、TCP チェックに応答して MariaDB ノードに要求を送信していまいたが、Galera クラスターとは同期されていませんでした。今回の修正により、HAProxy は clustercheck を使用して MariaDB のバックエンドのステータスをチェックし、MariaDB ノードに対して要求を正しく送信します。

distro-specific hieradata ファイルは、オーバークラウドノードには適用されませんでした。今回の修正により、全オーバークラウドノードに配布するための静的な RedHat.yaml が提供されるようになりました。

distro-specific hieradata ファイルは、オーバークラウドノードには適用されませんでした。今回の修正により、全オーバークラウドノードに配布するための静的な RedHat.yaml が提供されるようになりました。

mariadb サービスがブート時に起動していたため、再起動の後には、Pacemaker の mariadb リソースでエラーが発生していました。今回の修正により、ブート時に mariadb サービスが自動的に起動しないようになり、mariadb は Pacemaker リソースとして完全に制御されるようになりました。

mariadb サービスがブート時に起動していたため、再起動の後には、Pacemaker の mariadb リソースでエラーが発生していました。今回の修正により、ブート時に mariadb サービスが自動的に起動しないようになり、mariadb は Pacemaker リソースとして完全に制御されるようになりました。

Keystone サービスは、Pacemaker を介して起動する他に、Pacemaker 内の Ceilometer リソースの systemd の依存関係としても起動していました。そのため、Keystone の 2 つのバージョン間で競合が発生し、Pacemaker Keystone リソースの起動が失敗していました。今回の修正により、Pacemaker には、Keystone リソースが起動するまで Ceilometer リソースを停止する制約が追加されました。Keystone は Ceilometer よりも前に起動するようになり、Keystone サービスは systemd を介して起動されなくなりました。

Keystone サービスは、Pacemaker を介して起動する他に、Pacemaker 内の Ceilometer リソースの systemd の依存関係としても起動していました。そのため、Keystone の 2 つのバージョン間で競合が発生し、Pacemaker Keystone リソースの起動が失敗していました。今回の修正により、Pacemaker には、Keystone リソースが起動するまで Ceilometer リソースを停止する制約が追加されました。Keystone は Ceilometer よりも前に起動するようになり、Keystone サービスは systemd を介して起動されなくなりました。

director のプランを使用したデプロイメントは、ControlPlaneNetwork パラメーターが不足していたため、Heat テンプレートをベースとしたデプロイメントとは動作が異なりました。このため、プランベースのオーバークラウドデプロイメントは、ネットワークの分離を使用すると失敗していました。今回の修正により、ControlPlaneNetwork パラメーターが追加されたパッチが提供され、オーバークラウドのデプロイメントを正常に実行できるようになりました。

director のプランを使用したデプロイメントは、ControlPlaneNetwork パラメーターが不足していたため、Heat テンプレートをベースとしたデプロイメントとは動作が異なりました。このため、プランベースのオーバークラウドデプロイメントは、ネットワークの分離を使用すると失敗していました。今回の修正により、ControlPlaneNetwork パラメーターが追加されたパッチが提供され、オーバークラウドのデプロイメントを正常に実行できるようになりました。

Heat のサービスが、関係のない redis の仮想 IP アドレスの再配置で再起動していました。Pacemaker では、Heat リソースの再起動が失敗してしまいました。これは、クラスタリングのエラーにより、redis の仮想 IP アドレスの再配置時に再起動に失敗する Ceilometer リソースに対する依存関係が原因でした。今回の修正により、Ceilometer の再起動時に Heat が再起動しないようになりました。

Heat のサービスが、関係のない redis の仮想 IP アドレスの再配置で再起動していました。Pacemaker では、Heat リソースの再起動が失敗してしまいました。これは、クラスタリングのエラーにより、redis の仮想 IP アドレスの再配置時に再起動に失敗する Ceilometer リソースに対する依存関係が原因でした。今回の修正により、Ceilometer の再起動時に Heat が再起動しないようになりました。

ネットワークの分離を有効化したオーバークラウド上では、Pacemaker は、redis master が到達できないネットワーク上のホスト名に radis master を設定していたため、redis ノードはクラスターへの参加に失敗していました。今回の修正により、ネットワークの分離を有効にしてデプロイを行う場合には、Pacemaker のホスト名が internal_api アドレスに対して解決されるようになりました。

ネットワークの分離を有効化したオーバークラウド上では、Pacemaker は、redis master が到達できないネットワーク上のホスト名に radis master を設定していたため、redis ノードはクラスターへの参加に失敗していました。今回の修正により、ネットワークの分離を有効にしてデプロイを行う場合には、Pacemaker のホスト名が internal_api アドレスに対して解決されるようになりました。

以前のリリースでは、OpenStack は、NeutronScale puppet リソースを使用していました。このリソースは、コントローラー上で有効化され、neutron エージェントの「host」エントリーをコントローラー 0 では「neutron-n-0」、コントーラー 1 では「neutron-n-1」というように書き換えてタスク化されていました。この名前変更はデプロイメントの後半に、対応する neutron-scale リソースが Pacemaker によって起動される時点に実行されていました。L3 HA 用の L3 エージェントの不足の大半は仮想マシンの環境で発生し、neutron によって報告されて、オーバークラウドの neutron agent-list で不整合が生じました。このため、場合によっては、Neutron からのエラーメッセージで、HA を提供するための L3 エージェントが不足していることを示すエラーが自動的に宣言されていました (デフォルトの最小値 2)。オーバークラウドに対して「neutron agent-list」コマンドを実行すると、エージェントの不整合が表示されました。たとえば、ホスト「overcloud-controller-1.localdomain」上の元のエージェント (通常は "XXX" と表示される) と、ホスト「neutron-n-1」(「:-)」のステータスで稼働中) 上の「より新しい」エージェントの両方で、各エージェントのエントリー重複などがありました。また、エージェントの名前変更により、コントローラーが 1 つしかない場合に neutron エージェントの 1 つである openvswitch にエラーが発生し、配下にあるそれ以外のエージェントも連鎖されているため起動に失敗して、L3、メタデータ、dhcp エージェントがない状態となりました。

この問題は、ネイティブの neutron L3 High Availability を使用することと、ネイティブの neutron HA でネットワークごとに十分な DHCP エージェントを有効化することで修正されました。DHCP エージェント数は、以前は、すべての場合で 2 に静的に設定されていたので、追加が必要でした。これは、設定可能なパラメーターとして tripleo の Heat テンプレートに追加され、デフォルト値は「3」となりました。また、oscplugin でデプロイするために連携されました。NeutronScale のリソース自体は tripleo の Heat テンプレートから削除されましたが、オーバークラウドコントローラーの puppet マニフェストは維持されました。その結果、この修正の後に作成されたデプロイメントにはコントローラーノードに neutron-scale リソースはありません。これは、以下のコマンドで確認することができます。

1. コントローラーノードで以下のコマンドを実行します。
# pcs status | grep -n neutron -A 1

「neutron-scale」クローンセットまたはリソースの定義は表示されないはずです。

2. アンダークラウドで以下のコマンドを実行します。
$ source overcloudrc
$ neutron agent-list

すべての neutron エージェントは、「neutron-n-0」、「neutron-n-2」のような名前ではなく、「overcloud-controller-0.localdomain」、「overcloud-controller-2.localdomain」などの名前でホスト上に存在することが報告されるはずです。

以前のリリースでは、OpenStack は、NeutronScale puppet リソースを使用していました。このリソースは、コントローラー上で有効化され、neutron エージェントの「host」エントリーをコントローラー 0 では「neutron-n-0」、コントーラー 1 では「neutron-n-1」というように書き換えてタスク化されていました。この名前変更はデプロイメントの後半に、対応する neutron-scale リソースが Pacemaker によって起動される時点に実行されていました。L3 HA 用の L3 エージェントの不足の大半は仮想マシンの環境で発生し、neutron によって報告されて、オーバークラウドの neutron agent-list で不整合が生じました。このため、場合によっては、Neutron からのエラーメッセージで、HA を提供するための L3 エージェントが不足していることを示すエラーが自動的に宣言されていました (デフォルトの最小値 2)。オーバークラウドに対して「neutron agent-list」コマンドを実行すると、エージェントの不整合が表示されました。たとえば、ホスト「overcloud-controller-1.localdomain」上の元のエージェント (通常は "XXX" と表示される) と、ホスト「neutron-n-1」(「:-)」のステータスで稼働中) 上の「より新しい」エージェントの両方で、各エージェントのエントリー重複などがありました。また、エージェントの名前変更により、コントローラーが 1 つしかない場合に neutron エージェントの 1 つである openvswitch にエラーが発生し、配下にあるそれ以外のエージェントも連鎖されているため起動に失敗して、L3、メタデータ、dhcp エージェントがない状態となりました。

この問題は、ネイティブの neutron L3 High Availability を使用することと、ネイティブの neutron HA でネットワークごとに十分な DHCP エージェントを有効化することで修正されました。DHCP エージェント数は、以前は、すべての場合で 2 に静的に設定されていたので、追加が必要でした。これは、設定可能なパラメーターとして tripleo の Heat テンプレートに追加され、デフォルト値は「3」となりました。また、oscplugin でデプロイするために連携されました。NeutronScale のリソース自体は tripleo の Heat テンプレートから削除されましたが、オーバークラウドコントローラーの puppet マニフェストは維持されました。その結果、この修正の後に作成されたデプロイメントにはコントローラーノードに neutron-scale リソースはありません。これは、以下のコマンドで確認することができます。

1. コントローラーノードで以下のコマンドを実行します。
# pcs status | grep -n neutron -A 1

「neutron-scale」クローンセットまたはリソースの定義は表示されないはずです。

2. アンダークラウドで以下のコマンドを実行します。
$ source overcloudrc
$ neutron agent-list

すべての neutron エージェントは、「neutron-n-0」、「neutron-n-2」のような名前ではなく、「overcloud-controller-0.localdomain」、「overcloud-controller-2.localdomain」などの名前でホスト上に存在することが報告されるはずです。

コントローラーノードは consoleauth トークンを共有していなかったため、認証要求のプロセスの一部でエラーが発生していました。今回の修正により、consoleauth トークンを共有するための memcached が導入され、認証要求は正常に処理されるようになりました。

コントローラーノードは consoleauth トークンを共有していなかったため、認証要求のプロセスの一部でエラーが発生していました。今回の修正により、consoleauth トークンを共有するための memcached が導入され、認証要求は正常に処理されるようになりました。

今回のリリースでは、GRE トンネル ID を制御する neutron_tunnel_id_ranges パラメーターと、VXLAN トンネル ID を制御する neutron_vni_ranges のパラメーターを設定できるようになりました。これらは、オーバークラウドの Neutron によってオーバークラウドのテナントネットワーク用に提供されます。たとえば、以下のように指定することができます。 

# openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 1  --neutron-tunnel-id-ranges "1:1111,2:2222" --neutron-vni-ranges "3:33,5:55,100:999" --neutron-tunnel-types "gre,vxlan"

指定しなかった場合には、tunnel_id_ranges と neutron_vni_ranges はいずれもデフォルトで「1:1000」となります。この値は、一部のデプロイメントシナリオでは不適切または限定的となる場合があります。

上記の例に示したようにデプロイする場合には、コントローラーノードで (デプロイ後に) 関連する Neutron の設定ファイルを検査/確認することができます。以下に例を示します。

# grep -rni 'vni_ranges\|id_ranges\|tunnel_types' /etc/neutron/*
/etc/neutron/plugin.ini:78:tunnel_id_ranges =1:1111,2:2222
/etc/neutron/plugin.ini:85:vni_ranges =3:33,5:55,100:999
/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:77:tunnel_types =gre,vxlan
/etc/neutron/plugins/ml2/ml2_conf.ini:78:tunnel_id_ranges =1:1111,2:2222
/etc/neutron/plugins/ml2/ml2_conf.ini:85:vni_ranges =3:33,5:55,100:999

オーバークラウドネットワークを作成することによって (この場合もデプロイ後に) テストすることができます。以下はその例です。

# source overcloudrc # from the undercloud box for example
# neutron net-create --provider:network_type "vxlan" "foo"

このコマンドにより、vxlan タイプのネットワークが作成されます。検査をして、特定の vni_ranges からセグメンテーション ID を受信したことを確認することができます。

# neutron net-show foo
| provider:network_type     | vxlan
| provider:segmentation_id  | 3

同様に、適切なセグメンテーション ID が GRE ネットワークに割り当てられていることを確認することができます。

今回のリリースでは、GRE トンネル ID を制御する neutron_tunnel_id_ranges パラメーターと、VXLAN トンネル ID を制御する neutron_vni_ranges のパラメーターを設定できるようになりました。これらは、オーバークラウドの Neutron によってオーバークラウドのテナントネットワーク用に提供されます。たとえば、以下のように指定することができます。 

# openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 1  --neutron-tunnel-id-ranges "1:1111,2:2222" --neutron-vni-ranges "3:33,5:55,100:999" --neutron-tunnel-types "gre,vxlan"

指定しなかった場合には、tunnel_id_ranges と neutron_vni_ranges はいずれもデフォルトで「1:1000」となります。この値は、一部のデプロイメントシナリオでは不適切または限定的となる場合があります。

上記の例に示したようにデプロイする場合には、コントローラーノードで (デプロイ後に) 関連する Neutron の設定ファイルを検査/確認することができます。以下に例を示します。

# grep -rni 'vni_ranges\|id_ranges\|tunnel_types' /etc/neutron/*
/etc/neutron/plugin.ini:78:tunnel_id_ranges =1:1111,2:2222
/etc/neutron/plugin.ini:85:vni_ranges =3:33,5:55,100:999
/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:77:tunnel_types =gre,vxlan
/etc/neutron/plugins/ml2/ml2_conf.ini:78:tunnel_id_ranges =1:1111,2:2222
/etc/neutron/plugins/ml2/ml2_conf.ini:85:vni_ranges =3:33,5:55,100:999

オーバークラウドネットワークを作成することによって (この場合もデプロイ後に) テストすることができます。以下はその例です。

# source overcloudrc # from the undercloud box for example
# neutron net-create --provider:network_type "vxlan" "foo"

このコマンドにより、vxlan タイプのネットワークが作成されます。検査をして、特定の vni_ranges からセグメンテーション ID を受信したことを確認することができます。

# neutron net-show foo
| provider:network_type     | vxlan
| provider:segmentation_id  | 3

同様に、適切なセグメンテーション ID が GRE ネットワークに割り当てられていることを確認することができます。

以前のリリースでは、オーバークラウドの Keystone admin テナントの作成が連携されていなかったため、複数のコントローラーを使用するデプロイメントでエラーが発生していました。このため、Heat のスタック作成が ControllerNodesPostDeployment リソースで失敗して、Keystone が「openstack Conflict occurred attempting to store project - Duplicate Entry (HTTP 409)」という 409 エラーを返し、この時点で Puppet の実行が失敗してしまいました。今回のリリースでは、この問題の修正で、最初にpacemaker master ノード上で admin テナントを作成するプロセスが追加されました。その結果、複数のコントローラーを使用するデプロイメントで、オーバークラウドの Keystone admin ユーザーが正しく作成されるようになりました。これは、デプロイが成功した後に管理ユーザーとして任意のオーバークラウドサービスと対話することによって確認することができます。

# on the undercloud system, for example:
$ source overcloudrc
$ keystone user-list

以前のリリースでは、オーバークラウドの Keystone admin テナントの作成が連携されていなかったため、複数のコントローラーを使用するデプロイメントでエラーが発生していました。このため、Heat のスタック作成が ControllerNodesPostDeployment リソースで失敗して、Keystone が「openstack Conflict occurred attempting to store project - Duplicate Entry (HTTP 409)」という 409 エラーを返し、この時点で Puppet の実行が失敗してしまいました。今回のリリースでは、この問題の修正で、最初にpacemaker master ノード上で admin テナントを作成するプロセスが追加されました。その結果、複数のコントローラーを使用するデプロイメントで、オーバークラウドの Keystone admin ユーザーが正しく作成されるようになりました。これは、デプロイが成功した後に管理ユーザーとして任意のオーバークラウドサービスと対話することによって確認することができます。

# on the undercloud system, for example:
$ source overcloudrc
$ keystone user-list

オーバークラウドのデプロイ時に、Tuskar が Heat スタック内のトップレベルパラメーターの名前を変更していたため、Heat からのスタック検証中にエラーが発生していました。

ERROR: The Parameter (NeutronExternalNetworkBridge) was not defined in template.

この問題を回避するには、「tuskar plan-update」を使用してパラメーターを変更するか、環境ファイル内の変更されたパラメーター名を使用します。

parameters:
  Controller-1::NeutronExternalNetworkBridge: "''"

オーバークラウドは正しいパラメーター値を使用してデプロイを行います。

注記: パラメーターは、「parameter_defaults:」のセクションではなく、「parameters:」のセクションで定義する必要があります。正しく定義しなかった場合には、Tuskar のエクスポートされた environment.yaml によって値がオーバーライドされます。

オーバークラウドのデプロイ時に、Tuskar が Heat スタック内のトップレベルパラメーターの名前を変更していたため、Heat からのスタック検証中にエラーが発生していました。

ERROR: The Parameter (NeutronExternalNetworkBridge) was not defined in template.

この問題を回避するには、「tuskar plan-update」を使用してパラメーターを変更するか、環境ファイル内の変更されたパラメーター名を使用します。

parameters:
  Controller-1::NeutronExternalNetworkBridge: "''"

オーバークラウドは正しいパラメーター値を使用してデプロイを行います。

注記: パラメーターは、「parameter_defaults:」のセクションではなく、「parameters:」のセクションで定義する必要があります。正しく定義しなかった場合には、Tuskar のエクスポートされた environment.yaml によって値がオーバーライドされます。

Compute ノードは、Cinder publicurl エンドポイントにアクセスするには、接続可能であるかどうかにかかわらず、Keystone に対してクエリーを実行していました。このため、コンピュート専用のノードは Cinder API との対話に失敗していました。今回の修正により、publicurl エンドポイントは internalurl エンドポイントに変更され、コンピュートノードがアクセスできるようになりました。

Compute ノードは、Cinder publicurl エンドポイントにアクセスするには、接続可能であるかどうかにかかわらず、Keystone に対してクエリーを実行していました。このため、コンピュート専用のノードは Cinder API との対話に失敗していました。今回の修正により、publicurl エンドポイントは internalurl エンドポイントに変更され、コンピュートノードがアクセスできるようになりました。

Cinder ストレージノードは、Nova および Swift の publicurl エンドポイントにアクセスするは、接続可能であるかどうかにかかわらず、Keystone に対してクエリーを実行していました。このため、Cinder ストレージ専用ノードは Nova および Swift API と対話することができませんでした。今回の修正により、publicurl エンドポイントは internalurl エンドポイントに変更され、Cinder ストレージノードは、Nova および Swift API と正常に通信できるようになりました。

Cinder ストレージノードは、Nova および Swift の publicurl エンドポイントにアクセスするは、接続可能であるかどうかにかかわらず、Keystone に対してクエリーを実行していました。このため、Cinder ストレージ専用ノードは Nova および Swift API と対話することができませんでした。今回の修正により、publicurl エンドポイントは internalurl エンドポイントに変更され、Cinder ストレージノードは、Nova および Swift API と正常に通信できるようになりました。

今回のリリースの以前は、Neutron の allow_overlapping_ips 設定がデフォルトのままになっていたため、Neutron では、allow_overlapping_ips が無効化され、同じ範囲を使用して複数のネットワークを定義することができませんでした。この問題は、allow_overlapping_ips を「true」に設定することで修正されました。その結果、重複する範囲を使用してネットワークを定義できるようになりました。

今回のリリースの以前は、Neutron の allow_overlapping_ips 設定がデフォルトのままになっていたため、Neutron では、allow_overlapping_ips が無効化され、同じ範囲を使用して複数のネットワークを定義することができませんでした。この問題は、allow_overlapping_ips を「true」に設定することで修正されました。その結果、重複する範囲を使用してネットワークを定義できるようになりました。

以前のリリースでは、デフォルトの Ceph スケールは 1 に設定されていたため、ユーザーが必要としていない場合にも Ceph ノードが作成されていました。

今回のリリースでは、デフォルトの Ceph スケールが変更され、0 に設定されるようになりました。その結果、Ceph はデフォルトではデプロイされないようになりました。

以前のリリースでは、デフォルトの Ceph スケールは 1 に設定されていたため、ユーザーが必要としていない場合にも Ceph ノードが作成されていました。

今回のリリースでは、デフォルトの Ceph スケールが変更され、0 に設定されるようになりました。その結果、Ceph はデフォルトではデプロイされないようになりました。

os-apply-config コマンドを実行すると、パーミッションの制限がない /etc/puppet/hieradata が作成されていました。このディレクトリー内のファイルには、OpenStack のシステムに無許可のアクセスが可能となるパスワードとトークンが含まれていました。今回の修正により、/etc/puppet/hieradata は、root が所有するディレクトリーとして、0700 のパーミッションが設定されました。その結果、/etc/puppet/hieradata には root ユーザーのみがアクセス可能となり、システムのセキュリティーが強化されました。

os-apply-config コマンドを実行すると、パーミッションの制限がない /etc/puppet/hieradata が作成されていました。このディレクトリー内のファイルには、OpenStack のシステムに無許可のアクセスが可能となるパスワードとトークンが含まれていました。今回の修正により、/etc/puppet/hieradata は、root が所有するディレクトリーとして、0700 のパーミッションが設定されました。その結果、/etc/puppet/hieradata には root ユーザーのみがアクセス可能となり、システムのセキュリティーが強化されました。

オーバークラウドノードのシステム時刻の同期が正しく行われていませんでした。このため、HA コントローラークラスター全体で、さまざまなエラーが発生していました。この問題を回避するには、「openstack overcloud deploy」コマンドを実行する際に、コマンドライン引数 --ntp-server を渡します。この引数により、各オーバークラウド上の /etc/ntp.conf 内の ntp サーバーが設定されるので、システム時刻が正しく同期されて、Overcloud デプロイメントを正常に実行することができます。

オーバークラウドノードのシステム時刻の同期が正しく行われていませんでした。このため、HA コントローラークラスター全体で、さまざまなエラーが発生していました。この問題を回避するには、「openstack overcloud deploy」コマンドを実行する際に、コマンドライン引数 --ntp-server を渡します。この引数により、各オーバークラウド上の /etc/ntp.conf 内の ntp サーバーが設定されるので、システム時刻が正しく同期されて、Overcloud デプロイメントを正常に実行することができます。

以前のリリースでは、puppet デプロイメントへの移行により、boot-stack tripleo-image-element が初期 Tuskar データベースを作成しなくなりました。そのため、アンダークラウドのインストールが成功した後に、Tuskar サービスが正しく設定されませんでした。今回のリリースでは、アンダークラウドに Tuskar が正しくインストール/設定されるようになったので、アンダークラウドが正常にインストールされた後には Tuskar サービスと対話することができます。

以前のリリースでは、puppet デプロイメントへの移行により、boot-stack tripleo-image-element が初期 Tuskar データベースを作成しなくなりました。そのため、アンダークラウドのインストールが成功した後に、Tuskar サービスが正しく設定されませんでした。今回のリリースでは、アンダークラウドに Tuskar が正しくインストール/設定されるようになったので、アンダークラウドが正常にインストールされた後には Tuskar サービスと対話することができます。

tuskar のサービス設定パラメーター auth_strategy がデフォルトで「noauth」に設定されていました。これにより、tuskar の管理プランとロールに無制限なアクセスが可能でした。これには、テンプレートやパスワードなどが設定されている機密のパラメーターがすべて含まれます。今回の修正により、このパラメーターはデフォルトで keystone 認証に設定され、tuskar サービスに対する http 要求が認証されていない場合には、HTTP 401 Unauthorized のエラーが返されるようになりました。これを確認するには、アンダークラウドから以下のコマンドを実行します。

$ curl -v localhost:8585/v2/plans

tuskar のサービス設定パラメーター auth_strategy がデフォルトで「noauth」に設定されていました。これにより、tuskar の管理プランとロールに無制限なアクセスが可能でした。これには、テンプレートやパスワードなどが設定されている機密のパラメーターがすべて含まれます。今回の修正により、このパラメーターはデフォルトで keystone 認証に設定され、tuskar サービスに対する http 要求が認証されていない場合には、HTTP 401 Unauthorized のエラーが返されるようになりました。これを確認するには、アンダークラウドから以下のコマンドを実行します。

$ curl -v localhost:8585/v2/plans

一括処理のコードにはノードが実際に選択されていることを確認するプロセスが含まれていませんでした。この操作では、ノードのリストが空でないことを前提としていました。このコードにより、キャッチできない例外が発生し、DEBUG が無効な場合には「どこかがおかしくなりました！」のメッセージが表示されていました。

今回の更新では、少なくとも 1 つのノードが選択されていることを確認するプロセスが追加され、ノードが選択されていない場合にはわかりやすいエラーメッセージが表示されるようになりました。その結果、ノードが 1 つも選択されていない状態で一括処理を試みると、ノードをあらかじめ選択するように指示する、役立つメッセージが表示されます。

一括処理のコードにはノードが実際に選択されていることを確認するプロセスが含まれていませんでした。この操作では、ノードのリストが空でないことを前提としていました。このコードにより、キャッチできない例外が発生し、DEBUG が無効な場合には「どこかがおかしくなりました！」のメッセージが表示されていました。

今回の更新では、少なくとも 1 つのノードが選択されていることを確認するプロセスが追加され、ノードが選択されていない場合にはわかりやすいエラーメッセージが表示されるようになりました。その結果、ノードが 1 つも選択されていない状態で一括処理を試みると、ノードをあらかじめ選択するように指示する、役立つメッセージが表示されます。

ノードの詳細 URL 名が誤って指定され、正しくレンダリングされませんでした。今回の修正により、ノードの詳細 URL 名が正しくなり、ノードの詳細のリンクが適切にレンダリングされるようになったので、ノードの詳細ページにアクセスすることができます。

ノードの詳細 URL 名が誤って指定され、正しくレンダリングされませんでした。今回の修正により、ノードの詳細 URL 名が正しくなり、ノードの詳細のリンクが適切にレンダリングされるようになったので、ノードの詳細ページにアクセスすることができます。

アンダークラウドのインストール中にロールがプランに追加されなかったため、OpenStack Dashboard で編集できませんでした。

今回の更新では、アンダークラウドのインストールが修正され、ロールがプランに追加されるようになったので、Dashboard を使用してロールを編集できます。

アンダークラウドのインストール中にロールがプランに追加されなかったため、OpenStack Dashboard で編集できませんでした。

今回の更新では、アンダークラウドのインストールが修正され、ロールがプランに追加されるようになったので、Dashboard を使用してロールを編集できます。

keystone、heat、ironic、tuskar などの外部の API サービスとの通信が原因で、director のユーザーインターフェースのページ読み込みに長く時間がかかっていました。今回の修正により、全外部サービスの呼び出しにキャッシュが追加されたので、呼び出しの量が削減され、ページの読み込み時間が軽減されました。ユーザーインターフェースにアクセスする際のページの読み込み時間は、大幅に短縮されました。

keystone、heat、ironic、tuskar などの外部の API サービスとの通信が原因で、director のユーザーインターフェースのページ読み込みに長く時間がかかっていました。今回の修正により、全外部サービスの呼び出しにキャッシュが追加されたので、呼び出しの量が削減され、ページの読み込み時間が軽減されました。ユーザーインターフェースにアクセスする際のページの読み込み時間は、大幅に短縮されました。

ユーザーインターフェースは、対応するエンドポイントを作成/初期化する前にオーバークラウドの keystone-api への接続を試みていました。ユーザーインターフェースはエンドポイントを見つけることができず、オーバークラウドをユーザーインターフェースから初期化することはできませんでした。今回の修正により、ユーザーインターフェースは、オーバークラウドが初期化されていない場合には適切に特定できるようになり、エラーは発生しなくなりました。

ユーザーインターフェースは、対応するエンドポイントを作成/初期化する前にオーバークラウドの keystone-api への接続を試みていました。ユーザーインターフェースはエンドポイントを見つけることができず、オーバークラウドをユーザーインターフェースから初期化することはできませんでした。今回の修正により、ユーザーインターフェースは、オーバークラウドが初期化されていない場合には適切に特定できるようになり、エラーは発生しなくなりました。

統合 CLI では、インストール後の検証が実装されていませんでした。これは、非推奨となった OpenStack Deployment (tripleO) のスクリプトのみで実装されていました。そのため、python-rdomanager-oscplugin にコマンドがありませんでした。

今回の更新では、インストール後の検証が実装され、「openstack overcloud validate」コマンドが CLI で利用できるようになりました。

統合 CLI では、インストール後の検証が実装されていませんでした。これは、非推奨となった OpenStack Deployment (tripleO) のスクリプトのみで実装されていました。そのため、python-rdomanager-oscplugin にコマンドがありませんでした。

今回の更新では、インストール後の検証が実装され、「openstack overcloud validate」コマンドが CLI で利用できるようになりました。

統合 CLI には、DRAC の ready-state の設定が実装されていませんでした。これは、非推奨となった OpenStack Deployment (tripleO) のスクリプトのみで実装されていました。そのため、python-rdomanager-oscplugin にコマンドがありませんでした。

今回の更新で、DRAC の ready-state が実装され、「openstack baremetal configure ready state」コマンドが CLI で利用できるようになりました。

統合 CLI には、DRAC の ready-state の設定が実装されていませんでした。これは、非推奨となった OpenStack Deployment (tripleO) のスクリプトのみで実装されていました。そのため、python-rdomanager-oscplugin にコマンドがありませんでした。

今回の更新で、DRAC の ready-state が実装され、「openstack baremetal configure ready state」コマンドが CLI で利用できるようになりました。

今回のリリースでは、デフォルトのオーバークラウドの neutron テナントネットワークの動作を制御する 4 つのパラメーター (--neutron-network-type、--neutron-tunnel-types、--neutron-disable-tunnel$ source overcloudrc ing、--neutron-network-vlan-ranges) が追加されました。デフォルトでは、オーバークラウドのテナントネットワークに GRE タイプとトンネルが指定されます。

-neutron-network-type が「vlan」に指定されている場合には、--neutron-network-vlan-ranges パラメーターも設定することができます。このパラメーターは、オーバークラウドの Neutron テナントネットワークに確保される仮想 LAN ID の範囲を制御します (デフォルトでは「datacenter:1:1000」で、「datacenter」は仮想 LAN を確保する Neutron の物理ネットワークの名前に置き換える必要あり)。ネットワークの種別に「vlan」を専用で指定するには、--neutron-disable-tunneling も指定する必要があります (以下に例を記載)。 

 --neutron-network-type に「gre」または「vxlan」 (あるいはその両方) を指定する場合には、対応する --neutron-tunnel-types も有効にする必要があります (以下に例を記載)。加えて、「gre」または「vxlan」をネットワークの種別に指定する場合には、GRE トンネル ID を制御する --neutron-tunnel-id-ranges と、VXLAN トンネル ID を制御する  --neutron-vni-ranges の関連パラメーターをさらに設定することができます。これらはテナントネットワークで提供されます。

例:
オーバークラウドのテナントネットワークの種別を「vxlan」に指定する場合:
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "vxlan" --neutron-tunnel-types "vxlan"

オーバークラウドのテナントネットワークを「gre」と「vxlan」の両方に指定する場合:
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "gre,vxlan" --neutron-tunnel-types "gre,vxlan"

オーバークラウドのテナントネットワークの種別に「vlan」を指定し、かつ VLAN 範囲も指定する場合:
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "vlan" --neutron-disable-tunneling --neutron-network-vlan-ranges "datacenter:3:3000"

これらのパラメーターがデプロイ時に指定されなかった場合には、デフォルトで以下の値に設定されます。デプロイメントシナリオによっては、限定的または不適切と見なされる場合があります。

--neutron-network-type # default 'gre'
--neutron-tunnel-types # default 'gre'
--neutron-disable-tunneling # defaults to tunneling being enabled
--neutron-network-vlan-ranges # 'datacenter:1:1000'

デプロイ後には、コントローラーノード上の Neutron 設定ログで、以下のように設定されていることを確認できます。これらの値は、上記に示したように、デプロイ中に指定した値に対応するはずです。

grep -rni 'tunnel_types\|network_type\|enable_tunneling\|vlan_ranges' /etc/neutron/*
/etc/neutron/plugin.ini:14:tenant_network_types = vlan
/etc/neutron/plugin.ini:72:network_vlan_ranges =datacenter:3:3000
/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:54:enable_tunneling=False
/etc/neutron/plugins/ml2/ml2_conf.ini:14:tenant_network_types = vlan
/etc/neutron/plugins/ml2/ml2_conf.ini:72:network_vlan_ranges =datacenter:3:3000

また、オーバークラウドの Neutron にネットワークを作成して、それをたとえばアンダークラウド上で確認することができます。

$ source overcloudrc
$ neutron net-create "default"
$ neutron net-show default
...
| provider:network_type     | vlan                                 |
| provider:physical_network | datacenter                           |
| provider:segmentation_id  | 3                                    |
...

今回のリリースでは、デフォルトのオーバークラウドの neutron テナントネットワークの動作を制御する 4 つのパラメーター (--neutron-network-type、--neutron-tunnel-types、--neutron-disable-tunnel$ source overcloudrc ing、--neutron-network-vlan-ranges) が追加されました。デフォルトでは、オーバークラウドのテナントネットワークに GRE タイプとトンネルが指定されます。

-neutron-network-type が「vlan」に指定されている場合には、--neutron-network-vlan-ranges パラメーターも設定することができます。このパラメーターは、オーバークラウドの Neutron テナントネットワークに確保される仮想 LAN ID の範囲を制御します (デフォルトでは「datacenter:1:1000」で、「datacenter」は仮想 LAN を確保する Neutron の物理ネットワークの名前に置き換える必要あり)。ネットワークの種別に「vlan」を専用で指定するには、--neutron-disable-tunneling も指定する必要があります (以下に例を記載)。 

 --neutron-network-type に「gre」または「vxlan」 (あるいはその両方) を指定する場合には、対応する --neutron-tunnel-types も有効にする必要があります (以下に例を記載)。加えて、「gre」または「vxlan」をネットワークの種別に指定する場合には、GRE トンネル ID を制御する --neutron-tunnel-id-ranges と、VXLAN トンネル ID を制御する  --neutron-vni-ranges の関連パラメーターをさらに設定することができます。これらはテナントネットワークで提供されます。

例:
オーバークラウドのテナントネットワークの種別を「vxlan」に指定する場合:
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "vxlan" --neutron-tunnel-types "vxlan"

オーバークラウドのテナントネットワークを「gre」と「vxlan」の両方に指定する場合:
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "gre,vxlan" --neutron-tunnel-types "gre,vxlan"

オーバークラウドのテナントネットワークの種別に「vlan」を指定し、かつ VLAN 範囲も指定する場合:
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "vlan" --neutron-disable-tunneling --neutron-network-vlan-ranges "datacenter:3:3000"

これらのパラメーターがデプロイ時に指定されなかった場合には、デフォルトで以下の値に設定されます。デプロイメントシナリオによっては、限定的または不適切と見なされる場合があります。

--neutron-network-type # default 'gre'
--neutron-tunnel-types # default 'gre'
--neutron-disable-tunneling # defaults to tunneling being enabled
--neutron-network-vlan-ranges # 'datacenter:1:1000'

デプロイ後には、コントローラーノード上の Neutron 設定ログで、以下のように設定されていることを確認できます。これらの値は、上記に示したように、デプロイ中に指定した値に対応するはずです。

grep -rni 'tunnel_types\|network_type\|enable_tunneling\|vlan_ranges' /etc/neutron/*
/etc/neutron/plugin.ini:14:tenant_network_types = vlan
/etc/neutron/plugin.ini:72:network_vlan_ranges =datacenter:3:3000
/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:54:enable_tunneling=False
/etc/neutron/plugins/ml2/ml2_conf.ini:14:tenant_network_types = vlan
/etc/neutron/plugins/ml2/ml2_conf.ini:72:network_vlan_ranges =datacenter:3:3000

また、オーバークラウドの Neutron にネットワークを作成して、それをたとえばアンダークラウド上で確認することができます。

$ source overcloudrc
$ neutron net-create "default"
$ neutron net-show default
...
| provider:network_type     | vlan                                 |
| provider:physical_network | datacenter                           |
| provider:segmentation_id  | 3                                    |
...

統合 CLI は、OpenStack のオーバークラウドのデプロイが完了しなかったと判断して、タイムアウトしていたため、そのデプロイが失敗したというメッセージがユーザーに表示されていました。

今回の更新では、タイムアウトの値が 1 時間に延長され、デプロイメントはタイムアウトする前に終了するようになりました。

統合 CLI は、OpenStack のオーバークラウドのデプロイが完了しなかったと判断して、タイムアウトしていたため、そのデプロイが失敗したというメッセージがユーザーに表示されていました。

今回の更新では、タイムアウトの値が 1 時間に延長され、デプロイメントはタイムアウトする前に終了するようになりました。

今回のリリースでは、デプロイメントのスケーリングに直接 Tuskar を使用する方法と、deploy コマンドを使用する方法が優先され、重複していたコマンドは削除されました。

今回のリリースでは、デプロイメントのスケーリングに直接 Tuskar を使用する方法と、deploy コマンドを使用する方法が優先され、重複していたコマンドは削除されました。

過剰な数のノードが PXE ブートを同時に試みると、KVM PXE コードの問題でエラーが発生し、一部のノードが DHCP への接続で失敗していました。

今回の更新では、スリープの値が増やされ、ノードでのイントロスペクションが可能になりました。その結果、DHCP 接続で問題はなくなり、イントロスペクションがやや長く実行されるようになりました。

過剰な数のノードが PXE ブートを同時に試みると、KVM PXE コードの問題でエラーが発生し、一部のノードが DHCP への接続で失敗していました。

今回の更新では、スリープの値が増やされ、ノードでのイントロスペクションが可能になりました。その結果、DHCP 接続で問題はなくなり、イントロスペクションがやや長く実行されるようになりました。

以前のリリースでは、「openstack overcloud deploy」コマンドの使用時に、コードが一部のコマンドラインパラメーターを使用しなかったため、ユーザーは、それらのパラメーターを設定できませんでした。

今回のリリースでは、パラメーターが使用され、Orchestration Service に送信されるようになりました。

以前のリリースでは、「openstack overcloud deploy」コマンドの使用時に、コードが一部のコマンドラインパラメーターを使用しなかったため、ユーザーは、それらのパラメーターを設定できませんでした。

今回のリリースでは、パラメーターが使用され、Orchestration Service に送信されるようになりました。

「openstack overcloud validate」は、redhat-openstack/tempest のミッドストリームツールを使用する代わりに、アップストリームで文書化されているように OpenStack Integration Test Suite (tempest) を実行していたため、出力形式が異なりました。

今回の更新により、「openstack overcloud validate」はミッドストリームツールを使用して tempest を実行し、想定通りの形式で出力されるようになりました。

「openstack overcloud validate」は、redhat-openstack/tempest のミッドストリームツールを使用する代わりに、アップストリームで文書化されているように OpenStack Integration Test Suite (tempest) を実行していたため、出力形式が異なりました。

今回の更新により、「openstack overcloud validate」はミッドストリームツールを使用して tempest を実行し、想定通りの形式で出力されるようになりました。

CLI では、特定の Neutron パラメーターをカスタマイズする方法がありませんでした。今回の修正で、deploy コマンドに新しい引数が追加されました。ユーザーは、これらの引数を「openstack overcloud deploy」コマンドに使用して、パラメーターを設定することができます。

CLI では、特定の Neutron パラメーターをカスタマイズする方法がありませんでした。今回の修正で、deploy コマンドに新しい引数が追加されました。ユーザーは、これらの引数を「openstack overcloud deploy」コマンドに使用して、パラメーターを設定することができます。

Tuskar API は全パラメーターが文字列であることを想定していましたが、一部のパラメーターは整数値として渡されていたため、API はそれらの値を拒否していました。

今回の更新で、パラメーターはすべて、API に送信される前に文字列に変換されるようになりました。その結果、API は全パラメーターを受け入れ、デプロイメントが正常に機能するようになりました。

Tuskar API は全パラメーターが文字列であることを想定していましたが、一部のパラメーターは整数値として渡されていたため、API はそれらの値を拒否していました。

今回の更新で、パラメーターはすべて、API に送信される前に文字列に変換されるようになりました。その結果、API は全パラメーターを受け入れ、デプロイメントが正常に機能するようになりました。

directorは、/usr/share/openstack-tripleo-heat-templates/ 内の Heat テンプレートコレクションにハードコード化されたパスを使用していました。このため、ローカルコピーの作成やカスタマイズなどでカスタムの Heat テンプレートを使用する際に問題が生じていました。今回の修正により、--template 引数を使用した変数の入力ができるようになりました。ユーザーはカスタマイズされた Heat テンプレートコレクションを使用してオーバークラウドを作成することができます。

directorは、/usr/share/openstack-tripleo-heat-templates/ 内の Heat テンプレートコレクションにハードコード化されたパスを使用していました。このため、ローカルコピーの作成やカスタマイズなどでカスタムの Heat テンプレートを使用する際に問題が生じていました。今回の修正により、--template 引数を使用した変数の入力ができるようになりました。ユーザーはカスタマイズされた Heat テンプレートコレクションを使用してオーバークラウドを作成することができます。

以前のリリースでは、OpenStack オーバークラウドの再デプロイで、必要なパラメーターが Orchestration Service に正しく渡されていなかったため、UPGRADE_FAILED のメッセージが表示されていました。

今回の更新により、パラメーター「Existing=True」が Orchestration の更新パラメーターに追加され、オーバークラウドのデプロイメントを正常に実行できるようになりました。

以前のリリースでは、OpenStack オーバークラウドの再デプロイで、必要なパラメーターが Orchestration Service に正しく渡されていなかったため、UPGRADE_FAILED のメッセージが表示されていました。

今回の更新により、パラメーター「Existing=True」が Orchestration の更新パラメーターに追加され、オーバークラウドのデプロイメントを正常に実行できるようになりました。

デプロイメント中に、Ironic のログにはノードが利用可能と示されているにもかからわらず、有効なホストが見つからなかったため、Heat のエンジンログがゼロ以外のエラーを返していました。これは、「openstack baremetal introspection」コマンドの完了時に、director がノードを「available」に設定しなかったことが原因でした。今回の修正で、introspection の完了時にはノードが「available」に設定されるようになり、director はオーバークラウドのデプロイ時にノードを確認できるようになりました。

デプロイメント中に、Ironic のログにはノードが利用可能と示されているにもかからわらず、有効なホストが見つからなかったため、Heat のエンジンログがゼロ以外のエラーを返していました。これは、「openstack baremetal introspection」コマンドの完了時に、director がノードを「available」に設定しなかったことが原因でした。今回の修正で、introspection の完了時にはノードが「available」に設定されるようになり、director はオーバークラウドのデプロイ時にノードを確認できるようになりました。

director は、データベースに保管されているプランに加えて、Heat テンプレートコレクションを使用してオーバークラウドを作成できるようになりました。これにより、「openstack overcloud stack update」コマンドを実行してオーバークラウド上のパッケージを更新する際に、Heat テンプレートを直接使用する方法が提供されます。プランではなくテンプレートコレクションを使用してオーバークラウドを作成した場合には、「openstack overcloud stack update」コマンドを実行する際に「--plan」パラメーターではなく、「--templates」パラメーターを使用してください。

director は、データベースに保管されているプランに加えて、Heat テンプレートコレクションを使用してオーバークラウドを作成できるようになりました。これにより、「openstack overcloud stack update」コマンドを実行してオーバークラウド上のパッケージを更新する際に、Heat テンプレートを直接使用する方法が提供されます。プランではなくテンプレートコレクションを使用してオーバークラウドを作成した場合には、「openstack overcloud stack update」コマンドを実行する際に「--plan」パラメーターではなく、「--templates」パラメーターを使用してください。

director は、オーバークラウドノードでパッケージを更新する際に、追加の Heat 環境ファイルを受け入れるパラメーターを提供するようになりました。オーバークラウドの分離されたネットワークには、作成時およびその後の更新時に追加の環境ファイルが必要です。このファイルがない場合には、ユーザーは分離されたネットワークを使用するオーバークラウドでは「openstack overcloud update stack」のコマンドは使用できません。ユーザーは、「openstack overcloud update stack」コマンドに「-e」パラメーターを使用して、分離されたネットワークを使用するオーバークラウドノードでパッケージの更新を行うことができるようになりました。

director は、オーバークラウドノードでパッケージを更新する際に、追加の Heat 環境ファイルを受け入れるパラメーターを提供するようになりました。オーバークラウドの分離されたネットワークには、作成時およびその後の更新時に追加の環境ファイルが必要です。このファイルがない場合には、ユーザーは分離されたネットワークを使用するオーバークラウドでは「openstack overcloud update stack」のコマンドは使用できません。ユーザーは、「openstack overcloud update stack」コマンドに「-e」パラメーターを使用して、分離されたネットワークを使用するオーバークラウドノードでパッケージの更新を行うことができるようになりました。

今回のリリースでは、オーバークラウドノードの削除時に、Heat テンプレートを直接使用することができるようになりました。Tuskar を使用せずにデプロイされたオーバークラウドの場合には、「openstack overcloud node delete」コマンドに「--templates」パラメーターを使用できます。

今回のリリースでは、オーバークラウドノードの削除時に、Heat テンプレートを直接使用することができるようになりました。Tuskar を使用せずにデプロイされたオーバークラウドの場合には、「openstack overcloud node delete」コマンドに「--templates」パラメーターを使用できます。

今回のリリースでは、オーバークラウドからノードを削除する際に追加の Heat 環境ファイルを受け入れる新機能が実装されました。分離されたネットワークを使用している場合には、オーバークラウドの更新時に追加の環境ファイルを Heat に渡す必要があります。今回の更新により、「openstack overcloud node delete」コマンドを使用して、分離されたネットワーク上のオーバークラウドノードを削除できるようになりました。

今回のリリースでは、オーバークラウドからノードを削除する際に追加の Heat 環境ファイルを受け入れる新機能が実装されました。分離されたネットワークを使用している場合には、オーバークラウドの更新時に追加の環境ファイルを Heat に渡す必要があります。今回の更新により、「openstack overcloud node delete」コマンドを使用して、分離されたネットワーク上のオーバークラウドノードを削除できるようになりました。

deploy コマンドの一部の引数と同じ機能を提供する別の引数が存在していました。今回の修正で、重複していた引数 (--plan-uuid、--use-tripleo-heat-templates、--extra-template) は削除されました。

deploy コマンドの一部の引数と同じ機能を提供する別の引数が存在していました。今回の修正で、重複していた引数 (--plan-uuid、--use-tripleo-heat-templates、--extra-template) は削除されました。

タイムアウトを設定できなかったため、デプロイメントは、1 時間後に必ずタイムアウトしていました。今回の修正により、タイムアウトの引数が追加され、ユーザーはカスタムのタイムアウトを設定できるようになりました。デフォルト値は 4 時間です。

タイムアウトを設定できなかったため、デプロイメントは、1 時間後に必ずタイムアウトしていました。今回の修正により、タイムアウトの引数が追加され、ユーザーはカスタムのタイムアウトを設定できるようになりました。デフォルト値は 4 時間です。

Heat テンプレートには、Neutron L3 エージェントを設定する特定のパラメーターがなかったため、director は L3 エージェントを適切に設定できませんでした。今回の修正により、この Heat パラメーターがテンプレートに追加され、director は L3 エージェントを適切に設定できるようになりました。

Heat テンプレートには、Neutron L3 エージェントを設定する特定のパラメーターがなかったため、director は L3 エージェントを適切に設定できませんでした。今回の修正により、この Heat パラメーターがテンプレートに追加され、director は L3 エージェントを適切に設定できるようになりました。

キャストのバグが原因で、単一のコントローラーの構成でデプロイする際に、オーバークラウドの Neutron 設定に「L3HA」は「True」として渡されていました。ネイティブ L3 HA が確実に機能するには、Neutron に最小 2 つの L3 エージェントが必要なため、デプロイは成功しても、オーバークラウドのテナントネットワークの設定時にエラーが出ていました。そのため、デプロイの成功後に Neutron のテナントネットワークまたはルーターを作成する際には、Neutron から以下のようなエラーが返されていました。

    Not enough l3 agents available to ensure HA. Minimum required 2, available 1.

このバグは、L3 HA の有効化を確認する前にコントローラーの数を整数にキャストすることで修正されました。その結果、単一のコントローラーを使用するデプロイの場合には /etc/neutron/neutron.conf ファイルで「L3HA」が「False」に設定されるようになりました。複数のコントローラーを使用するデプロイの場合は、この値は「true」に設定されます。

キャストのバグが原因で、単一のコントローラーの構成でデプロイする際に、オーバークラウドの Neutron 設定に「L3HA」は「True」として渡されていました。ネイティブ L3 HA が確実に機能するには、Neutron に最小 2 つの L3 エージェントが必要なため、デプロイは成功しても、オーバークラウドのテナントネットワークの設定時にエラーが出ていました。そのため、デプロイの成功後に Neutron のテナントネットワークまたはルーターを作成する際には、Neutron から以下のようなエラーが返されていました。

    Not enough l3 agents available to ensure HA. Minimum required 2, available 1.

このバグは、L3 HA の有効化を確認する前にコントローラーの数を整数にキャストすることで修正されました。その結果、単一のコントローラーを使用するデプロイの場合には /etc/neutron/neutron.conf ファイルで「L3HA」が「False」に設定されるようになりました。複数のコントローラーを使用するデプロイの場合は、この値は「true」に設定されます。

python-tuskarclient は、Tuskar API サーバーから SSL 証明書を検証するためのカスタムの CA 証明書の指定はサポートしていませんでした。サーバーがクライアントにとって未知の CA によって署名された証明書を使用すると接続が失敗していました。今回の修正により、python-tuskarclient に「--os-cacert」オプションが追加され、CA 証明書のパスを指定できるようになりました。これにより、API サーバーとの通信を正常に実行できるようになりました。

python-tuskarclient は、Tuskar API サーバーから SSL 証明書を検証するためのカスタムの CA 証明書の指定はサポートしていませんでした。サーバーがクライアントにとって未知の CA によって署名された証明書を使用すると接続が失敗していました。今回の修正により、python-tuskarclient に「--os-cacert」オプションが追加され、CA 証明書のパスを指定できるようになりました。これにより、API サーバーとの通信を正常に実行できるようになりました。

オーバークラウドでは、/etc/glance/glance-api.conf ファイルの glance_store セクションが stores=glance.store.filesystem.Store に設定されていたため、ストアの種別の違いが原因でイメージのアップロードで問題が発生していました。今回の修正では、glance の設定ファイルが変更され、ストアのパラメーターに glance.store.http.Store が設定され、使用するストアの種別のバックエンドが含まれるようになりました。

オーバークラウドでは、/etc/glance/glance-api.conf ファイルの glance_store セクションが stores=glance.store.filesystem.Store に設定されていたため、ストアの種別の違いが原因でイメージのアップロードで問題が発生していました。今回の修正では、glance の設定ファイルが変更され、ストアのパラメーターに glance.store.http.Store が設定され、使用するストアの種別のバックエンドが含まれるようになりました。

設定ファイルの DHCP オプションの順序が誤っていたため、ブート時にマシンでエラーが発生していました。今回の修正により、DHCP オプションにタグが使用されるようになり、順序が正しくなりました。マシンは iPXE ROM を使用してブートをチェーンロードしてから、HTTP URL を起動してブートを継続します。その結果、ブートが正常に実行されるようになりました。

設定ファイルの DHCP オプションの順序が誤っていたため、ブート時にマシンでエラーが発生していました。今回の修正により、DHCP オプションにタグが使用されるようになり、順序が正しくなりました。マシンは iPXE ROM を使用してブートをチェーンロードしてから、HTTP URL を起動してブートを継続します。その結果、ブートが正常に実行されるようになりました。

grub の設定によりカーネルのパラメーターは、存在しない可能性のシリアルポートにコンソールをリダイレクトするよう設定されていたため、ノードの起動が失敗していました。今回の修正により、デフォルトではシリアルポートへのコンソールのリダイレクトが無効に設定され、ノードは正常に起動するようになりました。

grub の設定によりカーネルのパラメーターは、存在しない可能性のシリアルポートにコンソールをリダイレクトするよう設定されていたため、ノードの起動が失敗していました。今回の修正により、デフォルトではシリアルポートへのコンソールのリダイレクトが無効に設定され、ノードは正常に起動するようになりました。

アップストリームの Nova はデフォルトで「novalocal」をホスト名に追記していました。これは、Red Hat のツーリングで問題が発生する原因となっていました。追記された nova のホスト名は、puppet が想定する名前に対応しないため、オーバークラウドの作成中に Heat 内の ControllerNodesPostDeployment で CREATE_FAILED と報告されていました。今回の修正により、アップストリームのデフォルトが上書きされ、「novalocal」のサフィックスが設定されないようになったため、デプロイ後の puppet の設定で、オーバークラウドの Heat スタック上で CREATE_COMPLETE と報告されるようになりました。

アップストリームの Nova はデフォルトで「novalocal」をホスト名に追記していました。これは、Red Hat のツーリングで問題が発生する原因となっていました。追記された nova のホスト名は、puppet が想定する名前に対応しないため、オーバークラウドの作成中に Heat 内の ControllerNodesPostDeployment で CREATE_FAILED と報告されていました。今回の修正により、アップストリームのデフォルトが上書きされ、「novalocal」のサフィックスが設定されないようになったため、デプロイ後の puppet の設定で、オーバークラウドの Heat スタック上で CREATE_COMPLETE と報告されるようになりました。

テクノロジープレビューで instack.answers に設定できなかったアンダークラウドの deployment_mode 設定が削除されました。deployment_mode により、個別のロールを特定のノードにデプロイする「scale」モードの選択が可能でした。この機能は、Automated Health Check (AHC) ツールのノードタグ付機能の部分に置き換えられました。

テクノロジープレビューで instack.answers に設定できなかったアンダークラウドの deployment_mode 設定が削除されました。deployment_mode により、個別のロールを特定のノードにデプロイする「scale」モードの選択が可能でした。この機能は、Automated Health Check (AHC) ツールのノードタグ付機能の部分に置き換えられました。

director は、個別のサブネットおよび仮想 LAN 上で異るネットワークサービスを分離する方法を提供します。その手順は、『Red Hat Enterprise Linux OpenStack Platform 7.0 director のインストールと使用方法』のオーバークラウドの基本的および高度なシナリオのセクションに記載されています。

director は、個別のサブネットおよび仮想 LAN 上で異るネットワークサービスを分離する方法を提供します。その手順は、『Red Hat Enterprise Linux OpenStack Platform 7.0 director のインストールと使用方法』のオーバークラウドの基本的および高度なシナリオのセクションに記載されています。

DHCP と静的ルートを混在させると、ルートテーブルにそれらの両方が表示されます。ただし、DHCP ルートのメトリックは 100 で、代わりにメトリックが 0 の静的ルートが常に使用されていました。DHCP サーバーによって提供されるデフォルトルートを無視するように、1 つまたは複数の DHCP リンクを設定すると、この問題を回避して複数の DHCP リンクを使用することができます。そのためには、「defroute: false」宣言を使用してください。

DHCP と静的ルートを混在させると、ルートテーブルにそれらの両方が表示されます。ただし、DHCP ルートのメトリックは 100 で、代わりにメトリックが 0 の静的ルートが常に使用されていました。DHCP サーバーによって提供されるデフォルトルートを無視するように、1 つまたは複数の DHCP リンクを設定すると、この問題を回避して複数の DHCP リンクを使用することができます。そのためには、「defroute: false」宣言を使用してください。

以前のリリースでは、OpenStack Integration Test Suite (tempest) でデプロイメント固有の値が提供されず、一部の tempest テストが失敗していました。

今回の更新により、「openstack overcloud validate」コマンドに「--deployer-input」フラグが追加され、デプロイメント固有の値が含まれているファイル (tempest.conf) を管理者が指定できるようになりました。「--deployer-input filename」フラグを使用することにより、失敗するテストの数が削減されます。

以前のリリースでは、OpenStack Integration Test Suite (tempest) でデプロイメント固有の値が提供されず、一部の tempest テストが失敗していました。

今回の更新により、「openstack overcloud validate」コマンドに「--deployer-input」フラグが追加され、デプロイメント固有の値が含まれているファイル (tempest.conf) を管理者が指定できるようになりました。「--deployer-input filename」フラグを使用することにより、失敗するテストの数が削減されます。

Redis は別の仮想 IP アドレスを使用する必要があります。ネットワークの分離を使用してデプロイする場合、director がデフォルトで内部 API の仮想 IP アドレスに Redis の仮想 IP アドレスを自動的に配置します。オペレーターは ServiceNetMap パラメーターを使用して Redis を他のネットワークに移行することができます。

Redis は別の仮想 IP アドレスを使用する必要があります。ネットワークの分離を使用してデプロイする場合、director がデフォルトで内部 API の仮想 IP アドレスに Redis の仮想 IP アドレスを自動的に配置します。オペレーターは ServiceNetMap パラメーターを使用して Redis を他のネットワークに移行することができます。

director は以前、ネットワークと Floating IP のオプションがあるファイルをデプロイメントに使用していましたが、これらのネットワークオプションは初期バージョンの director では無視されていました。今回の修正により、このファイルは「openstack overcloud director」のコマンドライン引数のセットに置き換えられ、オーバークラウドでネットワークと Floating IP を設定するために必要なオプションが CLI ツールに含まれるようになりました。

director は以前、ネットワークと Floating IP のオプションがあるファイルをデプロイメントに使用していましたが、これらのネットワークオプションは初期バージョンの director では無視されていました。今回の修正により、このファイルは「openstack overcloud director」のコマンドライン引数のセットに置き換えられ、オーバークラウドでネットワークと Floating IP を設定するために必要なオプションが CLI ツールに含まれるようになりました。

以前のリリースでは、「management_plan.uuid」の変数名が誤っていたため、属性のエラーが生じて、Tuskar プランの全デプロイメントが失敗していました。今回の更新では、この変数名が修正されました。

以前のリリースでは、「management_plan.uuid」の変数名が誤っていたため、属性のエラーが生じて、Tuskar プランの全デプロイメントが失敗していました。今回の更新では、この変数名が修正されました。

オーバークラウドのデプロイ時には、director がパブリックの仮想 IP アドレスのサービスをプロビジョニングネットワークの「ctlplane」に配置していたため、オーバークラウドの外部からはこれらのサービスに到達できませんでした。今回の修正により、Heat テンプレートにパッチが適用され、パブリックの仮想 IP アドレスは外部ネットワークに配置されるようになりました。

オーバークラウドのデプロイ時には、director がパブリックの仮想 IP アドレスのサービスをプロビジョニングネットワークの「ctlplane」に配置していたため、オーバークラウドの外部からはこれらのサービスに到達できませんでした。今回の修正により、Heat テンプレートにパッチが適用され、パブリックの仮想 IP アドレスは外部ネットワークに配置されるようになりました。

オーバークラウドのデプロイ時には、director がパブリックの仮想 IP サービスをプロビジョニングネットワークの「ctlplane」に配置していたため、オーバークラウドの外部からは Horizon および Keystone のサービスに到達できませんでした。今回の修正により、Heat テンプレートにパッチが適用され、パブリックの仮想 IP アドレスは外部ネットワークに配置されるようになりました。

オーバークラウドのデプロイ時には、director がパブリックの仮想 IP サービスをプロビジョニングネットワークの「ctlplane」に配置していたため、オーバークラウドの外部からは Horizon および Keystone のサービスに到達できませんでした。今回の修正により、Heat テンプレートにパッチが適用され、パブリックの仮想 IP アドレスは外部ネットワークに配置されるようになりました。

以前のバージョンでは、ironic-discoverd がノード上ですでに設定済みのブートデバイスと同じデバイスを使用して「set_boot_device」要求を送信すると、OpenStack Bare Metal Provisioning (ironic) の DRAC ドライバーが BIOS に対して設定ジョブのコミットを変更なしで試みていたため、デプロイメントが失敗してしまいました。

今回の更新により、OpenStack Bare Metal Provisioning の DRAC ドライバーは、ターゲットのブートデバイスが現在のブートデバイスと同じ場合には、要求を無視するようになり、デプロイメントは失敗しなくなりました。

以前のバージョンでは、ironic-discoverd がノード上ですでに設定済みのブートデバイスと同じデバイスを使用して「set_boot_device」要求を送信すると、OpenStack Bare Metal Provisioning (ironic) の DRAC ドライバーが BIOS に対して設定ジョブのコミットを変更なしで試みていたため、デプロイメントが失敗してしまいました。

今回の更新により、OpenStack Bare Metal Provisioning の DRAC ドライバーは、ターゲットのブートデバイスが現在のブートデバイスと同じ場合には、要求を無視するようになり、デプロイメントは失敗しなくなりました。

以前のバージョンでは、Orchestration がオーバークラウドのデプロイを行っている間に、keystone のトークンの有効期限が切れてしまっていたため、認証エラーが発生して操作が失敗していました。

今回のリリースでは、トークンのタイムアウトが延長されたので、オーバークラウドのデプロイが正常にできるようになりました。

以前のバージョンでは、Orchestration がオーバークラウドのデプロイを行っている間に、keystone のトークンの有効期限が切れてしまっていたため、認証エラーが発生して操作が失敗していました。

今回のリリースでは、トークンのタイムアウトが延長されたので、オーバークラウドのデプロイが正常にできるようになりました。

デフォルトのルートは外部ネットワークに設定されていなかったため、Horizon とパブリックの API にはコントローラーと同じサブネットからしかアクセスできませんでした。今回の修正により Heat のテンプレートが更新され、ExternalInterfaceDefaultRoute パラメーターが含まれるようになったので、外部インターフェースでデフォルトのルートが利用できるようになりました。

デフォルトのルートは外部ネットワークに設定されていなかったため、Horizon とパブリックの API にはコントローラーと同じサブネットからしかアクセスできませんでした。今回の修正により Heat のテンプレートが更新され、ExternalInterfaceDefaultRoute パラメーターが含まれるようになったので、外部インターフェースでデフォルトのルートが利用できるようになりました。

NeutronScale のリソースにより、コントローラーノード上の neutron エージェントの名前が変更されていました。これにより、「neutron agent-list」と一致しなくなり、Neutron は L3 HA の L3 エージェントが不足しているというエラーを報告していました。今回の修正により、オーバークラウドの Heat テンプレートとプランから NeutronScale リソースが削除され、「neutron agent-list」に表示されなくなったため、Neutron はエラーを報告しなくなりました。

NeutronScale のリソースにより、コントローラーノード上の neutron エージェントの名前が変更されていました。これにより、「neutron agent-list」と一致しなくなり、Neutron は L3 HA の L3 エージェントが不足しているというエラーを報告していました。今回の修正により、オーバークラウドの Heat テンプレートとプランから NeutronScale リソースが削除され、「neutron agent-list」に表示されなくなったため、Neutron はエラーを報告しなくなりました。

以前のリリースでは、アンダークラウドの管理ユーザーにはサービステナントで「swiftoperator」のロールが割り当てられていなかったため、管理ユーザーを使用する CloudForms Management Engine (CFME) は swift のオブジェクトにアクセスできませんでした。

今回の更新により、サービステナント上でアンダークラウドの管理ユーザーに「swiftoperator」ロールが割り当てられたため、管理ユーザーは、API 要求でサービステナントを指定すると swift オブジェクトにアクセスできるようになりました。

以前のリリースでは、アンダークラウドの管理ユーザーにはサービステナントで「swiftoperator」のロールが割り当てられていなかったため、管理ユーザーを使用する CloudForms Management Engine (CFME) は swift のオブジェクトにアクセスできませんでした。

今回の更新により、サービステナント上でアンダークラウドの管理ユーザーに「swiftoperator」ロールが割り当てられたため、管理ユーザーは、API 要求でサービステナントを指定すると swift オブジェクトにアクセスできるようになりました。

NeutronScale のリソースにより、コントローラーノード上の neutron エージェントの名前が変更されていました。これにより、「neutron agent-list」と一致しなくなり、Neutron は L3 HA の L3 エージェントが不足しているというエラーを報告していました。今回の修正により、オーバークラウドの Heat テンプレートとプランから NeutronScale リソースが削除され、「neutron agent-list」に表示されなくなったため、Neutron はエラーを報告しなくなりました。

NeutronScale のリソースにより、コントローラーノード上の neutron エージェントの名前が変更されていました。これにより、「neutron agent-list」と一致しなくなり、Neutron は L3 HA の L3 エージェントが不足しているというエラーを報告していました。今回の修正により、オーバークラウドの Heat テンプレートとプランから NeutronScale リソースが削除され、「neutron agent-list」に表示されなくなったため、Neutron はエラーを報告しなくなりました。

今回のリリースでは、新な機能拡張により Block Storage Service に NFS バックエンドが追加され、利用可能な Block Storage バックエンドの種別が多くなりました。

その結果、以下のパラメーターを使用してオーバークラウドの Block Storage Service を NFS バックエンドに設定できるようになりました。

CinderEnableNfsBackend
CinderNfsMountOptions
CinderNfsServers

今回のリリースでは、新な機能拡張により Block Storage Service に NFS バックエンドが追加され、利用可能な Block Storage バックエンドの種別が多くなりました。

その結果、以下のパラメーターを使用してオーバークラウドの Block Storage Service を NFS バックエンドに設定できるようになりました。

CinderEnableNfsBackend
CinderNfsMountOptions
CinderNfsServers

glance バックエンドは swift を使用するようにハードコードされていたため、glance には NFS などのファイルシステムタイプを使用することができませんでした。今回のリリースでは、新たに機能が拡張され、glance に NFS バックエンドを使用できるようになりました。以下のパラメーターを使用して、オーバークラウドの glance サービスを NFS バックエンドに設定することができるようになりました。

GlanceBackend
GlanceFilePcmkManage
GlanceFilePcmkDevice
GlanceFilePcmkOptions

glance バックエンドは swift を使用するようにハードコードされていたため、glance には NFS などのファイルシステムタイプを使用することができませんでした。今回のリリースでは、新たに機能が拡張され、glance に NFS バックエンドを使用できるようになりました。以下のパラメーターを使用して、オーバークラウドの glance サービスを NFS バックエンドに設定することができるようになりました。

GlanceBackend
GlanceFilePcmkManage
GlanceFilePcmkDevice
GlanceFilePcmkOptions

OpenStack Dashboard (Horizon) は高可用性アーキテクチャーの一部となりました。Dashboard は、Pacemaker によって管理されるリソースの 1 つとなりました。

OpenStack Dashboard (Horizon) は高可用性アーキテクチャーの一部となりました。Dashboard は、Pacemaker によって管理されるリソースの 1 つとなりました。

Pacemaker と ironic は、電源管理の制御で競合していたため、フェンシングで問題が発生していました。今回の修正により、/etc/ironic/ironic.conf の force_power_state_during_sync=False がデフォルトで設定されるようになったため、ironic が同期中にノードの電源状態を自動的に復元しないようになり、Pacemaker はノードのフェンシングを正常に実行できるようになりました。

Pacemaker と ironic は、電源管理の制御で競合していたため、フェンシングで問題が発生していました。今回の修正により、/etc/ironic/ironic.conf の force_power_state_during_sync=False がデフォルトで設定されるようになったため、ironic が同期中にノードの電源状態を自動的に復元しないようになり、Pacemaker はノードのフェンシングを正常に実行できるようになりました。

NeutronExternalNetworkBridge を設定するための CLI パラメーターがなかったため、Floating IP の割り当て時に問題が発生していました。このパラメーターを設定する唯一の方法は、ネットワーク分離用のカスタムの環境ファイルを使用することです。以下に例を示します。

parameter_defaults:
  # Set to "br-ex" if External is on native VLAN
  NeutronExternalNetworkBridge: "''"

Floating IP ネットワークが仮想 LAN 上にある場合には、このパラメーターを「''」に設定し、また br-ex ブリッジ上のネイティブ仮想 LAN 上にある場合には「br-ex」に設定します。この設定により、Neutron のブリッジマッピングが環境で正しく機能できるようになります。この設定ついては、『Red Hat Enterprise Linux OpenStack Platform 7 Director インストールと使用方法』に記載しています。

NeutronExternalNetworkBridge を設定するための CLI パラメーターがなかったため、Floating IP の割り当て時に問題が発生していました。このパラメーターを設定する唯一の方法は、ネットワーク分離用のカスタムの環境ファイルを使用することです。以下に例を示します。

parameter_defaults:
  # Set to "br-ex" if External is on native VLAN
  NeutronExternalNetworkBridge: "''"

Floating IP ネットワークが仮想 LAN 上にある場合には、このパラメーターを「''」に設定し、また br-ex ブリッジ上のネイティブ仮想 LAN 上にある場合には「br-ex」に設定します。この設定により、Neutron のブリッジマッピングが環境で正しく機能できるようになります。この設定ついては、『Red Hat Enterprise Linux OpenStack Platform 7 Director インストールと使用方法』に記載しています。

以前のリリースでは、デフォルトの Red Hat Enterprise Linux リポジトリーでは ipxe-bootimgs パッケージが利用できず、Red Hat Enterprise Linux - Optional リポジトリーでのみ提供されていたため、Optional チャンネルを有効にしていない場合にはデプロイメントが失敗していました。今回の修正により、このパッケージは director のチャンネルに追加され、デプロイメントは Optional チャンネルが有効化されていなくても正常に実行できるようになりました。

以前のリリースでは、デフォルトの Red Hat Enterprise Linux リポジトリーでは ipxe-bootimgs パッケージが利用できず、Red Hat Enterprise Linux - Optional リポジトリーでのみ提供されていたため、Optional チャンネルを有効にしていない場合にはデプロイメントが失敗していました。今回の修正により、このパッケージは director のチャンネルに追加され、デプロイメントは Optional チャンネルが有効化されていなくても正常に実行できるようになりました。

NeutronScale のリソースにより、コントローラーノード上の neutron エージェントの名前が変更されていました。これにより、「neutron agent-list」と一致しなくなり、Neutron は L3 HA の L3 エージェントが不足しているというエラーを報告していました。今回の修正により、オーバークラウドの Heat テンプレートとプランから NeutronScale リソースが削除され、「neutron agent-list」に表示されなくなったため、Neutron はエラーを報告しなくなりました。

NeutronScale のリソースにより、コントローラーノード上の neutron エージェントの名前が変更されていました。これにより、「neutron agent-list」と一致しなくなり、Neutron は L3 HA の L3 エージェントが不足しているというエラーを報告していました。今回の修正により、オーバークラウドの Heat テンプレートとプランから NeutronScale リソースが削除され、「neutron agent-list」に表示されなくなったため、Neutron はエラーを報告しなくなりました。

オーバークラウドが Heat コンポーネントを正しく設定していなかったため、heat_stack_user_role、stack_domain_admin、および stack_domain_admin_password の設定が含まれていませんでした。今回の修正により、/etc/heat/heat.conf でユーザーと管理者のロールが正しく設定されるようになりました。

オーバークラウドが Heat コンポーネントを正しく設定していなかったため、heat_stack_user_role、stack_domain_admin、および stack_domain_admin_password の設定が含まれていませんでした。今回の修正により、/etc/heat/heat.conf でユーザーと管理者のロールが正しく設定されるようになりました。

オーバークラウドをデプロイすると、Heat CloudFormation API が auth_url pointing at localhost をポイントする auth_url を使用するように設定されていましたが、Keystone は localhost をリッスンしていなかったため、Heat CloudFormation API は使用できませんでした。今回の修正により、/etc/heat/heat.conf の auth_url オプションは、内部 API ネットワーク上で Keystone がリッスンしている IP アドレスに変更され、Heat CloudFormation API が正常に機能するようになりました。

オーバークラウドをデプロイすると、Heat CloudFormation API が auth_url pointing at localhost をポイントする auth_url を使用するように設定されていましたが、Keystone は localhost をリッスンしていなかったため、Heat CloudFormation API は使用できませんでした。今回の修正により、/etc/heat/heat.conf の auth_url オプションは、内部 API ネットワーク上で Keystone がリッスンしている IP アドレスに変更され、Heat CloudFormation API が正常に機能するようになりました。

オーバークラウドの Heat サービスの設定が instance_user=heat-admin となっていたため、Heat でプロビジョニングした仮想マシンに SSH 接続するには、heat-admin ユーザーである必要がありました。今回の修正により、instance_user に空の値が設定されるようになり、デフォルトのイメージユーザーを使用してゲスト仮想マシンに SSH 接続できるようになりました。

オーバークラウドの Heat サービスの設定が instance_user=heat-admin となっていたため、Heat でプロビジョニングした仮想マシンに SSH 接続するには、heat-admin ユーザーである必要がありました。今回の修正により、instance_user に空の値が設定されるようになり、デフォルトのイメージユーザーを使用してゲスト仮想マシンに SSH 接続できるようになりました。

Dashboard への接続数は、コントローラーの数と、各コントローラーのコア数によってスケーリングされていました。3 つのコントローラーを使用する HA シナリオで、各コントローラーに 12 コア以上ある場合には、データベース接続は、1024 に設定されているデフォルトの max_connections 値に達する可能性があり、サービスが要求に応答できなくなる原因となっていました。この問題を回避するには、以下のコマンドを使用して max_connections の上限を増やします。

$ openstack management plan set [tuskar_plan_uuid] -P "Controller-1::MysqlMaxConnections=4096"

[tuskar_plan_uuid] は、実際のプラン UUID に置き換えます。以下のコマンドで確認することができます。

$ openstack management plan list

--templates の引数を使用してデプロイする際に max_connections の値を増やすには、以下の設定を記載した追加のカスタム環境ファイルを deploy コマンドで指定します。

parameters:
  MysqlMaxConnections: 4096

deploy コマンドで以下のようにファイルを指定します。

$ openstack management deploy --plan overcloud -e /path/to/custom_environment_file.yaml

Dashboard への接続数は、コントローラーの数と、各コントローラーのコア数によってスケーリングされていました。3 つのコントローラーを使用する HA シナリオで、各コントローラーに 12 コア以上ある場合には、データベース接続は、1024 に設定されているデフォルトの max_connections 値に達する可能性があり、サービスが要求に応答できなくなる原因となっていました。この問題を回避するには、以下のコマンドを使用して max_connections の上限を増やします。

$ openstack management plan set [tuskar_plan_uuid] -P "Controller-1::MysqlMaxConnections=4096"

[tuskar_plan_uuid] は、実際のプラン UUID に置き換えます。以下のコマンドで確認することができます。

$ openstack management plan list

--templates の引数を使用してデプロイする際に max_connections の値を増やすには、以下の設定を記載した追加のカスタム環境ファイルを deploy コマンドで指定します。

parameters:
  MysqlMaxConnections: 4096

deploy コマンドで以下のようにファイルを指定します。

$ openstack management deploy --plan overcloud -e /path/to/custom_environment_file.yaml

NTP サーバーにアクセスできなかったため、ノードが同期されなくなる場合がありました。これは、全ノードが必要なサーバー (NTP、DNS など) にアクセスするようにルーティングされていなかったのが原因でした。今回の修正により、アンダークラウドがコントローラー以外のノードのゲートウェイとして設定され、コントローラー以外のノードに DNS や NTP などの外部サービスへのアクセスが提供され、同期できるようになりました。

NTP サーバーにアクセスできなかったため、ノードが同期されなくなる場合がありました。これは、全ノードが必要なサーバー (NTP、DNS など) にアクセスするようにルーティングされていなかったのが原因でした。今回の修正により、アンダークラウドがコントローラー以外のノードのゲートウェイとして設定され、コントローラー以外のノードに DNS や NTP などの外部サービスへのアクセスが提供され、同期できるようになりました。

Ceph OSD ノードで SELinux が Enforcing モードに設定されていましたが、正式な Ceph のマニュアルでは、Ceph OSD では SELinux を permissive モードに設定することが推奨されています。今回の修正により、Ceph OSD ノードでは、SELinux が permissive に設定されるようになりました。

Ceph OSD ノードで SELinux が Enforcing モードに設定されていましたが、正式な Ceph のマニュアルでは、Ceph OSD では SELinux を permissive モードに設定することが推奨されています。今回の修正により、Ceph OSD ノードでは、SELinux が permissive に設定されるようになりました。

Pacemaker サービスの起動のタイムアウトは 20 秒でした。場合によっては、起動時間がこの上限を超える場合があり、デプロイがハングしてしまいました。今回の修正により、タイムアウトは 60 秒に延長されたため、Pacemaker サービスが正しく起動してデプロイメントが完了するようになりました。

Pacemaker サービスの起動のタイムアウトは 20 秒でした。場合によっては、起動時間がこの上限を超える場合があり、デプロイがハングしてしまいました。今回の修正により、タイムアウトは 60 秒に延長されたため、Pacemaker サービスが正しく起動してデプロイメントが完了するようになりました。