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

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

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

Keystone のトークンをフラッシュする cron ジョブが設定されません。これは、Keystone のトークンがデータベースを無制限に生成し、データを投入することを意味します。回避策として、コントローラーホストに Keystone のトークンを消去する cron ジョブを追加すると、Keystone のトークンが定期的にフラッシュされるようになります。

openstack-cinder-volume が LVM バックエンドの使用時にオーバークラウドノードが再起動すると、ファイルベースのループバックデバイスは再度作成されません。回避策として、ループバックデバイスを手動で再作成します。

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

次に、openstack-cinder-volume を再起動します。openstack-cinder-volume はオーバークラウドコントローラーノードの高可用性クラスター内では、一回に 1 つのノードでしか実行できません。ただし、ループバックデバイスは、全ノード上に存在します。

stack-delete の操作は、初回に失敗する場合があります。このコマンドを再度実行すると、削除されない分離ネットワークもあります。これにより、次のデプロイメントが失敗しますが、スタックを削除した後には、デプロイメントは成功します。回避策として、初回のデプロイメントの前に、アンダークラウド上に存在するのが「ctlplane」ネットワークのみであるかどうかを確認します。「neutron net-list」のコマンドを実行します。「ctlplane」以外のネットワークがある場合には、他のネットワークに対して「neutron net-delete <UUID>」を実行します。これにより、初回のデプロイメント前に「ctlplane」のみが存在する状態となり、デプロイメントを成功させるのに役立ちます。

下層の Database-as-a-Service (Trove) のプロセスは、サービスのバックエンドデータベースが到達可能でなければ、開始しません。この問題を回避するには、バックエンドデータベースと同じノードに Database-as-a-Service をデプロイする必要があります。

1 つのノードで複数のネットワークインターフェースがプロビジョニングネットワークに接続されると、検出が失敗します。プロビジョニングネットワークには、1 つのインターフェースしか接続することはできません。これには、ボンディングを構成するインターフェースは使用できません。

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

ironic-conductor が突然停止すると、ベアメタルノードが一定の状態でロックされてしまうことがあります。このようになると、ユーザーはそのノードを削除したり、状態を切り替えたりすることはできません。回避策として、director のデータベースにログインして、以下のクエリーを使用してノードを利用可能な状態に戻すように設定してから、ロックを削除します。

UPDATE nodes SET provision_state="available", target_provision_state=NULL, reservation=NULL WHERE uuid=<node uuid>;

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 イメージの作成を正常に実行できるようになります。

アンダークラウドで、HAProxy が openstack-ironic-api サービスに対して HTTP チェックを 2 秒ごとに実行するように設定されています。このチェックにより、openstack-ironic-api は次のようなエラーでトレースバックを stderr にログ記録します。

 error: [Errno 104] Connection reset by peer
 error: [Errno 32] Broken pipe

チェックは 2 秒間隔で実行されるため、このメッセージは /var/log/messages に繰り返し頻繁に記録されてしまいます。回避策としては、root パーミッションに切り替えて /etc/haproxy/haproxy.cfg を編集し、ironic のリスナーの設定から「option httpchk GET /」の行をコメントアウトします。

 listen ironic
   bind 192.0.2.2:6385
   bind 192.0.2.3:6385
   # option httpchk GET /
   server 192.0.2.1 192.0.2.1:6385 check fall 5 inter 2000 rise 2

ファイルを保存して haproxy を再起動します。

 sudo systemctl restart haproxy

これで、openstack-ironic-api からのトレースバックは stderr に書き込まれなくなります。

Keystone エンドポイントはすべて外部の仮想 IP 上にあります。これは、Keystone への全 API コールが外部仮想 IP で行われます。今回は、この問題の回避策はありません。

