Red Hat OpenStack Platform の今回のリリースでは、以下の機能拡張が提供されています。

BZ#1419556

Object Store サービス (swift) は Barbican を統合して、保管されている (at-rest) オブジェクトを透過的に暗号化/復号化できるようになりました。at-rest 暗号化は、in-transit 暗号化とは異なり、ディスクに保管されている間にオブジェクトが暗号化されることを指します。

Swift のオブジェクトは、ディスク上にクリアテキストとして保管されます。このようなディスクは、ライフサイクル終了に達した時に適切に破棄しなければ、セキュリティーリスクをもたらす可能性があります。このリスクは、オブジェクトを暗号化することによって軽減されます。

Swift はこれらの暗号化タスクを透過的に実行し、オブジェクトは swift にアップロードされる際には自動的に暗号化され、ユーザーに提供される際には自動的に復号化されます。この暗号化と復号化は、Barbican に保管されている同じ (対称) キーを使用して処理されます。

BZ#1540239

今回の機能拡張により、Gnocchi DB インスタンスへのメトリックデータ送信がサポートされるようになりました。

collectd コンポーザブルサービス向けに以下の新しいパラメーターが追加されました。CollectdGnocchiAuthMode が「simple」に設定されると、CollectdGnocchiProtocol、CollectdGnocchiServer、CollectdGnocchiPort、CollectdGnocchiUser が設定に取り入れられます。

CollectdGnocchiAuthMode が「keystone」に設定されている場合には、CollectdGnocchiKeystone* パラメーターが設定に取り入れられます。

追加されたパラメーターに関する詳しい説明は以下のとおりです。

  CollectdGnocchiAuthMode:
    型: 文字列
    説明: >
      Gnocchi サーバーが使用する認証のタイプ。
      サポートされている値は、「simple」 と「keystone」です。
    デフォルト: 'simple'
  CollectdGnocchiProtocol:
    型: 文字列
    description: Gnocchi サーバーの使用する API プロトコル
    default: 'http'
  CollectdGnocchiServer:
    型: 文字列
    説明: >
      メトリックの送信先となる gnocchi エンドポイントの名前またはアドレス
    デフォルト: なし
  CollectdGnocchiPort:
    型: 数値
    説明: Gnocchi サーバーに接続するためのポート
    デフォルト: 8041
  CollectdGnocchiUser:
    型: 文字列
    説明: >
      簡易認証を使用して、リモートの Gnocchi サーバーに対して認証を行うためのユーザー名
    デフォルト: なし
  CollectdGnocchiKeystoneAuthUrl:
    型: 文字列
    説明: 認証先となる Keystone エンドポイントの URL
    デフォルト: なし
  CollectdGnocchiKeystoneUserName:
    型: 文字列
    説明: Keystone に対して認証を行うためのユーザー名
    デフォルト: なし
  CollectdGnocchiKeystoneUserId:
    型: 文字列
    説明:  Keystone に対して認証を行うためのユーザー ID
    デフォルト: なし
  CollectdGnocchiKeystonePassword:
    型: 文字列
    説明: Keystone に対して認証を行うためのパスワード
    デフォルト: なし
  CollectdGnocchiKeystoneProjectId:
    型: 文字列
    説明: Keystone に対して認証を行うためのプロジェクト ID
    デフォルト: なし
  CollectdGnocchiKeystoneProjectName:
    型: 文字列
    説明: Keystone に対して認証を行うためのプロジェクト名
    デフォルト: なし
  CollectdGnocchiKeystoneUserDomainId:
    型: 文字列
    説明: Keystone に対して認証を行うためのユーザードメイン ID
    デフォルト: なし
  CollectdGnocchiKeystoneUserDomainName:
    型: 文字列
    説明: Keystone に対して認証を行うためのユーザードメイン名
    デフォルト: なし
  CollectdGnocchiKeystoneProjectDomainId:
    型: 文字列
    説明: Keystone に対して認証を行うためのプロジェクトドメイン ID
    デフォルト: なし
  CollectdGnocchiKeystoneProjectDomainName:
    型: 文字列
    説明: Keystone に対して認証を行うためのプロジェクトドメイン名
    デフォルト: なし
  CollectdGnocchiKeystoneRegionName:
    型: 文字列
    説明: Keystone に対して認証を行うためのリージョン名
    デフォルト: なし
  CollectdGnocchiKeystoneInterface:
    型: 文字列
    説明: 認証先となる Keystone エンドポイントの種別
    デフォルト: なし
  CollectdGnocchiKeystoneEndpoint:
    型: 文字列
    説明: >
      Keystone の値を上書きする場合には、Gnocchi サーバーの URL を
      明示的に指定します。
    デフォルト: なし
  CollectdGnocchiResourceType:
    型: 文字列
    説明: >
      ホストを保管するために Gnocchi によって作成される 
      collectd-gnocchi プラグインのデフォルトのリソースタイプ
    デフォルト: 'collectd'
  CollectdGnocchiBatchSize:
    型: 数値
    説明: Gnocchi がバッチ処理すべき値の最小数
    デフォルト: 10

