リリースノート

互換モード

#subscription-manager repos --enable=[reponame]
#subscription-manager repos --enable=[reponame]
#subscription-manager repos --disable=[reponame]
#subscription-manager repos --disable=[reponame]
{"devices": [{
  "type": "nic",
  "bus": "pci",
  "address": "0000:00:02.0",
  "mac": "01:22:22:42:22:21",
  "tags": ["nfvfunc1"]
  "vlans":[300,1000]
  }]
}

{"devices": [{
  "type": "nic",
  "bus": "pci",
  "address": "0000:00:02.0",
  "mac": "01:22:22:42:22:21",
  "tags": ["nfvfunc1"]
  "vlans":[300,1000]
  }]
}

今回の更新で、Dashboard にユーザーの詳細情報のページが新たに追加され、アクションログのユーザー ID をクリックするとそのユーザーの詳細情報のページを開くことができるようになりました。
今回の更新で、Dashboard にユーザーの詳細情報のページが新たに追加され、アクションログのユーザー ID をクリックするとそのユーザーの詳細情報のページを開くことができるようになりました。
今回の更新で、Dashboard にユーザーの詳細情報のページが新たに追加され、アクションログのユーザー ID をクリックするとそのユーザーの詳細情報のページを開くことができるようになりました。
今回の更新で、Dashboard にユーザーの詳細情報のページが新たに追加され、アクションログのユーザー ID をクリックするとそのユーザーの詳細情報のページを開くことができるようになりました。
Time Series Database as a Service (gnocchi) および Aodh API のエンドポイントは、REST API 上で「/healthcheck」HTTP エンドポイントを公開するようになりました。このエンドポイントを要求すると、サービスのステータスを確認することが可能で、これには認証は必要ありません。
Time Series Database as a Service (gnocchi) および Aodh API のエンドポイントは、REST API 上で「/healthcheck」HTTP エンドポイントを公開するようになりました。このエンドポイントを要求すると、サービスのステータスを確認することが可能で、これには認証は必要ありません。
director で自動フェンシング設定を使用して、より簡単に高可用性のデプロイメントとアップグレードを実行できるようになりました。この新機能を活用するには、「overcloud generate fencing」コマンドを使用してください。
director で自動フェンシング設定を使用して、より簡単に高可用性のデプロイメントとアップグレードを実行できるようになりました。この新機能を活用するには、「overcloud generate fencing」コマンドを使用してください。
管理者はボリュームの譲渡操作時にユーザー認証情報を記録する必要がありますが、それを手動で行うのは煩わしい作業です。

今回の更新により、認証情報をダウンロードするための新たなボタンがボリュームの譲渡の画面に追加され、情報を簡単に保存できるようになりました。これにより、管理者はボタンをクリックして、情報をダウンロードして CSV ファイルを自分のローカルマシンに保存することができます。
管理者はボリュームの譲渡操作時にユーザー認証情報を記録する必要がありますが、それを手動で行うのは煩わしい作業です。

今回の更新により、認証情報をダウンロードするための新たなボタンがボリュームの譲渡の画面に追加され、情報を簡単に保存できるようになりました。これにより、管理者はボタンをクリックして、情報をダウンロードして CSV ファイルを自分のローカルマシンに保存することができます。
今回の機能拡張で、サーバーによって停止中と検出された LBaaS エージェントのロードバランサーを自動的に再スケジュールする機能が追加されました。以前は、ロードバランサーをスケジュールして、複数の LBaaS エージェントで実行することができましたが、ハイパーバイザーが停止した場合には、そのノードに対してスケジュールされていたロードバランサーは、操作を停止していました。
今回の更新では、これらのロードバランサーは別のエージェントに自動的に再スケジュールされるようになりました。この機能は、デフォルトで無効になっており、「allow_automatic_lbaas_agent_failover」を使用して管理されます。
今回の機能拡張で、サーバーによって停止中と検出された LBaaS エージェントのロードバランサーを自動的に再スケジュールする機能が追加されました。以前は、ロードバランサーをスケジュールして、複数の LBaaS エージェントで実行することができましたが、ハイパーバイザーが停止した場合には、そのノードに対してスケジュールされていたロードバランサーは、操作を停止していました。
今回の更新では、これらのロードバランサーは別のエージェントに自動的に再スケジュールされるようになりました。この機能は、デフォルトで無効になっており、「allow_automatic_lbaas_agent_failover」を使用して管理されます。
今回の機能拡張により、「HaproxyNSDriver」クラス (v2) に「ProcessMonitor」クラスが実装されました。このクラスは、必要に応じて「external_process」モジュールを活用して HAProxy プロセスを監視/再起動します。LBaaS エージェント (v2) は「external_process」関連のオプションを読み込み、HAProxy が予期せず停止した場合には、設定済みのアクションを実行します。
今回の機能拡張により、「HaproxyNSDriver」クラス (v2) に「ProcessMonitor」クラスが実装されました。このクラスは、必要に応じて「external_process」モジュールを活用して HAProxy プロセスを監視/再起動します。LBaaS エージェント (v2) は「external_process」関連のオプションを読み込み、HAProxy が予期せず停止した場合には、設定済みのアクションを実行します。
今回の更新により、バージョン 5.1.0 MapR プラグインがサポートされるようになりました。
今回の更新により、バージョン 5.1.0 MapR プラグインがサポートされるようになりました。
ディスクはさまざまな状態にある可能性があります。このため、director はディスクを Ceph OSD にしようとして失敗する場合があります。以前のリリースでは、ユーザーが first-boot スクリプトを実行してディスクを消去し、Ceph に必要とされる GPT ラベルを設定することが可能でした。今回のリリースでは、Ironic の新たなデフォルト設定により、ノードが利用可能な状態に設定されるとディスクが消去され、また puppet-ceph の変更により、GPT ラベルが付いていないディスクには、そのラベルが付けられるようになりました。
ディスクはさまざまな状態にある可能性があります。このため、director はディスクを Ceph OSD にしようとして失敗する場合があります。以前のリリースでは、ユーザーが first-boot スクリプトを実行してディスクを消去し、Ceph に必要とされる GPT ラベルを設定することが可能でした。今回のリリースでは、Ironic の新たなデフォルト設定により、ノードが利用可能な状態に設定されるとディスクが消去され、また puppet-ceph の変更により、GPT ラベルが付いていないディスクには、そのラベルが付けられるようになりました。
今回の更新により、CephFS ネイティブドライバーは OpenStack File Share Service (manila) のコアインフラストラクチャーと共に機能が拡張されました。CephFS ネイティブドライバーは読み取り専用のファイル共有をサポートするようになりました。また、「access_list」には含まれていないバックエンドルールを削除することにより、リカバリーモードが向上されました。
今回の更新により、CephFS ネイティブドライバーは OpenStack File Share Service (manila) のコアインフラストラクチャーと共に機能が拡張されました。CephFS ネイティブドライバーは読み取り専用のファイル共有をサポートするようになりました。また、「access_list」には含まれていないバックエンドルールを削除することにより、リカバリーモードが向上されました。
nova-api ワーカーにおけるメモリーの肥大化問題を防ぐために、simple-tenant-usage API 拡張機能にページネーションロジックが追加されました。
nova-api ワーカーにおけるメモリーの肥大化問題を防ぐために、simple-tenant-usage API 拡張機能にページネーションロジックが追加されました。
今回の機能拡張では、パブリックのファイル共有の作成を Dashboard で無効にできるようになりました。
作成処理中にファイル共有をパブリックにマークするチェックボックスを表示しないように Dashboard を設定することができます。デフォルトのオプションでは、このボックスにチェックマークはなしでプライベートのファイル共有が作成されます。
今回の機能拡張では、パブリックのファイル共有の作成を Dashboard で無効にできるようになりました。
作成処理中にファイル共有をパブリックにマークするチェックボックスを表示しないように Dashboard を設定することができます。デフォルトのオプションでは、このボックスにチェックマークはなしでプライベートのファイル共有が作成されます。
今回の機能拡張により、「glance-manage db purge」は、1 日未満の行を削除できるようになりました。この機能は、オペレーターがこの操作を定期的に実行する必要があるため追加されました。
その結果、「age_in_days」のオプションを「0」に設定することができるようになりました。
今回の機能拡張により、「glance-manage db purge」は、1 日未満の行を削除できるようになりました。この機能は、オペレーターがこの操作を定期的に実行する必要があるため追加されました。
その結果、「age_in_days」のオプションを「0」に設定することができるようになりました。
今回のリリースでは、CephFS のデプロイに必要な puppet モジュールが提供されるようになりました。これにより、director で、CephFS バックエンドを使用する OpenStack Shared File Systems サービス (openstack-manila) をデプロイすることができます。
今回のリリースでは、CephFS のデプロイに必要な puppet モジュールが提供されるようになりました。これにより、director で、CephFS バックエンドを使用する OpenStack Shared File Systems サービス (openstack-manila) をデプロイすることができます。
今回の機能拡張により、Time Series Database as a Service (gnocchi) をアンダークラウドで使用できるようになりました。Gnocchi は OpenStack Telemetry 用のメトリックバックエンドを提供します。デフォルトで「enable_telemetry」フラグが「true」に設定され、有効化されています。「undercloud.conf」で「enable_telemetry=false」に設定すると、全 Telemetry サービスを無効にすることができます。
今回の機能拡張により、Time Series Database as a Service (gnocchi) をアンダークラウドで使用できるようになりました。Gnocchi は OpenStack Telemetry 用のメトリックバックエンドを提供します。デフォルトで「enable_telemetry」フラグが「true」に設定され、有効化されています。「undercloud.conf」で「enable_telemetry=false」に設定すると、全 Telemetry サービスを無効にすることができます。
今回のリリースでは、多数のインスタンスがあるシステムに対して使用状況の統計を要求してリソースが大量に消費されるのを回避するために、ページネーションのサポートが追加されました。nova API simple-tenant-usage エンドポイントの v2.40 マイクロバージョンでは、新しいオプションのクエリーパラメーター「limit」と「marker」がページネーションに使用されます。「marker」オプションは開始点を設定し、「limit」オプションは開始点よりも後に表示されるレコード数を設定します。「limit」が設定されていない場合には、nova は設定可能な「max_limit」 (デフォルト値は 1000) を使用します。古いマイクロバージョンはこれらの新しいクエリーパラメーターを受け入れませんが、max_limit の適用を開始するので、結果が切り捨てられる場合があります。DoS ライクな使用状況の統計要求を回避して、応答が切り捨てられないようにするには、新しいマイクロバージョンを使用することを検討してください。
今回のリリースでは、多数のインスタンスがあるシステムに対して使用状況の統計を要求してリソースが大量に消費されるのを回避するために、ページネーションのサポートが追加されました。nova API simple-tenant-usage エンドポイントの v2.40 マイクロバージョンでは、新しいオプションのクエリーパラメーター「limit」と「marker」がページネーションに使用されます。「marker」オプションは開始点を設定し、「limit」オプションは開始点よりも後に表示されるレコード数を設定します。「limit」が設定されていない場合には、nova は設定可能な「max_limit」 (デフォルト値は 1000) を使用します。古いマイクロバージョンはこれらの新しいクエリーパラメーターを受け入れませんが、max_limit の適用を開始するので、結果が切り捨てられる場合があります。DoS ライクな使用状況の統計要求を回避して、応答が切り捨てられないようにするには、新しいマイクロバージョンを使用することを検討してください。
今回の更新で、パブリックおよび内部のネットワークに異なるドメイン名を使用できるようになりました。ネットワークごとにドメイン名を設定するには、以下の Heat テンプレートパラメーターを使用します。

* CloudName: そのクラウドの DNS 名。例:
      'ci-overcloud.tripleo.org'
* CloudNameInternal: そのクラウドの内部 API エンドポイントの DNS 名。例:
      'ci-overcloud.internalapi.tripleo.org'
* CloudNameStorage: そのクラウドのストレージエンドポイントの DNS 名。例:
      'ci-overcloud.storage.tripleo.org'
* CloudNameStorageManagement: そのクラウドのストレージ管理エンドポイントの DNS 名。例:
      'ci-overcloud.storagemgmt.tripleo.org'
* CloudNameCtlplane: そのクラウドのコントロールプレーンエンドポイントの DNS 名。例:
      'ci-overcloud.management.tripleo.org'
今回の更新で、パブリックおよび内部のネットワークに異なるドメイン名を使用できるようになりました。ネットワークごとにドメイン名を設定するには、以下の Heat テンプレートパラメーターを使用します。

* CloudName: そのクラウドの DNS 名。例:
      'ci-overcloud.tripleo.org'
* CloudNameInternal: そのクラウドの内部 API エンドポイントの DNS 名。例:
      'ci-overcloud.internalapi.tripleo.org'