OpenStack Dashboard (Horizon) は、ローカル IP アドレスで接続を受け入れるように設定されていません。これは、アンダークラウドの UI を含む OpenStack Dashboard を IP アドレスで参照できないことを意味します。回避策として、IP アドレスの代わりにアンダークラウドの完全修飾ドメイン名を使用します。IP アドレスを使用したアクセスが必要な場合は、/etc/openstack-dashboard/local_settings を編集して IP アドレスを ALLOWED_HOSTS 設定に追加してから、httpd サービスを再起動します。これで、ホストの IP アドレスを使用して OpenStack Dashboard を参照できるようになります。

High Availability (VRRP) ルーターと L2 Population の対話で、既知の問題が確認されました。現在、HA ルーターをサブネットに接続すると、HA ルーターは設計上、分散ポートを使用します。各ルーターには、スケジューリングされている各ノード上の同じポートの詳細が含まれており、マスタールーターのみにそのポートへの IP が設定されており、全スレーブルーターのポートには IP が設定されていません。
そのため、L2Population は古い情報を使用して、ルーターがノード上にあることを通知します (そのポートのポートバインド情報に記載)。
その結果、論理ネットワーク上にポートがあるノードにはそれぞれ、ポートがバインドされるはずのノードに対してのみトンネルが作成されます。また、作成したトンネル経由で、そのポートに対するトラフィックが送信されるように、フォワーディングのエントリーが設定されます。
ただし、マスターのルーターがポートバインドで指定されたノード上にある保証がないため、このアクションは失敗する可能性があります。そのため、マスタールーターが実際にノード上にある場合には、フェイルオーバーのイベントにより、マスタールーターが別のノードに移動されるため、ルーターとの接続性が失われてしまいます。

Ceph Storage ノードの 0 台からのスケールアップはサポートされていません。

swift のプロキシーポートは、アンダークラウドのファイアウォールで拒否されます。これは、swift プロキシーがローカルホストからの接続のみを受け入れることを意味します。回避策として、ファイアウォールで swift のプロキシーポートを開放します。

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

これで、リモートマシンからの swift プロキシーへの接続が有効になります。

NovaEnableRbdBackend パラメーターを使用する場合には、一時ストレージが true としてハードコードされています。これは、NovaEnableRbdBackend インスタンスが Ceph Storage 上に cinder バックエンドを使用できないことを意味します。回避策として、以下の行を puppet/hieradata/compute.yaml に追加します。

nova::compute::rbd::ephemeral_storage: false

これで一時ストレージが無効になります。

番号付きの NIC のエイリアス (nic1、nic2 など) に数えられるのは、スイッチポートへの有効な接続がある NIC のみです。回避策として、director には各ノードから全インターフェース上の最初のコントローラーに ping を送信するスクリプトが含まれています。デプロイメント時に接続されていないリンクがあるノードの場合には検出されるので、修正することが可能です。もうひとつの可能な回避策としては、各ホストに NIC 番号から物理 NIC へのマッピングが記載されたマッピングファイルを使用する方法です。1 つまたは複数のオーバークラウドノードでリンクが停止しているため正しく設定を行わない場合には、検出されるようになり、オーバークラウドは再度デプロイすることが可能です。

「openstack overcloud update stack」コマンドは、背後で操作が継続するにもかかわらず、即時に出力を返していました。このコマンドは対話的でないため、永遠に実行されるように見えました。そのような場合には、「-i」のフラグを付けてコマンドを実行すると、手動での対話が必要な場合にユーザーにプロンプトが表示されるようになります。

タイミングの問題により、オーバークラウドの neutron サービスは正しく自動起動しません。これは、インスタンスがアクセスできないことを意味します。回避策として、コントローラーノードクラスターで以下のコマンドを実行することができます。

$ sudo pcs resource debug-start neutron-l3-agent

これでインスタンスが適切に起動するようになります。

ごくまれですが、RabbitMQ がデプロイメント時に起動に失敗する場合があります。回避策として、RabbitMQ を手動で起動します:

$ pcs resource debug-start rabbitmq

この後でデプロイのコマンドを再度実行すると、デプロイメントは成功するようになります。