本項に記載する項目は、テクノロジープレビューとして提供しています。テクノロジープレビューの適用範囲のステータスに関する詳細情報およびそれに伴うサポートへの影響については、https://access.redhat.com/support/offerings/techpreview/ を参照してください。

BZ#1488095

RHOS-12 以降では、OpenStack サービスはコンテナー化されています。今回のリリースでは、 OpenStack Tempest もコンテナー化されました。コンテナー化された OpenStack Tempest はテクノロジープレビューとして提供されています。

本項では、Red Hat OpenStack Platform の注目すべき変更点や推奨プラクティスなど、今回のリリースに関する重要な情報を記載しています。お使いのデプロイメントに最大限の効果をもたらすために、以下の情報を考慮する必要があります。

BZ#1468020

Shared File System サービス (manila) は、IPv6 環境で manila を使用できるようにする NetApp ONTAP cDOT ドライバーを使用して IPv6 アクセスルールのサポートを提供するようになりました。

その結果、Shared File System サービスは、NetApp IPv6 ネットワーク上で ONTAP バックエンドによってバッキングされる共有のエクスポートをサポートします。エクスポートされた共有へのアクセスは、IPv6 のクライアントアドレスによって制御されます。

BZ#1469208

Shared File System サービス (manila) は、NFSv4 プロトコルを介して、Ceph File System (CephFS) によってバッキングされる共有ファイルシステムのマウントをサポートしています。コントローラーノード上で稼働する NFS-Ganesha サーバーを使用して、高可用性 (HA) を使用するテナントに CephFS をエクスポートします。テナントは相互に分離され、提供される NFS ゲートウェイインターフェースを介してのみ CephFS にアクセスすることができます。director には、この新機能は完全に統合されているので、CephFS バックエンドのデプロイとShared File System サービスの設定が可能です。

BZ#1496584

neutron サービスをコンテナー化する場合には、ネットワーク名前空間でコマンドの実行を試みると、以下のようなエラーで操作が失敗する可能性があります。

# ip netns exec qrouter...
RTNETLINK answers: Invalid argument

ネットワーク名前空間内でコマンドを実行するには、その名前空間を作成した neutron コンテナーから操作を行う必要があります。たとえば、l3-agent からルーター用のネットワーク名前空間を作成した場合には、コマンドを以下のように変更します。

# docker exec neutron_l3_agent ip netns exec qrouter...

同様に、「qdhcp」で始まるネットワーク名前空間の場合には、「neutron_dhcp」コンテナーからコマンドを実行してください。

BZ#1503521

本バージョンでは、networking-ovn の内部 DNS 解決のサポートが追加されました。ただし、既知の制限事項が 2 点あり、その 1 つは bz#1581332 で、内部 DNS を介した内部 fqdn 要求が適切に解決されない問題です。

GA リリース版の tripleo は、デフォルトではこの拡張機能を設定しない点に注意してください。bz#1577592 で回避策を参照してください。

BZ#1533206

openstack-gnocchi パッケージは gnocchi という名前に変更されました。アップストリームのスコープが変更されたため、openstack- のプレフィックスは削除されました。Gnocchi は OpenStack の傘下から外れて、スタンドアロンのプロジェクトになりました。

BZ#1556933

python-cryptography は、バージョン 2.1 より、証明書で使用されている CNS 名が IDN 標準に準拠していることを確認するようになりました。検出された名前がこの仕様に従っていない場合には、cryptography はその証明書の検証に失敗し、OpenStack コマンドラインインターフェースを使用する際や OpenStack のサービスログで異なるエラーが見つかる場合があります。