* CloudNameStorage: そのクラウドのストレージエンドポイントの DNS 名。例:
      'ci-overcloud.storage.tripleo.org'
* CloudNameStorageManagement: そのクラウドのストレージ管理エンドポイントの DNS 名。例:
      'ci-overcloud.storagemgmt.tripleo.org'
* CloudNameCtlplane: そのクラウドのコントロールプレーンエンドポイントの DNS 名。例:
      'ci-overcloud.management.tripleo.org'
今回の更新で、ユーザーインターフェースが一部国際化され、日本語と簡体字中国語で利用できるようになりました。 現段階ではインターフェース自体のみが国際化されている点に注意してください。TripleO Heat テンプレート、検証、通知用に他のサービスから提供されるパラメーター、テンプレート、環境の文字列はまだ国際化されていません。
今回の更新で、ユーザーインターフェースが一部国際化され、日本語と簡体字中国語で利用できるようになりました。 現段階ではインターフェース自体のみが国際化されている点に注意してください。TripleO Heat テンプレート、検証、通知用に他のサービスから提供されるパラメーター、テンプレート、環境の文字列はまだ国際化されていません。
最近実装された director の機能拡張には、ネットワークインターフェース設定用テンプレートを変更する必要があります。NIC 設定テンプレートは「os-net-config utility」を呼び出すスクリプトを使用してオーバークラウドノード上のネットワークを設定します。NIC 設定テンプレートには 3 つの大きな変更点があります。

* 「OsNetConfigImpl」リソースが「OS::Heat::StructuredConfig」リソースタイプから 「OS::Heat::SoftwareConfig」に変わりました。また、このリソースは「network_config」プロパティーをテキストの Blob として保管し、 「str_replace」(文字列置き換え) の関数を使用してその Blob を「run-os-net-config.sh」スクリプトに渡します。以下に例を示します。

----
resources:
  OsNetConfigImpl:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template:
            get_file: ../../scripts/run-os-net-config.sh
          params:
            $network_config:
              network_config:
----

* {get_input: <input>} コンストラクターはデフォルトの外部ブリッジとインターフェースを定義していましたが、現在はその代わりに 2 つの特別な文字列の値で外部ブリッジとインターフェースが定義されるようになりました。この値は、それぞれ「bridge_name」と「interface_name」です。「{get_input: bridge_name}」または 「{get_input: interface_name}」を使用する代わりに「bridge_name」または 「interface_name」を使用します。以下に例を示します。

----
              - type: ovs_bridge
                name: {get_input: bridge_name}
----
これは、以下のように変更されます。
----
              - type: ovs_bridge
                name: bridge_name
----

* 「network_config」には中かっこを使用しないようになりました。その代わりに {get_param: <param>} コンストラクトは定義する値の下のサブレベルに移動します。以下に例を示します。
----
                dns_servers: {get_param: DnsServers}
----
これは、以下のように変更されます。
----
                dns_servers:
                  get_param: DnsServers
----

詳しくは、『Advanced Overcloud Customizations』ガイドの「Network Isolation」の章を参照してください。
最近実装された director の機能拡張には、ネットワークインターフェース設定用テンプレートを変更する必要があります。NIC 設定テンプレートは「os-net-config utility」を呼び出すスクリプトを使用してオーバークラウドノード上のネットワークを設定します。NIC 設定テンプレートには 3 つの大きな変更点があります。

* 「OsNetConfigImpl」リソースが「OS::Heat::StructuredConfig」リソースタイプから 「OS::Heat::SoftwareConfig」に変わりました。また、このリソースは「network_config」プロパティーをテキストの Blob として保管し、 「str_replace」(文字列置き換え) の関数を使用してその Blob を「run-os-net-config.sh」スクリプトに渡します。以下に例を示します。

----
resources:
  OsNetConfigImpl:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template:
            get_file: ../../scripts/run-os-net-config.sh
          params:
            $network_config:
              network_config:
----

* {get_input: <input>} コンストラクターはデフォルトの外部ブリッジとインターフェースを定義していましたが、現在はその代わりに 2 つの特別な文字列の値で外部ブリッジとインターフェースが定義されるようになりました。この値は、それぞれ「bridge_name」と「interface_name」です。「{get_input: bridge_name}」または 「{get_input: interface_name}」を使用する代わりに「bridge_name」または 「interface_name」を使用します。以下に例を示します。

----
              - type: ovs_bridge
                name: {get_input: bridge_name}
----
これは、以下のように変更されます。
----
              - type: ovs_bridge
                name: bridge_name
----

* 「network_config」には中かっこを使用しないようになりました。その代わりに {get_param: <param>} コンストラクトは定義する値の下のサブレベルに移動します。以下に例を示します。
----
                dns_servers: {get_param: DnsServers}
----
これは、以下のように変更されます。
----
                dns_servers:
                  get_param: DnsServers
----

詳しくは、『Advanced Overcloud Customizations』ガイドの「Network Isolation」の章を参照してください。
今回の更新により、Wake-On-LAN および AMT ドライバーが Ironic から削除されました。これらのドライバーはサードパーティーの CI を提供していない、または提供する予定がないのが理由です。これらのドライバーは、ironic-staging-drivers リポジトリーにあるサポート対象外の Ironic ドライバーコレクションでまだ提供されています。Ironic のインストールがこれらをベースとするいずれかのドライバーを使用する場合には、ironic-staging-drivers をインストールし、以下の一覧に従って、影響を受けるノードでドライバーを変更する必要があります。

agent_amt -> pxe_amt_agent
pxe_amt -> pxe_amt_iscsi
agent_wol -> pxe_wol_agent
pxe_wol -> pxe_wol_iscsi
今回の更新により、Wake-On-LAN および AMT ドライバーが Ironic から削除されました。これらのドライバーはサードパーティーの CI を提供していない、または提供する予定がないのが理由です。これらのドライバーは、ironic-staging-drivers リポジトリーにあるサポート対象外の Ironic ドライバーコレクションでまだ提供されています。Ironic のインストールがこれらをベースとするいずれかのドライバーを使用する場合には、ironic-staging-drivers をインストールし、以下の一覧に従って、影響を受けるノードでドライバーを変更する必要があります。

agent_amt -> pxe_amt_agent
pxe_amt -> pxe_amt_iscsi
agent_wol -> pxe_wol_agent
pxe_wol -> pxe_wol_iscsi
DPDK を有効にしたインスタンスの起動に関する SELinux ポリシーは完全ではないため、SELinux が enforcing モードの場合には DPDK を使用するインスタンスの起動は失敗して、openvswitch および svirt に関する AVC 拒否が /var/log/audit/audit.log* に表示されます。

回避策として、 以下のリンク先のセクション 4.4.1.2 に記載されているように、DPDK を使用する各コンピュートノードで SELinux を permissive に設定します。

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-working_with_selinux-changing_selinux_modes

これにより、DPDK を有効化した仮想マシンを起動することができます。これは回避策で、この問題を詳しく調査している間の一時的な対策となる見込みです。
DPDK を有効にしたインスタンスの起動に関する SELinux ポリシーは完全ではないため、SELinux が enforcing モードの場合には DPDK を使用するインスタンスの起動は失敗して、openvswitch および svirt に関する AVC 拒否が /var/log/audit/audit.log* に表示されます。

回避策として、 以下のリンク先のセクション 4.4.1.2 に記載されているように、DPDK を使用する各コンピュートノードで SELinux を permissive に設定します。

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-working_with_selinux-changing_selinux_modes

これにより、DPDK を有効化した仮想マシンを起動することができます。これは回避策で、この問題を詳しく調査している間の一時的な対策となる見込みです。
問題の詳細:
OSP10 (OvS2.5) では、以下の問題があります。
1) tuned は誤った CPU セットで設定されています。想定されている設定は NeutronDpdkCoreList + NovaVcpuPinSet ですが、HostCpusList として設定されています。
2) post-config では、DPDK_OPTIONS の -l は 0 として設定され、NeutronDpdkdCoreList は pmd-cpu-mask として設定されます。

更新後に必要な手動の修正
1) tuned の設定ファイルに CPU の一覧が分離されるように NeutronDpdkCoreList + NovaVcpuPinSet で追加します。

TUNED_CORES="<list of CPUs"
sed -i 's/^isolated_cores=.*/isolated_cores=$TUNED_CORES/' $tuned_conf_path
tuned-adm profile cpu-partitioning

2) 更新後に lcore マスクは 0 に設定されます。first-boot スクリプトの get_mask コードで CPU マスクを取得します。
LCORE_MASK="<mask value output of get_mask"
ovs-vsctl --no-wait set Open_vSwitch . other-config:dpdk-lcore-mask=$LCORE_MASK
問題の詳細:
OSP10 (OvS2.5) では、以下の問題があります。
1) tuned は誤った CPU セットで設定されています。想定されている設定は NeutronDpdkCoreList + NovaVcpuPinSet ですが、HostCpusList として設定されています。
2) post-config では、DPDK_OPTIONS の -l は 0 として設定され、NeutronDpdkdCoreList は pmd-cpu-mask として設定されます。

更新後に必要な手動の修正
1) tuned の設定ファイルに CPU の一覧が分離されるように NeutronDpdkCoreList + NovaVcpuPinSet で追加します。

TUNED_CORES="<list of CPUs"
sed -i 's/^isolated_cores=.*/isolated_cores=$TUNED_CORES/' $tuned_conf_path
tuned-adm profile cpu-partitioning

2) 更新後に lcore マスクは 0 に設定されます。first-boot スクリプトの get_mask コードで CPU マスクを取得します。
LCORE_MASK="<mask value output of get_mask"
ovs-vsctl --no-wait set Open_vSwitch . other-config:dpdk-lcore-mask=$LCORE_MASK
セキュリティー上の理由により、オーバークラウドではデフォルトで 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 にイメージをアップロードする前に実行してください。
セキュリティー上の理由により、オーバークラウドではデフォルトで 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 にイメージをアップロードする前に実行してください。
番号付きの NIC の抽象化 (nic1、nic2 など) に数えられるのは、スイッチポートへの有効な接続がある NIC のみです。回避策として、director には各ノードから全インターフェース上の最初のコントローラーを ping するスクリプトが含まれています。デプロイメント時に接続されていないリンクがあるノードの場合には検出されるので、修正することが可能です。もうひとつの可能な回避策としては、各ホストに NIC 番号から物理 NIC へのマッピングが記載されたマッピングファイルを使用する方法です。1 つまたは複数のオーバークラウドノードで　リンクが停止しているため正しく設定を行わない場合には、検出されるようになり、オーバークラウドは再度デプロイすることが可能です。
番号付きの NIC の抽象化 (nic1、nic2 など) に数えられるのは、スイッチポートへの有効な接続がある NIC のみです。回避策として、director には各ノードから全インターフェース上の最初のコントローラーを ping するスクリプトが含まれています。デプロイメント時に接続されていないリンクがあるノードの場合には検出されるので、修正することが可能です。もうひとつの可能な回避策としては、各ホストに NIC 番号から物理 NIC へのマッピングが記載されたマッピングファイルを使用する方法です。1 つまたは複数のオーバークラウドノードで　リンクが停止しているため正しく設定を行わない場合には、検出されるようになり、オーバークラウドは再度デプロイすることが可能です。
1 つのノードで複数のネットワークインターフェースがプロビジョニングネットワークに接続されると、検出が失敗します。プロビジョニングネットワークには、1 つのインターフェースしか接続することはできません。このインターフェースはボンディングには使用できません。
1 つのノードで複数のネットワークインターフェースがプロビジョニングネットワークに接続されると、検出が失敗します。プロビジョニングネットワークには、1 つのインターフェースしか接続することはできません。このインターフェースはボンディングには使用できません。
フェンシングデバイスとホストデバイスの名前が同じ場合には、Pacemaker は連続的にクラッシュします。この問題を回避するには、「fence-」のプレフィックスをフェンシングデバイスに追加してください。名前をこのように設定した場合には、クラスターはエラーなしで機能します。
フェンシングデバイスとホストデバイスの名前が同じ場合には、Pacemaker は連続的にクラッシュします。この問題を回避するには、「fence-」のプレフィックスをフェンシングデバイスに追加してください。名前をこのように設定した場合には、クラスターはエラーなしで機能します。
ノードのデプロイ中に「openstack stack delete」コマンドを入力すると、デプロイ中の状態のままとなって削除できなくなる可能性があります。そのような状態になると、その領域は削除されていないノードによってブロックされるので、新規ノードをデプロイすることができなくなります。このような状況を回避するには、全ノードが完全にデプロイされるまで待ってから「openstack stack delete」コマンドを入力してください。また、「nova delete <node>」コマンドでノードを手動で削除することができます。
ノードのデプロイ中に「openstack stack delete」コマンドを入力すると、デプロイ中の状態のままとなって削除できなくなる可能性があります。そのような状態になると、その領域は削除されていないノードによってブロックされるので、新規ノードをデプロイすることができなくなります。このような状況を回避するには、全ノードが完全にデプロイされるまで待ってから「openstack stack delete」コマンドを入力してください。また、「nova delete <node>」コマンドでノードを手動で削除することができます。
「openstack overcloud stack update」コマンドの起動には時間かかります。このコマンドが機能していることが分かるまでに数分かかる場合があります。これは正常な動作です。
「openstack overcloud stack update」コマンドの起動には時間かかります。このコマンドが機能していることが分かるまでに数分かかる場合があります。これは正常な動作です。
neutron-openvswitch-agent でセキュリティーグループのトランク機能を実装するには、openvswitch のファイアウォールドライバーが必要です。このドライバーには現在 BZ# 1444368 のバグがあり、同じコンピュートノード上にある異なるネットワークセグメントで同じ MAC アドレスのポートが 2 つある場合には、受信トラフィックが間違って照合されます。

