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) のオーバークラウドデプロイメントのみをサポートしています。