BZ#1563412

OpenStack Compute (nova) に確保されるホストのメモリーが 2048 MB から 4096 MB に増やされました。これは、環境の容量推定に影響する可能性があります。必要な場合には、環境ファイル内の「NovaReservedHostMemory」パラメーターを使用して確保するメモリーを再設定することができます。以下に例を示します。

parameter_defaults:
  NovaReservedHostMemory: 2048

BZ#1564176

python-mistralclient は、サポートされているオーバークラウドユースケースのいずれにも属さないため、OSP 13 リリースでは -tools チャンネルから削除されました。

BZ#1567735

OVN をネットワークバックエンドとして使用する OSP13 で、最初のリリースには IPv6 のサポートは含まれません。ゲスト仮想マシンから送信される Neighbor Solicitation 要求への応答に問題があり、デフォルトのルートが失われます。

BZ#1575752

以前のバージョンでは、*NetName パラメーター (例: InternalApiNetName) によってデフォルトのネットワークの名前が変更されていました。これはサポートされなくなりました。

デフォルトのネットワーク名を変更するには、カスタムのコンポーザブルネットワークファイル (network_data.yaml) を使用して、「openstack overcloud deploy」コマンドに「-n」オプションを指定してそのファイルを追加してください。このファイルで、「name_lower」フィールドに変更するネットワークのカスタム net 名を指定します。詳しい情報は、『Advanced Overcloud Customization』ガイドの「Using Composable Networks」を参照してください。

また、ServiceNetMap テーブルのローカルパラメーターを network_environment.yaml に追加して、古いネットワーク名のデフォルト値を新しいカスタム名でオーバーライドする必要があります。デフォルト値は /usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml にあります。この ServiceNetMap の変更は、今後の OSP-13 リリースでは必要なくなります。

BZ#1577537

OSP 13 ベータ版で一部のコンテナーイメージが利用できなかった問題が修正されました。

BZ#1578312

OVSDB サーバーが異なるコントローラーノードにフェイルオーバーする場合に、その状況が検出されなかったため、neutron-server/metadata-agent からの再接続が実行されませんでした。

その結果、metadata-agent が新しいメタデータ名前空間をプロビジョニングせず、クラスターが想定通りに動作しないため、仮想マシンの起動が機能しない場合があります。

回避策としては、新しいコントローラーが OVN データベース向けにマスターとして昇格した後に、全コンピュートノードで ovn_metadata_agent コンテナーを再起動する方法を使用することができます。また、plugin.ini で ovsdb_probe_interval の値を 600000 ミリ秒に増やしてください。

BZ#1589849

OVN メタデータエージェントがコンピュートノードで停止すると、そのノード上の全仮想マシンがメタデータサービスにアクセスできなくなります。これにより、新規仮想マシンを起動したり、既存の仮想マシンを再起動したりする場合に、OVN メタデータエージェントが稼働状態に戻るまで仮想マシンはメタデータにアクセスできません。

BZ#1592528

まれな状況で、コントローラーノードを数回リブートした後に、RabbitMQ の稼働状態が一定しなくなってオーバークラウド上の API 操作がブロックされる場合があります。

この問題には、以下のような症状があります。
 - いずれかの OpenStack サービスのログで以下の形式のエントリーが表示される。
 DuplicateMessageError: Found duplicate message(629ff0024219488499b0fac0cacaa3a5). Skipping it.
 - 「openstack network agent list」で一部のエージェントが DOWN と返される。

通常の操作ができる状態に戻すには、いずれかのコントローラーノードで以下のコマンドを実行します (1 台のコントローラーでのみ実行する必要があります):
 pcs resource restart rabbitmq-bundle

現時点における Red Hat OpenStack Platform の既知の問題は以下のとおりです。

BZ#1321179

「python-requests」を使用する OpenStack のコマンドラインクライアントは、現在、IP アドレスが SAN フィールドに記載されている証明書は検証できません。

BZ#1461132

Cinder ボリュームと Cinder バックアップの両方のブロックストレージバックエンドとして Red Hat Ceph Storage を使用する場合には、差分バックアップの実行を試みると、代わりに完全バックアップが警告なしに実行されます。これは既知の問題です。