このため、サブポートが親ポートと同じ MAC アドレスの場合には、受信トラフィックは一方のポートには正しく照合されません。

トラフィックを正しく処理するための回避策として、親ポートとサブポートでポートセキュリティーを無効にします。

たとえば、UUID 12345 のポートのポートセキュリティーを無効にするには、そのポートに関連付けられたセキュリティーグループを削除する必要があります。
 openstack port set --no-security-group --disable-port-security 12345

そのポートにはセキュリティーグループのルールは一切適用されず、トラフィックのフィルタリングおよび ip/mac/arp スプーフィングに対する保護は適用されない点に注意してください。
neutron-openvswitch-agent でセキュリティーグループのトランク機能を実装するには、openvswitch のファイアウォールドライバーが必要です。このドライバーには現在 BZ# 1444368 のバグがあり、同じコンピュートノード上にある異なるネットワークセグメントで同じ MAC アドレスのポートが 2 つある場合には、受信トラフィックが間違って照合されます。

このため、サブポートが親ポートと同じ MAC アドレスの場合には、受信トラフィックは一方のポートには正しく照合されません。

トラフィックを正しく処理するための回避策として、親ポートとサブポートでポートセキュリティーを無効にします。

たとえば、UUID 12345 のポートのポートセキュリティーを無効にするには、そのポートに関連付けられたセキュリティーグループを削除する必要があります。
 openstack port set --no-security-group --disable-port-security 12345

そのポートにはセキュリティーグループのルールは一切適用されず、トラフィックのフィルタリングおよび ip/mac/arp スプーフィングに対する保護は適用されない点に注意してください。
Puppet と MongoDB サービスの間で競合状態が発生する場合があります。その結果、MongoDB データベースを実行しているノードのスケールアウトは失敗し、オーバークラウドスタックは更新されません。同じデプロイメントコマンドを再度実行すると、MongoDB ノードは正常にスケールアウトされます。
Puppet と MongoDB サービスの間で競合状態が発生する場合があります。その結果、MongoDB データベースを実行しているノードのスケールアウトは失敗し、オーバークラウドスタックは更新されません。同じデプロイメントコマンドを再度実行すると、MongoDB ノードは正常にスケールアウトされます。
現在、Red Hat OpenStack Platform director 10 で SRIOV を有効にしている場合には、compute.yaml file で NIC ID (例: nic1、nic2、nic3 など) を使用するとオーバークラウドデプロイメントが失敗します。

デプロイメントが正常に完了するようにするには、回避策として、NIC ID の代わりに NIC の名前 (例: ens1f0、ens1f1、ens2f0 など) を使用する必要があります。
現在、Red Hat OpenStack Platform director 10 で SRIOV を有効にしている場合には、compute.yaml file で NIC ID (例: nic1、nic2、nic3 など) を使用するとオーバークラウドデプロイメントが失敗します。

デプロイメントが正常に完了するようにするには、回避策として、NIC ID の代わりに NIC の名前 (例: ens1f0、ens1f1、ens2f0 など) を使用する必要があります。
OVS のアップグレードやネットワークサービスの再起動などの特定の状況では、OVS ブリッジが解除され、再構築されていました。そのような状態になると、既存のネットワークフローが中断され、ネットワークトラフィックはフローが再構築されるまで転送を停止していました。複雑なデプロイメントの場合には、多少時間がかかる可能性がありました。

ダウンタイムが発生しないようにするには、コントロールプレーンのネットワークを OVS ブリッジ上に配置すべきではありません。その代わりに、コントロールプレーン (プロビジョニング)、内部 API、およびストレージ管理のネットワークは、ブリッジ上にはない専用のインターフェースまたは VLAN インターフェースに配置すべきです。たとえば、1 つのインターフェースまたはボンディングにはコントロールプレーンの VLAN を割り当てる一方で、もう 1 つのインターフェースまたはボンディングはテナントネットワークデータ用の OVS ブリッジ上に配置することができます。

コントロールプレーンのインターフェースが OVS ブリッジ上にない限りは、ネットワークのダウンタイムはテナントデータプレーンに限定されることになります。
OVS のアップグレードやネットワークサービスの再起動などの特定の状況では、OVS ブリッジが解除され、再構築されていました。そのような状態になると、既存のネットワークフローが中断され、ネットワークトラフィックはフローが再構築されるまで転送を停止していました。複雑なデプロイメントの場合には、多少時間がかかる可能性がありました。

ダウンタイムが発生しないようにするには、コントロールプレーンのネットワークを OVS ブリッジ上に配置すべきではありません。その代わりに、コントロールプレーン (プロビジョニング)、内部 API、およびストレージ管理のネットワークは、ブリッジ上にはない専用のインターフェースまたは VLAN インターフェースに配置すべきです。たとえば、1 つのインターフェースまたはボンディングにはコントロールプレーンの VLAN を割り当てる一方で、もう 1 つのインターフェースまたはボンディングはテナントネットワークデータ用の OVS ブリッジ上に配置することができます。

コントロールプレーンのインターフェースが OVS ブリッジ上にない限りは、ネットワークのダウンタイムはテナントデータプレーンに限定されることになります。
CLI と UI では、パラメーター、環境、およびテンプレートの処理が若干異なります。
そのため、UI で自動生成されたパスワードは、テンプレートからは変更できません。カスタムのパスワードを使用するには、デプロイメント全体の設定のパラメーターとして UI で手動で設定するか、ロールカードで編集する必要があります。
別の方法としては、「$ openstack overcloud plan create <my_plan> --disable-password-generation」のコマンドを CLI に入力してパスワードの自動生成なしでプランを作成することができます。パスワードはテンプレートを使用して明示的に指定するか、UI で手動で設定する必要があります。
CLI と UI では、パラメーター、環境、およびテンプレートの処理が若干異なります。
そのため、UI で自動生成されたパスワードは、テンプレートからは変更できません。カスタムのパスワードを使用するには、デプロイメント全体の設定のパラメーターとして UI で手動で設定するか、ロールカードで編集する必要があります。
別の方法としては、「$ openstack overcloud plan create <my_plan> --disable-password-generation」のコマンドを CLI に入力してパスワードの自動生成なしでプランを作成することができます。パスワードはテンプレートを使用して明示的に指定するか、UI で手動で設定する必要があります。
「openstack overcloud deploy」コマンドを実行すると、デフォルトの「overcloud」プランが置き換えられます。ユーザーがオーバークラウドを CLI で作成し、それを削除してから新しいオーバークラウドを Web UI で作成する場合には、Web UI は CLI デプロイメントからの「overcloud」プランを使用します。このため、Web UI により、以前のオーバークラウドデプロイメントから不要なパラメーターが追加されてしまいます。この問題は、以下の方法で回避します。

1. オーバークラウドの新規作成時には、「user-environment.yaml」環境ファイルが無効であることを確認します。
2. プランの新しいバージョンを (「/usr/share/openstack-tripleo-heat-template」から) アップロードします。
「openstack overcloud deploy」コマンドを実行すると、デフォルトの「overcloud」プランが置き換えられます。ユーザーがオーバークラウドを CLI で作成し、それを削除してから新しいオーバークラウドを Web UI で作成する場合には、Web UI は CLI デプロイメントからの「overcloud」プランを使用します。このため、Web UI により、以前のオーバークラウドデプロイメントから不要なパラメーターが追加されてしまいます。この問題は、以下の方法で回避します。

1. オーバークラウドの新規作成時には、「user-environment.yaml」環境ファイルが無効であることを確認します。
2. プランの新しいバージョンを (「/usr/share/openstack-tripleo-heat-template」から) アップロードします。
director では、イントロスペクションを実行する前にノードが管理されている状態である必要があります。新規登録されたノードは、director の Web UI で「manageable」に設定されますが、ユーザーがイントロスペクションを後日に実行する必要がある場合にノードを「manageable」に切り替えるためのオプションは現在のところありません。回避策としては、「openstack baremetal node manage」コマンドでノードを「manageable」状態に戻す方法があります。
director では、イントロスペクションを実行する前にノードが管理されている状態である必要があります。新規登録されたノードは、director の Web UI で「manageable」に設定されますが、ユーザーがイントロスペクションを後日に実行する必要がある場合にノードを「manageable」に切り替えるためのオプションは現在のところありません。回避策としては、「openstack baremetal node manage」コマンドでノードを「manageable」状態に戻す方法があります。
無効なキャッシュファイルが原因で、os-collect-config が「ValueError: No JSON object could be decoded」のエラーを報告して、サービスの起動が失敗する場合があります。「/var/lib/os-collect-config/」にあるキャッシュファイルは、有効な json ファイルである必要があります。サイズが 0 の場合や、無効な json が含まれている場合には、その無効なファイルを「/var/lib/os-collect-config」から削除しないと、os-collect-config は起動しなくなる可能性があります。
無効なキャッシュファイルが原因で、os-collect-config が「ValueError: No JSON object could be decoded」のエラーを報告して、サービスの起動が失敗する場合があります。「/var/lib/os-collect-config/」にあるキャッシュファイルは、有効な json ファイルである必要があります。サイズが 0 の場合や、無効な json が含まれている場合には、その無効なファイルを「/var/lib/os-collect-config」から削除しないと、os-collect-config は起動しなくなる可能性があります。
Red Hat OpenStack Platform のバージョン 9 から 10 にアップグレードしたお客様は、Red Hat OpenStack Platform 11 へのアップグレードは、この既知の問題が修正される予定の最初の非同期リリースまでお待ちください。最初の非同期リリースは通常、一般出荷版リリースの数日以内に提供されます。
Red Hat OpenStack Platform のバージョン 9 から 10 にアップグレードしたお客様は、Red Hat OpenStack Platform 11 へのアップグレードは、この既知の問題が修正される予定の最初の非同期リリースまでお待ちください。最初の非同期リリースは通常、一般出荷版リリースの数日以内に提供されます。
高可用性の IPv6 デプロイメントでは、アップグレード中に RabbitMQ に使用される仮想 IP コントローラーホスト間で移動する場合があります。IPv6 IP の作成のバグが原因で、それらのアドレスは RabbitMQ 接続のソースアドレスとして使用されます。その結果、RabbitMQ はクラッシュしてクラスターを自動的に回復することはできません。

通常の状態に戻すには、対象のコントローラーホスト上の RabbitMQ と、RabbitMQ に依存する、自動的に再接続されないサービスを再起動してください。
高可用性の IPv6 デプロイメントでは、アップグレード中に RabbitMQ に使用される仮想 IP コントローラーホスト間で移動する場合があります。IPv6 IP の作成のバグが原因で、それらのアドレスは RabbitMQ 接続のソースアドレスとして使用されます。その結果、RabbitMQ はクラッシュしてクラスターを自動的に回復することはできません。