BZ#1508449

OVN は、直接コンピュートノード上で ovn-controller を使用して openflow コントローラーとして DHCP を提供します。ただし、SR-IOV インスタンスは VF/PF を介して直接ネットワークにアタッチされます。そのため、SR-IOV インスタンスは DHCP の応答をどこからも取得することができません。

この問題を回避するには、「OS::TripleO::Services::NeutronDhcpAgent」を以下のように変更してください。

   OS::TripleO::Services::NeutronDhcpAgent: docker/services/neutron-dhcp.yaml

BZ#1515815

ルーターゲートウェイがクリアされる際には、検出された IP アドレスに関連するレイヤー 3 フローは削除されません。検出される IP アドレスには、PNF と外部ゲートウェイの IP アドレスが含まれます。これによりフローが古くなりますが、機能的には問題ありません。外部ゲートウェイと IP アドレスは頻繁には変わりません。古くなったフローは、外部ネットワークが削除される際に削除されます。

BZ#1518126

Redis は、TLS を有効化した HA デプロイメントでは、ノード間でデータのレプリケーションを正しく行うことができません。Redis のフォロワーノードにはリーダーノードからのデータは全く含まれません。Redis デプロイメントには TLS を無効にすることを推奨します。

BZ#1519783

Neutron は、Neutron Router 作成でクォータを超過していることを示すエラーが表示する場合があります。これは、networking-odl のバグが原因で Neutron DB で単一の作成要求によって複数のルーターリソースが作成される既知の問題です。この問題の回避策は、OpenStack Neutron CLI で重複したルーターを削除して、再度ルーターを 1 つ作成する方法で、これにより単一のインスタンスになります。

BZ#1557794

『Back Up and Restore the Director Undercloud』の手順でリグレッションが確認されました。その結果、同ガイドは変更と確認を行ってから公開する必要があります。

従って、『Back Up and Restore the Director Undercloud』は Red Hat OpenStack Platform 13 の一般提供リリースでは提供されません。この手順の更新は、一般提供リリースの後に優先され、確認が済み次第公開される予定です。

BZ#1559055

OpenDaylight のロギングで前半のログが含まれていない可能性があります。OpenDaylight の journald ロギング (「docker logs opendaylght_api」コマンドを使用) の既知の問題です。現在の回避策としては、OpenDaylight のロギングを「file」メカニズムに切り替えて、コンテナー内の /opt/opendaylight/data/logs/karaf.log にロギングされるようにする方法があります。そのためには、次の heat パラメーターを設定します: OpenDaylightLogMechanism: ‘file’

BZ#1562035

docker-puppet または paunch コンテナーの実行中には、nsenter コールのカーネルエラーで Docker run が失敗します。これは、fork 関数の unshare コールの使用と関連したカーネルの問題として確認されました。この問題は、RHEL 7.5.2 リリースに関連付けられた次のカーネルリリースで修正されることになっています (6 月末の予定)。BZ #1577745 と関連付けられたカーネルのホットフィックスがリクエストに応じて提供可能です。

その代わりに、以下の回避策を使用することも可能です。
1) 環境ファイルから「TunedProfileName」パラメーターを削除してデプロイします。cpu-partitioning を使用せずにデプロイした場合には再現性がより低くなることが確認されています。 デプロイが完了したら、以下のステップに従って tuned プロファイルを設定します。
  * /etc/tuned/cpu-partitioning-variables.conf で「isolated_cores」を設定します。
  * 「tuned-adm profile cpu-partitioning」のコマンドを実行します。
  * ノードを再起動します。
注記: この回避策を使用すると、問題の発生率が低くなることが確認されています。

2) https://bugzilla.redhat.com/show_bug.cgi?id=1562035#c27 および https://bugzilla.redhat.com/show_bug.cgi?id=1562035#c31 のコメントで指定されているコマンドに従います。
注記: これにより、ホストの PID がコンテナーに公開されてコンテナーが実行されることになり、望ましい結果ではありません。「pid=host」回避策を使用しなくても済む方法の詳しい手順は、OSP13 の次のマイナーリリースで提供されます。

BZ#1568012