通常の状態に戻すには、対象のコントローラーホスト上の RabbitMQ と、RabbitMQ に依存する、自動的に再接続されないサービスを再起動してください。
Red Hat OpenStack Platform のバージョン 9 から 10 にアップグレードしたお客様は、Red Hat OpenStack Platform 11 へのアップグレードは、この既知の問題が修正される予定の最初の非同期リリースまでお待ちください。最初の非同期リリースは通常、一般出荷版リリースの数日以内に提供されます。
Red Hat OpenStack Platform のバージョン 9 から 10 にアップグレードしたお客様は、Red Hat OpenStack Platform 11 へのアップグレードは、この既知の問題が修正される予定の最初の非同期リリースまでお待ちください。最初の非同期リリースは通常、一般出荷版リリースの数日以内に提供されます。
Red Hat OpenStack Platform director が TripleO を使用して libvirtd ベースのライブマイグレーションを有効にする機能に、設計上の不備による問題が見つかりました。TripleO はセキュアなライブマイグレーションをサポートしていないため、director によって libvirtd デプロイメントをロックダウンする追加のステップが実行されませんでした。libvirtd はデフォルトで (director により) デプロイされ、認証または暗号化なしで 0.0.0.0 (全インターフェース) 上でリッスンします。127.0.0.1、その他のループバックインターフェースアドレス、また場合によっては管理インターフェースの外部に公開されている可能性のあるアドレスを含む、任意のコンピュートホストの IP アドレスに TCP 接続ができる人は誰でも、この機能を使用して libvirtd インスタンスに対する virsh セッションを開いて仮想マシンインスタンスを制御したり、場合によってはホストを乗っ取ったりすることも可能でした。

他に不備がなければ、テナントネットワークまたは外部ネットワークからアクセスできないはずである点に注意してください。

Red Hat OpenStack Platform 10 から Red Hat OpenStack Platform 11 にアップグレードする場合には、最初にこの問題を解決するための適切な更新を適用する必要があります。

Red Hat OpenStack Platform 11 には、一般出荷の時点でこの更新が同梱されており、追加の更新は必要ありません。

この問題に関する詳しい情報と、それに対応する解決方法は、 https://access.redhat.com/solutions/3022771 を参照してください。
Red Hat OpenStack Platform director が TripleO を使用して libvirtd ベースのライブマイグレーションを有効にする機能に、設計上の不備による問題が見つかりました。TripleO はセキュアなライブマイグレーションをサポートしていないため、director によって libvirtd デプロイメントをロックダウンする追加のステップが実行されませんでした。libvirtd はデフォルトで (director により) デプロイされ、認証または暗号化なしで 0.0.0.0 (全インターフェース) 上でリッスンします。127.0.0.1、その他のループバックインターフェースアドレス、また場合によっては管理インターフェースの外部に公開されている可能性のあるアドレスを含む、任意のコンピュートホストの IP アドレスに TCP 接続ができる人は誰でも、この機能を使用して libvirtd インスタンスに対する virsh セッションを開いて仮想マシンインスタンスを制御したり、場合によってはホストを乗っ取ったりすることも可能でした。

他に不備がなければ、テナントネットワークまたは外部ネットワークからアクセスできないはずである点に注意してください。

Red Hat OpenStack Platform 10 から Red Hat OpenStack Platform 11 にアップグレードする場合には、最初にこの問題を解決するための適切な更新を適用する必要があります。

Red Hat OpenStack Platform 11 には、一般出荷の時点でこの更新が同梱されており、追加の更新は必要ありません。

この問題に関する詳しい情報と、それに対応する解決方法は、 https://access.redhat.com/solutions/3022771 を参照してください。
OpenStack Platform 10 でスタンドアロンの Keystone ノードを使用する場合には、「openstack-gnocchi-statsd」が正常に起動しません。これは、「gnocchi」と「keystone」サービスが同じステップでアクティブ化されることが原因で、そのために競合状態が発生します。「gnocchi」は認証に失敗しますが、再試行しません。この問題は BZ#1447422 で対処されました。

スタンドアロンの Keystone ロールを使用している場合には、「openstack-gnocchi-statsd」サービスが起動に失敗すると OpenStack Platform 11 のアップグレードの事前チェックが失敗するので、OpenStack Platform 10 から 11 へのアップグレードも失敗することになります。回避策として、アップグレードのステップを開始する前にオーバークラウド上で「openstack-gnocchi-statsd」サービスを再起動する方法があります。これにより、サービスが正しく有効化され、アップグレードが成功します。これは、スタンドアロンの Keystone ノードを使用している OpenStack Platform 10 にのみが対象で、他のアップグレードシナリオには影響はありません。
OpenStack Platform 10 でスタンドアロンの Keystone ノードを使用する場合には、「openstack-gnocchi-statsd」が正常に起動しません。これは、「gnocchi」と「keystone」サービスが同じステップでアクティブ化されることが原因で、そのために競合状態が発生します。「gnocchi」は認証に失敗しますが、再試行しません。この問題は BZ#1447422 で対処されました。

スタンドアロンの Keystone ロールを使用している場合には、「openstack-gnocchi-statsd」サービスが起動に失敗すると OpenStack Platform 11 のアップグレードの事前チェックが失敗するので、OpenStack Platform 10 から 11 へのアップグレードも失敗することになります。回避策として、アップグレードのステップを開始する前にオーバークラウド上で「openstack-gnocchi-statsd」サービスを再起動する方法があります。これにより、サービスが正しく有効化され、アップグレードが成功します。これは、スタンドアロンの Keystone ノードを使用している OpenStack Platform 10 にのみが対象で、他のアップグレードシナリオには影響はありません。
Red Hat Ceph Storage を Block Storage (cinder) ボリュームとバックアップの両方のバックエンドとして使用する場合には、増分バックアップを試みると、代わりに完全なバックアップが実行され、警告は表示されません。
Red Hat Ceph Storage を Block Storage (cinder) ボリュームとバックアップの両方のバックエンドとして使用する場合には、増分バックアップを試みると、代わりに完全なバックアップが実行され、警告は表示されません。
「python-requests」を使用する OpenStack のコマンドラインクライアントは、現在、IP アドレスが SAN フィールドに記載されている証明書は検証できません。
「python-requests」を使用する OpenStack のコマンドラインクライアントは、現在、IP アドレスが SAN フィールドに記載されている証明書は検証できません。
image_path パラメーターは使用されなくなりました。今回の更新で、このパラメーターはアンダークラウドの設定ファイルから削除されました。
image_path パラメーターは使用されなくなりました。今回の更新で、このパラメーターはアンダークラウドの設定ファイルから削除されました。
VPNaaS 機能は Red Hat OpenStack Platform 11 では非推奨となり、Red Hat OpenStack Platform 12 では削除される予定です。
VPNaaS 機能は Red Hat OpenStack Platform 11 では非推奨となり、Red Hat OpenStack Platform 12 では削除される予定です。
Red Hat OpenStack Platform 11 では、Neutron の Linux Bridge ML2 ドライバーおよびエージェントは非推奨となり、Red Hat OpenStack Platform 12 では削除される予定です。OpenStack Platform director によってデフォルトでデプロイされるのは、Open vSwitch (OVS) のプラグインです。一般的な用途の場合には、Red Hat はこのプラグインを推奨しています。
Red Hat OpenStack Platform 11 では、Neutron の Linux Bridge ML2 ドライバーおよびエージェントは非推奨となり、Red Hat OpenStack Platform 12 では削除される予定です。OpenStack Platform director によってデフォルトでデプロイされるのは、Open vSwitch (OVS) のプラグインです。一般的な用途の場合には、Red Hat はこのプラグインを推奨しています。
Red Hat OpenStack Platform 11 では Ceilometer API サービスが非推奨になり、Gnocchi、Aodh、および Panko API に置き換えられます。Ceilometer API の代わりに、サービス API に移行することをお勧めします。Red Hat OpenStack Platform 11 では、Ceilometer API はデフォルトでインストール/設定されます。今後のリリースでは、この API はデフォルトで無効となり、必要に応じてのみ有効にできるオプションが提供されることになります。
Red Hat OpenStack Platform 11 では Ceilometer API サービスが非推奨になり、Gnocchi、Aodh、および Panko API に置き換えられます。Ceilometer API の代わりに、サービス API に移行することをお勧めします。Red Hat OpenStack Platform 11 では、Ceilometer API はデフォルトでインストール/設定されます。今後のリリースでは、この API はデフォルトで無効となり、必要に応じてのみ有効にできるオプションが提供されることになります。
本リリースの時点で、Glance API V1 はサポートされなくなり利用できなくなりました。
本リリースの時点で、Glance API V1 はサポートされなくなり利用できなくなりました。
今回の更新で、Dashboard にユーザーの詳細情報のページが新たに追加され、アクションログのユーザー ID をクリックするとそのユーザーの詳細情報のページを開くことができるようになりました。
今回の更新で、Dashboard にユーザーの詳細情報のページが新たに追加され、アクションログのユーザー ID をクリックするとそのユーザーの詳細情報のページを開くことができるようになりました。
今回の更新で、Dashboard にユーザーの詳細情報のページが新たに追加され、アクションログのユーザー ID をクリックするとそのユーザーの詳細情報のページを開くことができるようになりました。
今回の更新で、Dashboard にユーザーの詳細情報のページが新たに追加され、アクションログのユーザー ID をクリックするとそのユーザーの詳細情報のページを開くことができるようになりました。
今回の機能拡張で、Red Hat OpenStack Platform director を通じた OpenStack Load Balancing as a Service (octavia) の構成が提供されています。
今回の機能拡張で、Red Hat OpenStack Platform director を通じた OpenStack Load Balancing as a Service (octavia) の構成が提供されています。
大量のメモリー消費が確認され (特に、大規模な環境において)、メモリー不足の問題を招いていました。主な原因は、仮想マシンから Nova へのメタデータリクエストをプロキシー処理する neutron-ns-metadata-proxy プロセスでした。

neutron-ns-metadata-proxy は、メモリーフットプリントがより小さい haproxy に置き換えられています。
大量のメモリー消費が確認され (特に、大規模な環境において)、メモリー不足の問題を招いていました。主な原因は、仮想マシンから Nova へのメタデータリクエストをプロキシー処理する neutron-ns-metadata-proxy プロセスでした。

neutron-ns-metadata-proxy は、メモリーフットプリントがより小さい haproxy に置き換えられています。
OS::Nova::ServerGroup リソースで、「affinity」および「anti-affinity」ポリシーに加えて、「soft-affinity」および「soft-anti-affinity」ポリシーを使用できるようになりました。
OS::Nova::ServerGroup リソースで、「affinity」および「anti-affinity」ポリシーに加えて、「soft-affinity」および「soft-anti-affinity」ポリシーを使用できるようになりました。
同じ環境で SR-IOV Physical Function (PF) と Virtual Functionand (VF) を使用するには、compute.yaml heat テンプレートの SR-IOV PF 設定に「nm_controlled」および「hotplug」パラメーターを追加します。

 -type: interface
  name: nic6
  use_dhcp: false
  nm_controlled: true
  hotplug: true

直接 Physical Function を使用していた OpenStack インスタンスが破棄されると、PCI デバイスは開放されて OpenStack およびホストシステムに戻されます。続いて、ルート PCI デバイスは、デプロイメント時に定義された Virtual Function 数をサポートするように設定されます。このプロセスはホストオペレーティングシステム、NetworkManager、および OpenStack の協調により実施され、Virtual Function を利用できるまでに若干の遅れが生じる場合があります。
同じ環境で SR-IOV Physical Function (PF) と Virtual Functionand (VF) を使用するには、compute.yaml heat テンプレートの SR-IOV PF 設定に「nm_controlled」および「hotplug」パラメーターを追加します。

 -type: interface
  name: nic6
  use_dhcp: false
  nm_controlled: true
  hotplug: true

直接 Physical Function を使用していた OpenStack インスタンスが破棄されると、PCI デバイスは開放されて OpenStack およびホストシステムに戻されます。続いて、ルート PCI デバイスは、デプロイメント時に定義された Virtual Function 数をサポートするように設定されます。このプロセスはホストオペレーティングシステム、NetworkManager、および OpenStack の協調により実施され、Virtual Function を利用できるまでに若干の遅れが生じる場合があります。
Red Hat OpenStack Platform 11 に同梱される各サービスの API ワーカー数は、以前のバージョンより非常に少なくなっています。ワーカー数が少ないことでノイズは低減されますが、API のレスポンス時間のパフォーマンスも低下します。
Red Hat OpenStack Platform 11 に同梱される各サービスの API ワーカー数は、以前のバージョンより非常に少なくなっています。ワーカー数が少ないことでノイズは低減されますが、API のレスポンス時間のパフォーマンスも低下します。
無効なキャッシュファイルが原因で、os-collect-config が「ValueError: No JSON object could be decoded」のエラーを報告して、サービスの起動が失敗する場合があります。「/var/lib/os-collect-config/」にあるキャッシュファイルは、有効な json ファイルである必要があります。サイズが 0 の場合や、無効な json が含まれている場合には、その無効なファイルを「/var/lib/os-collect-config」から削除しないと、os-collect-config は起動しなくなる可能性があります。
無効なキャッシュファイルが原因で、os-collect-config が「ValueError: No JSON object could be decoded」のエラーを報告して、サービスの起動が失敗する場合があります。「/var/lib/os-collect-config/」にあるキャッシュファイルは、有効な json ファイルである必要があります。サイズが 0 の場合や、無効な json が含まれている場合には、その無効なファイルを「/var/lib/os-collect-config」から削除しないと、os-collect-config は起動しなくなる可能性があります。
高可用性の IPv6 デプロイメントでは、アップグレード中に RabbitMQ に使用される仮想 IP コントローラーホスト間で移動する場合があります。IPv6 IP の作成のバグが原因で、それらのアドレスは RabbitMQ 接続のソースアドレスとして使用されます。その結果、RabbitMQ はクラッシュしてクラスターを自動的に回復することはできません。

通常の状態に戻すには、対象のコントローラーホスト上の RabbitMQ と、RabbitMQ に依存する、自動的に再接続されないサービスを再起動してください。
高可用性の IPv6 デプロイメントでは、アップグレード中に RabbitMQ に使用される仮想 IP コントローラーホスト間で移動する場合があります。IPv6 IP の作成のバグが原因で、それらのアドレスは RabbitMQ 接続のソースアドレスとして使用されます。その結果、RabbitMQ はクラッシュしてクラスターを自動的に回復することはできません。

通常の状態に戻すには、対象のコントローラーホスト上の RabbitMQ と、RabbitMQ に依存する、自動的に再接続されないサービスを再起動してください。
データベースアップグレードの問題により、OpenStack Networking (neutron) のアップグレードが妨げられていました。そのため、OpenStack Platform 10 から 11 にアップグレードすることができませんでした。この修正により、neutron データベースアップグレードの問題が是正されています。

この問題は、過去に OpenStack Platform 9 から 10 にアップグレードし、今回 OpenStack Platform 11 へのアップグレードを希望するお客様に影響します。
データベースアップグレードの問題により、OpenStack Networking (neutron) のアップグレードが妨げられていました。そのため、OpenStack Platform 10 から 11 にアップグレードすることができませんでした。この修正により、neutron データベースアップグレードの問題が是正されています。

この問題は、過去に OpenStack Platform 9 から 10 にアップグレードし、今回 OpenStack Platform 11 へのアップグレードを希望するお客様に影響します。
OpenStack Compute (nova) では、RabbitMQ のバージョン管理通知とバージョン非管理通知の両方が提供されます。しかし、バージョン管理通知のコンシューマーが少ないため、バージョン管理通知のキューが短時間に増大することが原因で RabbitMQ に異常が発生します。このため、インスタンスの作成やフレーバーの作成などの Compute 操作が妨げられます。現在 Red Hat では、以下のように RabbitMQ および director に対する修正を実装中です。

https://bugzilla.redhat.com/show_bug.cgi?id=1478274
https://bugzilla.redhat.com/show_bug.cgi?id=1488499

Red Hat からこの問題に対するパッチがリリースされるまでは、以下のアーティクルに記載する回避策を確認してください。

https://access.redhat.com/solutions/3139721
OpenStack Compute (nova) では、RabbitMQ のバージョン管理通知とバージョン非管理通知の両方が提供されます。しかし、バージョン管理通知のコンシューマーが少ないため、バージョン管理通知のキューが短時間に増大することが原因で RabbitMQ に異常が発生します。このため、インスタンスの作成やフレーバーの作成などの Compute 操作が妨げられます。現在 Red Hat では、以下のように RabbitMQ および director に対する修正を実装中です。

https://bugzilla.redhat.com/show_bug.cgi?id=1478274
https://bugzilla.redhat.com/show_bug.cgi?id=1488499

Red Hat からこの問題に対するパッチがリリースされるまでは、以下のアーティクルに記載する回避策を確認してください。

https://access.redhat.com/solutions/3139721
Red Hat Ceph Storage を Block Storage (cinder) ボリュームとバックアップの両方のバックエンドとして使用する場合には、増分バックアップを試みると、代わりに完全なバックアップが実行され、警告は表示されません。
Red Hat Ceph Storage を Block Storage (cinder) ボリュームとバックアップの両方のバックエンドとして使用する場合には、増分バックアップを試みると、代わりに完全なバックアップが実行され、警告は表示されません。
従来、Red Hat OpenStack Platform 11 のデプロイメント中に、ceilometer-upgrade が Apache の再起動 (同じステップで設定中の他のサービスによる) と同時に実行される、という競合状態が発生していました。その結果、ceilometer-upgrade は Identity サービスで認証することができないためエラーが発生し、一方 Apache はアクティブな状態にならないため、デプロイメントは失敗して中止されました。

今回の更新では、回避策として、この問題が発生した場合、オーバークラウドのデプロイに失敗した時点からデプロイを再開する必要があります。これにより、デプロイはこの競合状態を解消し、通常どおりデプロイメントが進行するはずです。その結果、デプロイメントはエラーで失敗せずに成功するはずです。
従来、Red Hat OpenStack Platform 11 のデプロイメント中に、ceilometer-upgrade が Apache の再起動 (同じステップで設定中の他のサービスによる) と同時に実行される、という競合状態が発生していました。その結果、ceilometer-upgrade は Identity サービスで認証することができないためエラーが発生し、一方 Apache はアクティブな状態にならないため、デプロイメントは失敗して中止されました。

今回の更新では、回避策として、この問題が発生した場合、オーバークラウドのデプロイに失敗した時点からデプロイを再開する必要があります。これにより、デプロイはこの競合状態を解消し、通常どおりデプロイメントが進行するはずです。その結果、デプロイメントはエラーで失敗せずに成功するはずです。
RHEL オーバークラウドイメージには、tuned バージョン 2.8 が含まれます。
OVS-DPDK および SR-IOV のデプロイメントでは、初回ブートのメカニズムを通じて tuned のインストールおよびアクティベーションが行われます。

https://bugzilla.redhat.com/show_bug.cgi?id=1488369#c1 で説明するように、このインストールおよびアクティベーションが失敗します。

tuned プロファイルを強制的に適用するために、コンピュートノードをリブートする必要があります。
RHEL オーバークラウドイメージには、tuned バージョン 2.8 が含まれます。
OVS-DPDK および SR-IOV のデプロイメントでは、初回ブートのメカニズムを通じて tuned のインストールおよびアクティベーションが行われます。

https://bugzilla.redhat.com/show_bug.cgi?id=1488369#c1 で説明するように、このインストールおよびアクティベーションが失敗します。

tuned プロファイルを強制的に適用するために、コンピュートノードをリブートする必要があります。
本リリースの時点で、Glance API V1 はサポートされなくなり利用できなくなりました。
本リリースの時点で、Glance API V1 はサポートされなくなり利用できなくなりました。
undercloud.conf の store_events オプションは非推奨になり、サポートされなくなりました。このオプションは設定から削除されています。
undercloud.conf の store_events オプションは非推奨になり、サポートされなくなりました。このオプションは設定から削除されています。
アンダークラウドスタックの rc ファイルは、Keystone v2 rc です。以前のリリースでは、v3 rc ファイル (v3 overcloudrc など) から切り替えた場合に、一部の v3 環境変数が残っていました。そのため、Keystone の認証が正しく機能しない場合がありました。

今回のリリースでは、OpenStack に関連した環境変数はすべて、アンダークラウドの値が設定される前に消去されるようになりました。その結果、stackrc を読み込んだ後に、以前の rc ファイルからの変数は環境には残らなくなり、Keystone の認証が正しく機能するようになりました。
アンダークラウドスタックの rc ファイルは、Keystone v2 rc です。以前のリリースでは、v3 rc ファイル (v3 overcloudrc など) から切り替えた場合に、一部の v3 環境変数が残っていました。そのため、Keystone の認証が正しく機能しない場合がありました。

今回のリリースでは、OpenStack に関連した環境変数はすべて、アンダークラウドの値が設定される前に消去されるようになりました。その結果、stackrc を読み込んだ後に、以前の rc ファイルからの変数は環境には残らなくなり、Keystone の認証が正しく機能するようになりました。
image_path パラメーターは使用されなくなりました。今回の更新で、このパラメーターはアンダークラウドの設定ファイルから削除されました。
image_path パラメーターは使用されなくなりました。今回の更新で、このパラメーターはアンダークラウドの設定ファイルから削除されました。
特定の状況では、検証ロジックのエラーが原因で、アンダークラウドの仮想 IP が正しく検証されませんでした。このため、アンダークラウドは誤った仮想 IP でデプロイされる可能性がありました。このエラーは修正され、仮想 IP は正しく検証されるようになりました。仮想 IP の設定に何らかの問題がある場合には、実際にデプロイメントが実行される前に検出されます。
特定の状況では、検証ロジックのエラーが原因で、アンダークラウドの仮想 IP が正しく検証されませんでした。このため、アンダークラウドは誤った仮想 IP でデプロイされる可能性がありました。このエラーは修正され、仮想 IP は正しく検証されるようになりました。仮想 IP の設定に何らかの問題がある場合には、実際にデプロイメントが実行される前に検出されます。
以前のリリースでは、同じイメージからのボリューム作成要求を同時に実行すると、Block Storage サービスのイメージキャッシュに複数のエントリーが追加される可能性がありました。このため、同じイメージのイメージキャッシュエントリーが重複して、スペースが無駄になっていました。

今回の更新では、この問題を防ぐために同期のロックが実装され、イメージからのボリューム作成の最初の要求がキャッシュされ、それ以外のリクエストはすべてキャッシュされたイメージを使用するようになりました。
以前のリリースでは、同じイメージからのボリューム作成要求を同時に実行すると、Block Storage サービスのイメージキャッシュに複数のエントリーが追加される可能性がありました。このため、同じイメージのイメージキャッシュエントリーが重複して、スペースが無駄になっていました。

今回の更新では、この問題を防ぐために同期のロックが実装され、イメージからのボリューム作成の最初の要求がキャッシュされ、それ以外のリクエストはすべてキャッシュされたイメージを使用するようになりました。
今回の機能拡張により、「glance-manage db purge」は、経過時間が 1 日未満の行を削除できるようになりました。この機能は、オペレーターがこの操作を定期的に実行する必要がある場合があるため追加されました。
その結果、「age_in_days」のオプションを「0」に設定することができるようになりました。
今回の機能拡張により、「glance-manage db purge」は、経過時間が 1 日未満の行を削除できるようになりました。この機能は、オペレーターがこの操作を定期的に実行する必要がある場合があるため追加されました。
その結果、「age_in_days」のオプションを「0」に設定することができるようになりました。
Time Series Database as a Service (gnocchi) および Aodh API のエンドポイントは、REST API 上で「/healthcheck」HTTP エンドポイントを公開するようになりました。このエンドポイントを要求すると、サービスのステータスを確認することが可能で、これには認証は必要ありません。
Time Series Database as a Service (gnocchi) および Aodh API のエンドポイントは、REST API 上で「/healthcheck」HTTP エンドポイントを公開するようになりました。このエンドポイントを要求すると、サービスのステータスを確認することが可能で、これには認証は必要ありません。
以前のリリースでは、FAILED 状態のリソースに pre-update フックが設定されていると、Orchestration サービスはフックがアクティブであることを示すイベントを記録し、ユーザーがフックを消去するのを待たずに代わりのリソースを即時に作成していました。その結果、tripleoclient サービスは、(イベントに基づいて) フックが保留中であると見なしましたが、代わりのリソースにはフックが設定されていないため、消去を試みても失敗し、director はオーバークラウドを更新できず、次のようなメッセージが表示されていました。 

    ERROR: The "pre-update" hook is not defined on SoftwareDeployment
    "UpdateDeployment"

これは、フックを使用する他のクライアント側のアプリケーションにも影響を及ぼしていました。director では、この問題のために、2 台のコントローラーノードで UpdateDeployment が順次ではなく同時に実行され、1 回に更新されるのは、1 台のコントローラーのみでした。

今回の更新では、Orchestration サービスは、リソースの状態に拘らず、ユーザーによってフックが消去されるまで一時停止するようになりました。このため、UpdateDeployment リソースが FAILED の状態でも、director のオーバークラウドの更新は完了するようになりました。
以前のリリースでは、FAILED 状態のリソースに pre-update フックが設定されていると、Orchestration サービスはフックがアクティブであることを示すイベントを記録し、ユーザーがフックを消去するのを待たずに代わりのリソースを即時に作成していました。その結果、tripleoclient サービスは、(イベントに基づいて) フックが保留中であると見なしましたが、代わりのリソースにはフックが設定されていないため、消去を試みても失敗し、director はオーバークラウドを更新できず、次のようなメッセージが表示されていました。 

    ERROR: The "pre-update" hook is not defined on SoftwareDeployment
    "UpdateDeployment"