Floating IP をインスタンスに割り当ててからその Floating IP の割り当てを解除する際に、外部の IP への接続が失敗します。この状況は、テナントの VLAN ネットワークで、NAPT 以外のスイッチ上で起動する仮想マシンに Floating IP が割り当てられ、その後にその Floating IP が削除された場合に発生します。これによって、NAPT スイッチの FIB テーブルでフローが (散発的に) 失われます。


失われた FIB テーブルのエントリーが原因で、仮想マシンはパブリックネットワークへの接続を失います。

Floating IP を仮想マシンに割り当てると、パブリックネットワークへの接続が復元されます。その Floating IP が仮想マシンに割り当てられている限りは、インターネットへの接続が可能ですが、外部ネットワークからのパブリック IP/Floating IP を失います。

BZ#1568311

Floating IP が割り当てられていないインスタンスが別のルーター上の Floating IP が割り当てられているインスタンスに接続を試みると、複数のサブネット全体にわたる Nova インスタンス間のレイヤー 3 接続が失敗する可能性があります。これは、Nova インスタンスが複数の Compute ノードに分散している場合に発生します。この問題には、現在適切な回避策はありません。

BZ#1568976

機能の読み込みのバグが原因で、デプロイメント中に OpenDaylight インスタンスが 1 つまたは複数失敗する場合があり、これによって、デプロイメントまたは機能でエラーが発生する可能性があります。

このような状況では、以下の措置を取ってください。
 * In an HA デプロイメントの場合は、少なくとも 2 つの OpenDaylight インスタンスが正しくブートしなければデプロイメントは失敗する場合があります。このような場合には、現在の回避策は、「docker ps」コマンドで各コンテナーのヘルスステータスをチェックする方法です。異常な場合には、「docker restart opendaylight_api」でコンテナーの再起動を実行します。

 * TLS ベースのデプロイメントでは、全 OpenDaylight インスタンスが正しくブートしなければデプロイメントは失敗します。このため、デプロイメントは全 OpenDaylights が正常にブートするまで再起動する必要があります。

BZ#1571864

Fast Forward Upgrade の準備中に Heat stack リソースの一時的に削除されることにより、RHEL が登録解除がトリガーされます。
このような状態になると、Heat ソフトウェアデプロイメントのシグナルが正常に機能しないため、RHEL の登録解除は保留になります。

この問題を回避するには、オーバークラウドがまだ OSP 10 の間に、オーバークラウドの最後のマイナーバージョン更新を実行する準備が整った時点で以下の手順を実行します。
1. テンプレートファイル /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration/rhel-registration.yaml を編集します。
2. そのテンプレートから RHELUnregistration および RHELUnregistrationDeployment のリソースを削除します。
3. マイナー更新と Fast Forward Upgrade の手順を続行します。

BZ#1573597

パフォーマンスの低い Swift クラスターが Gnocchi のバックエンドとして使用されると、collectd ログに 503 エラーと、gnocchi-metricd.conf に "ConnectionError: ('Connection aborted.', CannotSendRequest())" エラーが出力される場合があります。
この問題を軽減するには、CollectdDefaultPollingInterval パラメーターの値を増やすか、Swift クラスターのパフォーマンスを改善してください。

BZ#1574708

OpenDaylight インスタンスがクラスターから削除されて再接続されると、そのインスタンスがクラスターに正常に参加されない場合があります。ノードは最終的にクラスターに再参加します。

このような場合には、以下のアクションを実行すべきです。
 * 問題の発生したノードを再起動する
 * REST エンドポイントをモニタリングして、クラスターメンバーの正常性を確認します: http://$ODL_IP:8081/jolokia/read/org.opendaylight.controller:Category=ShardManager,name=shard-manager-config,type=DistributedConfigDatastore
 * 応答には、“SyncStatus” のフィールドが含まれるはずで、値が “true” の場合には、クラスターメンバーが正常であることを示します。

BZ#1574725

VLAN プロバイダーネットワークの同じサブネット内の複数の仮想マシンが異なる 2 台のコンピュートノードでスケジュールされると、それらの仮想マシン間の ARP が散発的に失敗します。 

それらの仮想マシン間の ARP パケット送信は失敗するため、2 つの仮想マシン間には実質的にネットワークがないことになります。

BZ#1575023

ceph-ansible の複合 ceph-keys 処理により、/etc/ceph/ceph.client.manila.keyring ファイルの内容が誤って生成されるため、manila-share サービスの初期化が失敗します。