これは、フックを使用する他のクライアント側のアプリケーションにも影響を及ぼしていました。director では、この問題のために、2 台のコントローラーノードで UpdateDeployment が順次ではなく同時に実行され、1 回に更新されるのは、1 台のコントローラーのみでした。

今回の更新では、Orchestration サービスは、リソースの状態に拘らず、ユーザーによってフックが消去されるまで一時停止するようになりました。このため、UpdateDeployment リソースが FAILED の状態でも、director のオーバークラウドの更新は完了するようになりました。
以前のリリースでは、スタックの状態が正しくない場合に Orchestration サービスがリソースのステータスをリセットすることができましたが、更新が再度トリガーされると、サービスはその操作に失敗していました。このため、リソースは進行中の状態で止まってしまい、デプロイメントのブロックを解除するのにデータベースを修正する必要がありました。

今回のリリースでは、Orchestration サービスは、スタックのステータス設定時に全リソースのステータスを設定するようになりました。これにより、リソースが進行中の状態で停止することはなくなり、操作の再試行を正常に実行できるようになりました。
以前のリリースでは、スタックの状態が正しくない場合に Orchestration サービスがリソースのステータスをリセットすることができましたが、更新が再度トリガーされると、サービスはその操作に失敗していました。このため、リソースは進行中の状態で止まってしまい、デプロイメントのブロックを解除するのにデータベースを修正する必要がありました。

今回のリリースでは、Orchestration サービスは、スタックのステータス設定時に全リソースのステータスを設定するようになりました。これにより、リソースが進行中の状態で停止することはなくなり、操作の再試行を正常に実行できるようになりました。
今回の更新により、CephFS ネイティブドライバーは OpenStack File Share Service (manila) のコアインフラストラクチャーと共に機能が拡張されました。CephFS ネイティブドライバーは、読み取り専用のファイル共有をサポートするようになりました。また、「access_list」には含まれていないバックエンドルールを削除することにより、リカバリーモードが向上されました。
今回の更新により、CephFS ネイティブドライバーは OpenStack File Share Service (manila) のコアインフラストラクチャーと共に機能が拡張されました。CephFS ネイティブドライバーは、読み取り専用のファイル共有をサポートするようになりました。また、「access_list」には含まれていないバックエンドルールを削除することにより、リカバリーモードが向上されました。
今回の機能拡張では、パブリックのファイル共有の作成を Dashboard で無効にできるようになりました。
作成処理中にファイル共有をパブリックにマークするチェックボックスを表示しないように Dashboard を設定することができます。デフォルトのオプションでは、このボックスにチェックマークはなしでプライベートのファイル共有が作成されます。
今回の機能拡張では、パブリックのファイル共有の作成を Dashboard で無効にできるようになりました。
作成処理中にファイル共有をパブリックにマークするチェックボックスを表示しないように Dashboard を設定することができます。デフォルトのオプションでは、このボックスにチェックマークはなしでプライベートのファイル共有が作成されます。
neutron-openvswitch-agent でセキュリティーグループのトランク機能を実装するには、openvswitch のファイアウォールドライバーが必要です。このドライバーには現在 BZ# 1444368 のバグがあり、同じコンピュートノード上にある異なるネットワークセグメントで同じ MAC アドレスのポートが 2 つある場合には、受信トラフィックが間違って照合されます。

このため、サブポートが親ポートと同じ MAC アドレスの場合には、受信トラフィックは一方のポートには正しく照合されません。

トラフィックを正しく処理するための回避策として、親ポートとサブポートでポートセキュリティーを無効にします。

たとえば、UUID 12345 のポートのポートセキュリティーを無効にするには、そのポートに関連付けられたセキュリティーグループを削除する必要があります。
 openstack port set --no-security-group --disable-port-security 12345

そのポートにはセキュリティーグループのルールは一切適用されず、トラフィックのフィルタリングおよび ip/mac/arp スプーフィングに対する保護は適用されない点に注意してください。
neutron-openvswitch-agent でセキュリティーグループのトランク機能を実装するには、openvswitch のファイアウォールドライバーが必要です。このドライバーには現在 BZ# 1444368 のバグがあり、同じコンピュートノード上にある異なるネットワークセグメントで同じ MAC アドレスのポートが 2 つある場合には、受信トラフィックが間違って照合されます。

このため、サブポートが親ポートと同じ MAC アドレスの場合には、受信トラフィックは一方のポートには正しく照合されません。

トラフィックを正しく処理するための回避策として、親ポートとサブポートでポートセキュリティーを無効にします。

たとえば、UUID 12345 のポートのポートセキュリティーを無効にするには、そのポートに関連付けられたセキュリティーグループを削除する必要があります。
 openstack port set --no-security-group --disable-port-security 12345

そのポートにはセキュリティーグループのルールは一切適用されず、トラフィックのフィルタリングおよび ip/mac/arp スプーフィングに対する保護は適用されない点に注意してください。
DVR の設定で、「test_l3_agent_scheduler.py」の「test_add_list_remove_router_on_l3_agent」が正常に終了しませんでした。このテスト手順は、新規ルーターの作成時に、以前にバインディング済みであっても、ネットワークインターフェースを L3 エージェントにバインディングするように試みていました。
この問題は修正され、ルーターへのインターフェース追加と L3 エージェントへの割り当ては、テストによって実行されるまでは行われないようになったので、テストは正常に終了するようになりました。
DVR の設定で、「test_l3_agent_scheduler.py」の「test_add_list_remove_router_on_l3_agent」が正常に終了しませんでした。このテスト手順は、新規ルーターの作成時に、以前にバインディング済みであっても、ネットワークインターフェースを L3 エージェントにバインディングするように試みていました。
この問題は修正され、ルーターへのインターフェース追加と L3 エージェントへの割り当ては、テストによって実行されるまでは行われないようになったので、テストは正常に終了するようになりました。
今回の機能拡張で、サーバーによって停止中と検出された LBaaS エージェントのロードバランサーを自動的に再スケジュールする機能が追加されました。以前は、ロードバランサーをスケジュールして、複数の LBaaS エージェントで実行することができましたが、ハイパーバイザーが停止した場合には、そのノードに対してスケジュールされていたロードバランサーは、操作を停止していました。
今回の更新では、これらのロードバランサーは別のエージェントに自動的に再スケジュールされるようになりました。この機能は、デフォルトで無効になっており、「allow_automatic_lbaas_agent_failover」を使用して管理されます。
今回の機能拡張で、サーバーによって停止中と検出された LBaaS エージェントのロードバランサーを自動的に再スケジュールする機能が追加されました。以前は、ロードバランサーをスケジュールして、複数の LBaaS エージェントで実行することができましたが、ハイパーバイザーが停止した場合には、そのノードに対してスケジュールされていたロードバランサーは、操作を停止していました。
今回の更新では、これらのロードバランサーは別のエージェントに自動的に再スケジュールされるようになりました。この機能は、デフォルトで無効になっており、「allow_automatic_lbaas_agent_failover」を使用して管理されます。
今回の機能拡張により、「HaproxyNSDriver」クラス (v2) に「ProcessMonitor」クラスが実装されました。このクラスは、必要に応じて「external_process」モジュールを活用して HAProxy プロセスを監視/再起動します。LBaaS エージェント (v2) は「external_process」関連のオプションを読み込み、HAProxy が予期せず停止した場合には、設定済みのアクションを実行します。
今回の機能拡張により、「HaproxyNSDriver」クラス (v2) に「ProcessMonitor」クラスが実装されました。このクラスは、必要に応じて「external_process」モジュールを活用して HAProxy プロセスを監視/再起動します。LBaaS エージェント (v2) は「external_process」関連のオプションを読み込み、HAProxy が予期せず停止した場合には、設定済みのアクションを実行します。
今回のリリースでは、多数のインスタンスがあるシステムに対して使用状況の統計を要求してリソースが大量に消費されるのを回避するために、ページネーションのサポートが追加されました。nova API simple-tenant-usage エンドポイントの v2.40 マイクロバージョンでは、新しいオプションのクエリーパラメーター「limit」と「marker」がページネーションに使用されます。「marker」オプションは開始点を設定し、「limit」オプションは開始点よりも後に表示されるレコード数を設定します。「limit」が設定されていない場合には、nova は設定可能な「max_limit」 (デフォルト値は 1000) を使用します。古いマイクロバージョンはこれらの新しいクエリーパラメーターを受け入れませんが、max_limit の適用を開始するので、結果が切り捨てられる場合があります。DoS ライクな使用状況の統計要求を回避して、応答が切り捨てられないようにするには、新しいマイクロバージョンを使用することを検討してください。
今回のリリースでは、多数のインスタンスがあるシステムに対して使用状況の統計を要求してリソースが大量に消費されるのを回避するために、ページネーションのサポートが追加されました。nova API simple-tenant-usage エンドポイントの v2.40 マイクロバージョンでは、新しいオプションのクエリーパラメーター「limit」と「marker」がページネーションに使用されます。「marker」オプションは開始点を設定し、「limit」オプションは開始点よりも後に表示されるレコード数を設定します。「limit」が設定されていない場合には、nova は設定可能な「max_limit」 (デフォルト値は 1000) を使用します。古いマイクロバージョンはこれらの新しいクエリーパラメーターを受け入れませんが、max_limit の適用を開始するので、結果が切り捨てられる場合があります。DoS ライクな使用状況の統計要求を回避して、応答が切り捨てられないようにするには、新しいマイクロバージョンを使用することを検討してください。
今回の更新により、バージョン 5.1.0 MapR プラグインがサポートされるようになりました。
今回の更新により、バージョン 5.1.0 MapR プラグインがサポートされるようになりました。
DPDK を有効にしたインスタンスの起動に関する SELinux ポリシーは完全ではないため、SELinux が enforcing モードの場合には DPDK を使用するインスタンスの起動は失敗して、openvswitch および svirt に関する AVC 拒否が /var/log/audit/audit.log* に表示されます。

回避策として、 以下のリンク先のセクション 4.4.1.2 に記載されているように、DPDK を使用する各コンピュートノードで SELinux を permissive に設定します。

SELinux の状態とモードの永続的変更

これにより、DPDK を有効化した仮想マシンを起動することができます。これは回避策で、この問題を詳しく調査している間の一時的な対策となる見込みです。
DPDK を有効にしたインスタンスの起動に関する SELinux ポリシーは完全ではないため、SELinux が enforcing モードの場合には DPDK を使用するインスタンスの起動は失敗して、openvswitch および svirt に関する AVC 拒否が /var/log/audit/audit.log* に表示されます。

回避策として、 以下のリンク先のセクション 4.4.1.2 に記載されているように、DPDK を使用する各コンピュートノードで SELinux を permissive に設定します。

SELinux の状態とモードの永続的変更

これにより、DPDK を有効化した仮想マシンを起動することができます。これは回避策で、この問題を詳しく調査している間の一時的な対策となる見込みです。
Heat 内のノードを削除する際には、バックグラウンドでそのプロセスがまだ実行中でも、削除のコマンドが終了し、プロンプトが返されていました。この直後に別のコマンドを実行すると、競合が発生して、コマンドが失敗していました。このプロセスの動作は変更され、プロセスが完全に終了した場合にのみプロンプトが返されるようになりました。
Heat 内のノードを削除する際には、バックグラウンドでそのプロセスがまだ実行中でも、削除のコマンドが終了し、プロンプトが返されていました。この直後に別のコマンドを実行すると、競合が発生して、コマンドが失敗していました。このプロセスの動作は変更され、プロセスが完全に終了した場合にのみプロンプトが返されるようになりました。
director で自動フェンシング設定を使用して、より簡単に高可用性のデプロイメントとアップグレードを実行できるようになりました。この新機能を活用するには、「overcloud generate fencing」コマンドを使用してください。
director で自動フェンシング設定を使用して、より簡単に高可用性のデプロイメントとアップグレードを実行できるようになりました。この新機能を活用するには、「overcloud generate fencing」コマンドを使用してください。
neutron-openvswitch-agent サービスを停止する場合には、停止の処理が正常に終了するのに長時間かかる場合があり、systemd によって強制終了されていました。このような場合には、実行中の neutron-rootwrap-daemon がシステムに残ってしまい、neutron-openvswitch-agent サービスが再起動できなくなっていました。
この問題は修正され、rpm スクリプレットが孤立した neutron-rootwrap-daemon を検出して終了するようになったので、neutron-openvswitch-agent サービスは正常に起動/再起動するようになりました。
neutron-openvswitch-agent サービスを停止する場合には、停止の処理が正常に終了するのに長時間かかる場合があり、systemd によって強制終了されていました。このような場合には、実行中の neutron-rootwrap-daemon がシステムに残ってしまい、neutron-openvswitch-agent サービスが再起動できなくなっていました。
この問題は修正され、rpm スクリプレットが孤立した neutron-rootwrap-daemon を検出して終了するようになったので、neutron-openvswitch-agent サービスは正常に起動/再起動するようになりました。
今回のリリースでは、「clustercheck」は Galera の「wsrep_cluster_address」オプションで指定したノードでのみ実行されるようになりました。この変更は、Galera が 専用ノードで実行されるユースケース (コンポーザブルロールで可能となった) を考慮して実装されました。以前のリリースでは、マイナーな更新の際には「clustercheck」は、Galera も同じノードにあることを前提として、pacemaker を稼働中の全ノードで実行されていました。
今回のリリースでは、「clustercheck」は Galera の「wsrep_cluster_address」オプションで指定したノードでのみ実行されるようになりました。この変更は、Galera が 専用ノードで実行されるユースケース (コンポーザブルロールで可能となった) を考慮して実装されました。以前のリリースでは、マイナーな更新の際には「clustercheck」は、Galera も同じノードにあることを前提として、pacemaker を稼働中の全ノードで実行されていました。
director は「/etc/rabbitmq/rabbitmq.config」に「tcp_list_options」 スタンザを 2 回設定していました。これによる悪影響はありませんでしたが、混乱を招く可能性がありました。今回の修正により重複していたスタンザは削除され、設定ファイルには「tcp_list_options」スタンザが 1 回のみ記載されるようになりました。
director は「/etc/rabbitmq/rabbitmq.config」に「tcp_list_options」 スタンザを 2 回設定していました。これによる悪影響はありませんでしたが、混乱を招く可能性がありました。今回の修正により重複していたスタンザは削除され、設定ファイルには「tcp_list_options」スタンザが 1 回のみ記載されるようになりました。
puppet の hieradata を使用して、libvirtd によって起動された QEMU インスタンス向けに max_files と max_processes を設定できるようになりました。これは、適切な puppet クラスが含まれた環境ファイルで設定することができます。たとえば、max_files を 32768 に、max_processes を 131072 に指定するには、以下の設定を使用します。