manila-share サービスを初期化できるようにするには、以下の手順を実行してください。
1) オーバークラウドのデプロイに使用する /usr/share/openstack/tripleo-heat-templates のコピーを作成します。

2) .../tripleo-heat-templates/docker/services/ceph-ansible/ceph-base.yaml ファイルを編集して、295 行目の 3 つ並んだバックスラッシュをすべて 1 つのバックスラッシュに変更します。
編集前:
mon_cap: 'allow r, allow command \\\"auth del\\\", allow command \\\"auth caps\\\", allow command \\\"auth get\\\", allow command \\\"auth get-or-create\\\"'
編集後:
mon_cap: 'allow r, allow command \"auth del\", allow command \"auth caps\", allow command \"auth get\", allow command \"auth get-or-create\"'

3) tripleo-heat-templates のコピーのパスを、元の overcloud-deploy コマンドで実行した /usr/share/openstack-tripleo-heat テンプレートの場所に置き換えてオーバークラウドをデプロイします。

ceph キーの /etc/ceph/ceph.client.manila.keyring ファイルには適切な内容が記載されるようになり、manila-share サービスは正常に初期化されるようになります。

BZ#1575118

Ceph リリース 12.2.1 では、各 OSD で許容される PG の最大数が少なくなっています。上限値が低くなったため、モニターが途中で HEALTH_WARN メッセージを発行する場合があります。

モニターの警告の閾値は、1 OSD あたり 300 から 200 PG に削減されています。200 は、一般的な推奨目標値である 1 OSD あたり 100 PG の 2 倍です。この上限は、モニター上の mon_max_pg_per_osd オプションで調整することができます。以前の mon_pg_warn_max_per_osd オプションは削除されています。

プールの消費する PG の量を少なくすることはできません。アップグレードにより既存のデプロイメントが上限に達した場合には、ceph-upgrade のステップを実行中に上限をアップグレード前の値に増やすことができます。環境ファイルで、以下のようなパラメーター設定を追加します。

  parameter_defaults:
    CephConfigOverrides:
      mon_max_pg_per_osd: 300

この設定は ceph.conf に適用されて、クラスターは HEALTH_OK の状態を維持します。

BZ#1575150

OpenDaylight クラスターのメンバーが (エラーなどで) 停止した際に OpenDaylight クラスターが最長で 30 分応答しなくなる既知の問題があります。回避策は、クラスターが再度アクティブになるまで待つことです。

BZ#1575496

director で外部ネットワーク用の物理ホストのインターフェースを使用する場合に、そのインターフェースが OVS ブリッジに接続されていなければ、そのインターフェースは OpenDaylight 環境でトラフィックが通過しなくなるので、この種の構成は避けるべきです。

オーバークラウドの外部ネットワーク用の NIC テンプレートでは、常に OVS ブリッジを使用してください。このブリッジは、director ではデフォルトで「br-ex」という名前です (任意の名前を使用可)。外部ネットワークに使用する物理ホストのインターフェースをこの OVS ブリッジに接続する必要があります。

OVS ブリッジに接続したインターフェースを使用すると、デプロイメントは正しく機能し、外部ネットワークからテナントにトラフィックが通過できるようになります。

BZ#1577975

OpenDaylight で CPU の使用率が非常に高くなる期間が発生する場合があります。この問題は、OpenDaylight の機能には影響しませんが、他のシステムのサービスに悪影響を及ぼす可能性があります。

BZ#1579025

OVN pacemaker Resource Agent (RA) のスクリプトは、pacemaker がスレーブノードのプロモーションを試みる際に、プロモーションのアクションが適切に処理されない場合があります。これは、ovsdb-servers が master のステータスを RA スクリプトに報告し、マスターの ip がそのノードに移った場合に発生する問題で、アップストリームでは修正済みです。

問題が発生すると、neutron サーバーは OVN North および South DB サーバーに接続できなくなり、neutron サーバーに対する Create/Update/Delete API はすべて失敗します。

この問題は、ovn-dbs-bundle リソースを再起動すると解決します。以下のコマンドをコントローラーノードで実行してください。

「pcs resource restart ovn-dbs-bundle」

BZ#1579417

SNAT サポートには、テナントネットワークに使用されているカプセル化に拘らず、VXLAN トンネルを設定する必要があります。また、VLAN テナントネットワークを使用する場合は、VXLAN トンネルのヘッダーがペイロードに追加され、それによってパケットがデフォルトの MTU (1500 バイト) を超過する可能性があるので、MTU を正しく設定する必要もあります。

SNAT トラフィックが流れるようにするには、VXLAN トンネルを適切に設定する必要があります。
VLAN テナントネットワークを使用する場合は、以下のいずれかの方法で MTU を設定して、SNAT トラフィックが VXLAN トンネルを流れるようにしてください:
 * VLAN テナントベースのネットワークは、ネットワーク構成 1 つにつき 1450 の MTU を使用するように設定します。
 * heat パラメーターの NeutronGlobalPhysnetMtu を 1450 に設定します。注記: これは、すべての flat/VLAN プロバイダーネットワークが 1450 MTU となることを意味し、望ましい設定ではありません (外部プロバイダーネットワークは特に)。
 * テナントネットワークの下層は、MTU を 1550 (またはそれ以上) に設定します。これには、テナントネットワーク用の NIC の NIC テンプレートで MTU を設定する操作が含まれます。

BZ#1581337

PING タイプのヘルスモニターを使用するには、HAProxy (ネットワークロードバランシング用のドライバーで使用するデフォルトのソフトウェア) のバージョンは最小で 1.6 が必要です。古いバージョンの HAProxy を使用すると、ヘルスチェックはユーザーが知らないうちに、TCP 接続となります。

アップストリームのコミュニティーでは、使用中の HAProxy のバージョンを確認して、それに応じてアクションを実行するチェックをコードに追加して、問題を修正済みです。
HAProxy バージョン 1.6 以降の場合には、PING を使用できます。
そうでない場合には、引き続き TCP 接続を使用します (それらの haproxy バージョンに他に解決方法がない場合には、全く使えなくなってしまうよりは、TCP 接続を使用した方がよいことになります)。

OSP13 の GA リリースでは、HAProxy が RHEL チャンネルの一部として出荷されており、そのチャンネルでは古いバージョンの HAProxy を使用しているのが問題点です。そのため、OSP13 のユーザーが PING タイプのヘルスモニターを設定すると、代わりに TCP 接続されてしまいます。

BZ#1583541

SRIOV ベースの Compute インスタンスは、異なるネットワーク上にある OVS Compute インスタンスには接続できません。回避策は、両方の VLAN プロバイダーネットワークに接続された外部ルーターを使用することです。

BZ#1584518

RHOSP では、nova で DifferentHostFilter / SameHostFilter の有無はデフォルトでは設定されません。これらの設定は、一部のテストを適切に完了するために必要です。このため、いくつかのセキュリティーグループのテストが無作為に失敗する可能性があります。

そのようなテストは省略するか、nova の設定にそれらのフィルターを追加する必要があります。

BZ#1584762

アンダークラウド上で Telemetry が手動で有効化された場合には、各ノードのファイアウォールの間違った設定が原因で「hardware.*」メトリックは機能しません。

回避策としては、以下のようにアンダークラウドデプロイメント用に更にテンプレートを追加することによって、コントロールプレーンネットワークで「snmpd」サブネットを手動で設定する必要があります。

parameter_defaults:
  SnmpdIpSubnet: 192.168.24.0/24

BZ#1588186

競合により、Open vSwitch は Opendaylight openflowplugin に接続されません。この問題の修正は、本製品の 13.z リリースで実装される予定です。

BZ#1590114

アンダークラウド上で Telemetry が手動で有効化された場合には、各ノードのファイアウォールの間違った設定が原因で「hardware.*」メトリックは機能しません。

回避策としては、以下のようにアンダークラウドデプロイメント用に更にテンプレートを追加することによって、コントロールプレーンネットワークで「snmpd」サブネットを手動で設定する必要があります。

parameter_defaults:
  SnmpdIpSubnet: 192.168.24.0/24

BZ#1590560

ceph-ansible ユーティリティーは、ceph-create-keys コンテナーが作成されたのと同じノードから ceph-create-keys コンテナーを必ずしも削除しません。