parameter_defaults:
  ExtraConfig
    nova::compute::libvirt::qemu::max_files: 32768
    nova::compute::libvirt::qemu::max_processes: 131072

また、libvirtd によって起動された QEMU インスタンスは多数のファイル記述子またはスレッドを使用する可能性があるため、今回の更新でこれらの値がデフォルト値になりました。これは、各コンピュートノード上でホストされているコンピュートのゲストと、各インスタンスのアタッチ先の Ceph RBD イメージによって異なります。大型のクラスターでは、これらの制限値を設定可能である必要があります。

これらの新しいデフォルト値により、Compute サービスは 700 以上の OSD を使用できるはずです。以前のリリースでは、max_files の数値 (元は 1024) が低いために課される制限として見なされていました。
puppet の hieradata を使用して、libvirtd によって起動された QEMU インスタンス向けに max_files と max_processes を設定できるようになりました。これは、適切な puppet クラスが含まれた環境ファイルで設定することができます。たとえば、max_files を 32768 に、max_processes を 131072 に指定するには、以下の設定を使用します。

parameter_defaults:
  ExtraConfig
    nova::compute::libvirt::qemu::max_files: 32768
    nova::compute::libvirt::qemu::max_processes: 131072

また、libvirtd によって起動された QEMU インスタンスは多数のファイル記述子またはスレッドを使用する可能性があるため、今回の更新でこれらの値がデフォルト値になりました。これは、各コンピュートノード上でホストされているコンピュートのゲストと、各インスタンスのアタッチ先の Ceph RBD イメージによって異なります。大型のクラスターでは、これらの制限値を設定可能である必要があります。

これらの新しいデフォルト値により、Compute サービスは 700 以上の OSD を使用できるはずです。以前のリリースでは、max_files の数値 (元は 1024) が低いために課される制限として見なされていました。
OpenStack Platform 10 には、Big Switch エージェントの誤った設定が含まれていました。同梱されている Heat テンプレートと共に Big Switch エージェントをデプロイすると、デプロイメントが失敗していました。今回の修正により、Heat テンプレートが Big Switch エージェントを正しくデプロイするように更新され、director はコンポーザブルロールに Big Switch エージェントを適切にデプロイするようになりました。
OpenStack Platform 10 には、Big Switch エージェントの誤った設定が含まれていました。同梱されている Heat テンプレートと共に Big Switch エージェントをデプロイすると、デプロイメントが失敗していました。今回の修正により、Heat テンプレートが Big Switch エージェントを正しくデプロイするように更新され、director はコンポーザブルロールに Big Switch エージェントを適切にデプロイするようになりました。
Memcached のデフォルトのメモリー設定は使用可能な RAM 全体の 95 パーセントだったので、リソースの競合が発生する場合がありました。今回の修正により、デフォルト値は使用可能な RAM 全体の 50 パーセントに下げられました。この値は「MemcachedMaxMemory」で設定することも可能です。このため、リソースの競合が発生する可能性が低くなりました。
Memcached のデフォルトのメモリー設定は使用可能な RAM 全体の 95 パーセントだったので、リソースの競合が発生する場合がありました。今回の修正により、デフォルト値は使用可能な RAM 全体の 50 パーセントに下げられました。この値は「MemcachedMaxMemory」で設定することも可能です。このため、リソースの競合が発生する可能性が低くなりました。
オーバークラウドのパッケージ更新のスクリプトのバグが原因で、更新用に提供されているパッケージがない場合でも、クラスターサービスが必ず再起動されていました。今回の修正により、保留中のパッケージ更新があるかどうかを判断するチェックが正しく機能するようになり、更新するパッケージがない場合には、yum update スクリプトは終了し、クラスターサービスは再起動されません。
オーバークラウドのパッケージ更新のスクリプトのバグが原因で、更新用に提供されているパッケージがない場合でも、クラスターサービスが必ず再起動されていました。今回の修正により、保留中のパッケージ更新があるかどうかを判断するチェックが正しく機能するようになり、更新するパッケージがない場合には、yum update スクリプトは終了し、クラスターサービスは再起動されません。
セキュリティー上の理由により、オーバークラウドではデフォルトで 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 にイメージをアップロードする前に実行してください。
セキュリティー上の理由により、オーバークラウドではデフォルトで 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 にイメージをアップロードする前に実行してください。
「tuned-profiles-cpu-partitioning」パッケージが「overcloud-full.qcow2」イメージに事前インストールされるようになりました。DPDK デプロイメントの場合には、このパッケージはホストのチューニングと CPU の用途分けをサポートするのに必要です。director には、必要な引数を使用して「tuned」サービスを有効にするための適切な first-boot スクリプトが含まれます。
「tuned-profiles-cpu-partitioning」パッケージが「overcloud-full.qcow2」イメージに事前インストールされるようになりました。DPDK デプロイメントの場合には、このパッケージはホストのチューニングと CPU の用途分けをサポートするのに必要です。director には、必要な引数を使用して「tuned」サービスを有効にするための適切な first-boot スクリプトが含まれます。
現在、Red Hat OpenStack Platform director 10 で SRIOV を有効にしている場合には、compute.yaml file で NIC ID (例: nic1、nic2、nic3 など) を使用するとオーバークラウドデプロイメントが失敗します。

デプロイメントが正常に完了するようにするには、回避策として、NIC ID の代わりに NIC の名前 (例: ens1f0、ens1f1、ens2f0 など) を使用する必要があります。
現在、Red Hat OpenStack Platform director 10 で SRIOV を有効にしている場合には、compute.yaml file で NIC ID (例: nic1、nic2、nic3 など) を使用するとオーバークラウドデプロイメントが失敗します。

デプロイメントが正常に完了するようにするには、回避策として、NIC ID の代わりに NIC の名前 (例: ens1f0、ens1f1、ens2f0 など) を使用する必要があります。
以前のバージョン (Red Hat Ceph Storage 1.3) を使用する外部の Ceph Storage クラスターと統合された Red Hat OpenStack Platform 環境をアップグレードまたはデプロイする場合には、後方互換性を有効にする必要があります。そのためには、アップグレードまたはデプロイメント中に environments/puppet-ceph-external.yaml で以下の行をコメント解除してください。

parameter_defaults:
  # Uncomment if connecting to a pre-Jewel or RHCS1.3 Ceph Cluster
  RbdDefaultFeatures: 1
以前のバージョン (Red Hat Ceph Storage 1.3) を使用する外部の Ceph Storage クラスターと統合された Red Hat OpenStack Platform 環境をアップグレードまたはデプロイする場合には、後方互換性を有効にする必要があります。そのためには、アップグレードまたはデプロイメント中に environments/puppet-ceph-external.yaml で以下の行をコメント解除してください。

parameter_defaults:
  # Uncomment if connecting to a pre-Jewel or RHCS1.3 Ceph Cluster
  RbdDefaultFeatures: 1
今回のリリースでは、CephFS のデプロイに必要な puppet モジュールが提供されるようになりました。これにより、director で、CephFS バックエンドを使用する OpenStack Shared File Systems サービス (openstack-manila) をデプロイすることができます。
今回のリリースでは、CephFS のデプロイに必要な puppet モジュールが提供されるようになりました。これにより、director で、CephFS バックエンドを使用する OpenStack Shared File Systems サービス (openstack-manila) をデプロイすることができます。
以前のリリースでは、以下のようなエラーでデプロイメントが失敗することがありました。
	  Error: /Stage[main]/Pacemaker::Corosync/Exec[Start Cluster tripleo_cluster]/returns: change from notrun to 0 failed: /sbin/pcs cluster start --all returned 1 instead of one of 0

今回の更新により、クラスターの設定中に puppet pacemaker が失敗する可能性のあったわずかな競合状態が解消されました。その結果、デプロイメントはエラーなしで正しく機能するようになりました。
以前のリリースでは、以下のようなエラーでデプロイメントが失敗することがありました。
	  Error: /Stage[main]/Pacemaker::Corosync/Exec[Start Cluster tripleo_cluster]/returns: change from notrun to 0 failed: /sbin/pcs cluster start --all returned 1 instead of one of 0

今回の更新により、クラスターの設定中に puppet pacemaker が失敗する可能性のあったわずかな競合状態が解消されました。その結果、デプロイメントはエラーなしで正しく機能するようになりました。
以前のリリースでは、Pacemaker のサービスはすべて同じロールにする必要がありました。

今回の更新の新たな機能により、Pacemaker の管理対象サービスでコンポーザブルロールを使用できるようになりました。Pacemaker の管理対象サービスをより多くの異なるノードにスケールアウトするためには、この機能が必要です。
以前のリリースでは、Pacemaker のサービスはすべて同じロールにする必要がありました。

今回の更新の新たな機能により、Pacemaker の管理対象サービスでコンポーザブルロールを使用できるようになりました。Pacemaker の管理対象サービスをより多くの異なるノードにスケールアウトするためには、この機能が必要です。
以前のリリースでは、OpenStack Dashboard サービスはデプロイメントの不適切なステップで設定されていました。このため、デプロイメント中に horizon が一時的に使用できなくなり、httpd サービスの再起動が追加で実行されていました。

今回の更新により、OpenStack Dashboard の設定は、httpd 設定の残りと同時に行われるように修正されました。その結果、オーバークラウドの実行時に、horizon が一時的に利用不能になることはなくなりました。
以前のリリースでは、OpenStack Dashboard サービスはデプロイメントの不適切なステップで設定されていました。このため、デプロイメント中に horizon が一時的に使用できなくなり、httpd サービスの再起動が追加で実行されていました。

今回の更新により、OpenStack Dashboard の設定は、httpd 設定の残りと同時に行われるように修正されました。その結果、オーバークラウドの実行時に、horizon が一時的に利用不能になることはなくなりました。
管理者はボリュームの譲渡操作時にユーザー認証情報を記録する必要がありますが、それを手動で行うのは煩わしい作業です。

今回の更新により、認証情報をダウンロードするための新たなボタンがボリュームの譲渡の画面に追加され、情報を簡単に保存できるようになりました。これにより、管理者はボタンをクリックして、情報をダウンロードして CSV ファイルを自分のローカルマシンに保存することができます。
管理者はボリュームの譲渡操作時にユーザー認証情報を記録する必要がありますが、それを手動で行うのは煩わしい作業です。

今回の更新により、認証情報をダウンロードするための新たなボタンがボリュームの譲渡の画面に追加され、情報を簡単に保存できるようになりました。これにより、管理者はボタンをクリックして、情報をダウンロードして CSV ファイルを自分のローカルマシンに保存することができます。
nova-api ワーカーにおけるメモリーの肥大化問題を防ぐために、simple-tenant-usage API 拡張機能にページネーションロジックが追加されました。
nova-api ワーカーにおけるメモリーの肥大化問題を防ぐために、simple-tenant-usage API 拡張機能にページネーションロジックが追加されました。
以前のリリースでは、アンダースコアが含まれたユーザー ID の処理がコード内で正しく行われないため、ユーザー ID にアンダースコアが含まれている場合には、プロジェクト/ドメインのメンバーを更新できませんでした。