このため、「Error response from daemon: No such container: ceph-create-keys.」というメッセージが表示されてデプロイメントが失敗する場合があります。これにより、複数のコンピュートノードを使用する新規デプロイメントや、Ceph クライアントとして動作し Ceph を使用するサービスをホスティングするカスタムロールを使用する新規デプロイメントを含む ceph-ansible の実行で影響を受ける場合があります。

BZ#1590938

RHCS3 上に OSD を 3 つ以上デプロイして、pgcalc (https://access.redhat.com/labs/cephpgc) により決定されるプールの PG 数を設定する場合は、全 OSD がアクティブになる前に ceph-ansible がプールを作成するため、デプロイメントが失敗します。

この問題を回避するには、デフォルトの PG 数を 32 に設定しておき、デプロイメントの終了時には、『Storage Strategies Guide』の https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html/storage_strategies_guide/placement_groups_pgs#set_the_number_of_pgs に記載の手順で PG 数を増やします。

BZ#1590939

ceph-ansible OpenStack プールタスクに誤ったコンテナー名が付いているため、Ceph MON と OSD のコロケーションはまだできません。
標準の HCI (Compute + OSD) には影響ありません。

BZ#1593290

SR-IOV ベースのネットワークインターフェースがアタッチされているゲストを実行中に nova-compute サービスを再起動した後に、そのゲストを削除すると、そのノード上の SR-IOV VF はどのゲストにもアタッチできなくなります。これは、サービスの起動時に利用可能なデバイスが列挙されますが、ゲストにアタッチ済みのデバイスはホストデバイスの一覧に含まれないためです。

ゲストを削除した後には、「nova-compute」サービスを再起動する必要があります。ゲストを削除した後にこのサービスを再起動すると、利用可能な SR-IOV デバイスの一覧が正しくなります。

BZ#1593715

非セキュアなレジストリーの一覧は、メジャーアップグレード中に一部のコンテナーイメージがプルされた後に更新されるため、新たに導入された非セキュアなレジストリーからのコンテナーイメージは「openstack overcloud upgrade run」コマンドの実行中にダウンロードに失敗します。

以下の回避策を使用することができます。

オプション A: Pacemaker によって管理されているコンテナーがあるノード上の /etc/sysconfig/docker ファイルを手動で更新して、新たに導入された非セキュアなレジストリーを追加します。

オプション B: アップグレードの直前に「openstack overcloud deploy」コマンドを実行して、環境ファイルの DockerInsecureRegistryAddress パラメーターで必要な新しい非セキュアなレジストリーを指定します。

これで、アップグレード中にすべてのコンテナーイメージがダウンロードされるようになるはずです。

BZ#1593757

既存のオーバークラウドデプロイメントで Octavia を有効化すると操作が成功したと報告されますが、コントローラーノード上のファイアウォールルールが誤って設定されているため、Octavia API エンドポイントに到達出来ません。

回避策:

全コントローラーノードでファイアウォールルールを追加して、それらが DROP ルールの前に挿入されるようにします。

IPv4:
  # iptables -A INPUT -p tcp -m multiport --dports 9876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy ipv4" -j ACCEPT
  # iptables -A INPUT -p tcp -m multiport --dports 13876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy_ssl ipv4" -j ACCEPT
  # iptables -A INPUT -p tcp -m multiport --dports 9876,13876 -m state --state NEW -m comment --comment "120 octavia_api ipv4" -j ACCEPT


IPv6:
  # ip6tables -A INPUT -p tcp -m multiport --dports 9876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy ipv6" -j ACCEPT
  # ip6tables -A INPUT -p tcp -m multiport --dports 13876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy_ssl ipv6" -j ACCEPT
  # ip6tables -A INPUT -p tcp -m multiport --dports 9876,13876 -m state --state NEW -m comment --comment "120 octavia_api ipv6" -j ACCEPT

HAProxy を再起動します:
  # docker restart haproxy-bundle-docker-0

BZ#1595363

Fast Forward Upgrade の処理中には、アンダークラウドがバージョン 10 から 11 にアップグレードされます。場合によっては、nova-api.log に以下のようなエラーが報告される可能性があります。

「Unexpected API Error. Table 'nova_cell0.instances' doesn't exist」

このエラーは、以下のコマンドを実行すると解決することができます。

$ sudo nova-manage api_db sync

この問題はクリティカルではないので、Fast forward Upgrade プロセスを大きく妨げることにはならないはずです。