今回の更新により、ユーザー ID を処理するコードが修正され、アンダースコアを正しく処理するようになりました。その結果、アンダースコアが含まれていても、プロジェクト/ドメインのメンバーを更新できるようになりました。
以前のリリースでは、アンダースコアが含まれたユーザー ID の処理がコード内で正しく行われないため、ユーザー ID にアンダースコアが含まれている場合には、プロジェクト/ドメインのメンバーを更新できませんでした。

今回の更新により、ユーザー ID を処理するコードが修正され、アンダースコアを正しく処理するようになりました。その結果、アンダースコアが含まれていても、プロジェクト/ドメインのメンバーを更新できるようになりました。
イベントの取得プロセスを最適化した後に、「openstack stack hook poll」コマンドは、保留中のフックが存在していて返す必要がある場合でも、返すのを停止していました。この問題は修正され、フックは正しく返されるようになりました。
イベントの取得プロセスを最適化した後に、「openstack stack hook poll」コマンドは、保留中のフックが存在していて返す必要がある場合でも、返すのを停止していました。この問題は修正され、フックは正しく返されるようになりました。
以前のリリースでは、「openstack network」コマンドは「--os-interface」スイッチを無視していました。そのため、他のインターフェースが指定されていても、このコマンドはすべて「パブリック」のエンドポイントを使用していました。今回のリリースでは、このスイッチに対するサポートが追加され、「openstack network」コマンドは「--os-interface」スイッチで指定されたエンドポイントを正しく使用するようになりました。
以前のリリースでは、「openstack network」コマンドは「--os-interface」スイッチを無視していました。そのため、他のインターフェースが指定されていても、このコマンドはすべて「パブリック」のエンドポイントを使用していました。今回のリリースでは、このスイッチに対するサポートが追加され、「openstack network」コマンドは「--os-interface」スイッチで指定されたエンドポイントを正しく使用するようになりました。
以前のリリースでは、Oslo Messaging のリモートプロシージャーコール (RPC) メッセージ受信確認 はスレッドセーフではありませんでした。そのため、競合状態により、Ceilometer で RPC タイムアウトが発生していました。今回のリリースでは Oslo Messaging のメッセージ受信確認は修正され、Ceilometer は正しく応答するようになりました。
以前のリリースでは、Oslo Messaging のリモートプロシージャーコール (RPC) メッセージ受信確認 はスレッドセーフではありませんでした。そのため、競合状態により、Ceilometer で RPC タイムアウトが発生していました。今回のリリースでは Oslo Messaging のメッセージ受信確認は修正され、Ceilometer は正しく応答するようになりました。
以前のリリースでは、Oslo Messaging は設定を正しく初期化していませんでした。その結果、「nova-manage」クライアントは起動中に失敗していました。今回のリリースではこのエラーは修正され、「nova-manage」は正しく起動するようになりました。
以前のリリースでは、Oslo Messaging は設定を正しく初期化していませんでした。その結果、「nova-manage」クライアントは起動中に失敗していました。今回のリリースではこのエラーは修正され、「nova-manage」は正しく起動するようになりました。
以前のリリースでは、更新またはアップグレードが失敗しても、0 の終了値が返されていたので、この値に基づいて、処理が正常に完了したかどうかを確認することはできませんでした。今回の更新により、更新またはアップグレードが失敗すると、例外が発生し、OpenStackClient に対してエラー状態であることを示しますようになりました。その結果、OpenStackClient は処理が正常に完了した場合にのみ 0 の終了値を返し、エラーが発生した場合には 0 以外の値を返すようになりました。
以前のリリースでは、更新またはアップグレードが失敗しても、0 の終了値が返されていたので、この値に基づいて、処理が正常に完了したかどうかを確認することはできませんでした。今回の更新により、更新またはアップグレードが失敗すると、例外が発生し、OpenStackClient に対してエラー状態であることを示しますようになりました。その結果、OpenStackClient は処理が正常に完了した場合にのみ 0 の終了値を返し、エラーが発生した場合には 0 以外の値を返すようになりました。
以前のリリースでは、「openstack overcloud image upload」は、オーバークラウドイメージのアップロードまたは更新時に「--image-path」の引数を無視していました。そのため、作業ディレクトリー内のイメージしか使用できませんでした。今回のリリースでは、「--image-path」の引数のサポートが追加され、この引数によって指定された異なるディレクトリーからイメージを正常にアップロードできるようになりました。
以前のリリースでは、「openstack overcloud image upload」は、オーバークラウドイメージのアップロードまたは更新時に「--image-path」の引数を無視していました。そのため、作業ディレクトリー内のイメージしか使用できませんでした。今回のリリースでは、「--image-path」の引数のサポートが追加され、この引数によって指定された異なるディレクトリーからイメージを正常にアップロードできるようになりました。
フェンシングデバイスとホストデバイスの名前が同じ場合には、Pacemaker は連続的にクラッシュします。この問題を回避するには、「fence-」のプレフィックスをフェンシングデバイスに追加してください。名前をこのように設定した場合には、クラスターはエラーなしで機能します。
フェンシングデバイスとホストデバイスの名前が同じ場合には、Pacemaker は連続的にクラッシュします。この問題を回避するには、「fence-」のプレフィックスをフェンシングデバイスに追加してください。名前をこのように設定した場合には、クラスターはエラーなしで機能します。

チャンネル	リポジトリー名
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 11 for RHEL 7 (RPMs)	`rhel-7-server-openstack-11-rpms`
Red Hat Enterprise Linux 7 Server - Extras (RPMs)	`rhel-7-server-extras-rpms`

チャンネル	リポジトリー名
Red Hat Enterprise Linux 7 Server - Optional	`rhel-7-server-optional-rpms`
Red Hat OpenStack Platform 11 Operational Tools for RHEL 7 (RPMs)	`rhel-7-server-openstack-11-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"`

リリースノート

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

OpenStack Documentation Team

第1章 はじめにリンクのコピーリンクがクリップボードにコピーされました!

1.1. 本リリースについてリンクのコピーリンクがクリップボードにコピーされました!

1.2. 要件リンクのコピーリンクがクリップボードにコピーされました!

1.3. デプロイメント制限事項リンクのコピーリンクがクリップボードにコピーされました!

1.4. データベースサイズの管理リンクのコピーリンクがクリップボードにコピーされました!

1.5. 認定済みのドライバーとプラグインリンクのコピーリンクがクリップボードにコピーされました!

1.6. 認定済みゲストオペレーティングシステムリンクのコピーリンクがクリップボードにコピーされました!

1.7. Bare Metal Provisioning でサポートされているオペレーティングシステムリンクのコピーリンクがクリップボードにコピーされました!

1.8. ハイパーバイザーのサポートリンクのコピーリンクがクリップボードにコピーされました!

1.9. コンテンツ配信ネットワーク (CDN) チャンネルリンクのコピーリンクがクリップボードにコピーされました!

1.10. 製品サポートリンクのコピーリンクがクリップボードにコピーされました!

第2章 最も重要な新機能リンクのコピーリンクがクリップボードにコピーされました!

2.1. Red Hat OpenStack Platform Directorリンクのコピーリンクがクリップボードにコピーされました!

2.2. Block Storageリンクのコピーリンクがクリップボードにコピーされました!

2.3. Computeリンクのコピーリンクがクリップボードにコピーされました!

2.4. Dashboardリンクのコピーリンクがクリップボードにコピーされました!

2.5. Identityリンクのコピーリンクがクリップボードにコピーされました!

2.6. Image サービスリンクのコピーリンクがクリップボードにコピーされました!

2.7. OpenStack Networkingリンクのコピーリンクがクリップボードにコピーされました!

2.8. Shared File Systemリンクのコピーリンクがクリップボードにコピーされました!

2.9. Telemetryリンクのコピーリンクがクリップボードにコピーされました!

2.10. 高可用性リンクのコピーリンクがクリップボードにコピーされました!

2.11. 運用ツールリンクのコピーリンクがクリップボードにコピーされました!

2.12. Bare Metal Provisioning サービスリンクのコピーリンクがクリップボードにコピーされました!

2.13. OpenStack Integration Test Suite サービスリンクのコピーリンクがクリップボードにコピーされました!

2.14. OpenStack Data Processing サービスリンクのコピーリンクがクリップボードにコピーされました!

2.15. テクノロジープレビューリンクのコピーリンクがクリップボードにコピーされました!

2.15.1. 新規テクノロジープレビューリンクのコピーリンクがクリップボードにコピーされました!

2.15.2. 以前にリリースされたテクノロジープレビューリンクのコピーリンクがクリップボードにコピーされました!

第3章 リリースの情報リンクのコピーリンクがクリップボードにコピーされました!

3.1. Red Hat OpenStack Platform 11 GAリンクのコピーリンクがクリップボードにコピーされました!

3.1.1. 機能拡張リンクのコピーリンクがクリップボードにコピーされました!

3.1.2. リリースノートリンクのコピーリンクがクリップボードにコピーされました!

3.1.3. 既知の問題リンクのコピーリンクがクリップボードにコピーされました!

3.1.4. 非推奨の機能リンクのコピーリンクがクリップボードにコピーされました!

3.2. Red Hat OpenStack Platform 11 メンテナンスリリースリンクのコピーリンクがクリップボードにコピーされました!

3.2.1. 機能拡張リンクのコピーリンクがクリップボードにコピーされました!

3.2.2. リリースノートリンクのコピーリンクがクリップボードにコピーされました!

3.2.3. 既知の問題リンクのコピーリンクがクリップボードにコピーされました!

3.2.4. 非推奨の機能リンクのコピーリンクがクリップボードにコピーされました!

第4章 テクニカルノートリンクのコピーリンクがクリップボードにコピーされました!

4.1. RHEA-2016:1245: Red Hat OpenStack Platform 11.0 のバグ修正と機能拡張アドバイザリーリンクのコピーリンクがクリップボードにコピーされました!

法律上の通知リンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第1章はじめに
リンクのコピー

1.1. 本リリースについて
リンクのコピー

1.2. 要件
リンクのコピー

1.3. デプロイメント制限事項
リンクのコピー

1.4. データベースサイズの管理
リンクのコピー

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

1.6. 認定済みゲストオペレーティングシステム
リンクのコピー

1.7. Bare Metal Provisioning でサポートされているオペレーティングシステム
リンクのコピー

1.8. ハイパーバイザーのサポート
リンクのコピー

1.9. コンテンツ配信ネットワーク (CDN) チャンネル
リンクのコピー

1.10. 製品サポート
リンクのコピー

第2章最も重要な新機能
リンクのコピー

2.1. Red Hat OpenStack Platform Director
リンクのコピー

2.2. Block Storage
リンクのコピー

2.3. Compute
リンクのコピー

2.4. Dashboard
リンクのコピー

2.5. Identity
リンクのコピー

2.6. Image サービス
リンクのコピー

2.7. OpenStack Networking
リンクのコピー

2.8. Shared File System
リンクのコピー

2.9. Telemetry
リンクのコピー

2.10. 高可用性
リンクのコピー

2.11. 運用ツール
リンクのコピー

2.12. Bare Metal Provisioning サービス
リンクのコピー

2.13. OpenStack Integration Test Suite サービス
リンクのコピー

2.14. OpenStack Data Processing サービス
リンクのコピー

2.15. テクノロジープレビュー
リンクのコピー

2.15.1. 新規テクノロジープレビュー
リンクのコピー

2.15.2. 以前にリリースされたテクノロジープレビュー
リンクのコピー

第3章リリースの情報
リンクのコピー

3.1. Red Hat OpenStack Platform 11 GA
リンクのコピー

3.1.1. 機能拡張
リンクのコピー

3.1.2. リリースノート
リンクのコピー

3.1.3. 既知の問題
リンクのコピー

3.1.4. 非推奨の機能
リンクのコピー

3.2. Red Hat OpenStack Platform 11 メンテナンスリリース
リンクのコピー

3.2.1. 機能拡張
リンクのコピー

3.2.2. リリースノート
リンクのコピー

3.2.3. 既知の問題
リンクのコピー

3.2.4. 非推奨の機能
リンクのコピー

第4章テクニカルノート
リンクのコピー

4.1. RHEA-2016:1245: Red Hat OpenStack Platform 11.0 のバグ修正と機能拡張アドバイザリー
リンクのコピー

法律上の通知
リンクのコピー