リリースノート Red Hat OpenStack Platform 14

[reponame]

#subscription-manager repos --enable=[reponame]
#subscription-manager repos --disable=[reponame]
parameter_defaults:
  ComputeOvsDpdkParameters:
    NovaComputeCpuSharedSet: "0-1"
HostCpusList: "0-1"
hw:emulator_threads_policy=share
workflow_parameters:  tripleo.derive_params.v1.derive_parameters:
    num_phy_cores_per_numa_node_for_pmd: 2
    huge_page_allocation_percentage: 90
今回の更新で、「openstack port list」コマンドの出力にホスト名およびネットワーク名が追加されました。
追加の情報により、Neutron ポートおよび IP アドレスと特定のホストを容易に関連付けられるようになりました。
今回の更新で、libvirt コンピュートドライバーが信頼済み SR-IOV Virtual Function を持つインスタンスの作成を許可するようになりました。信頼済みの場合、ゲストの VF の MAC アドレスを変更するなど特定の操作を実施することができます。

インターフェースをボンディングするためには、すべてのスレーブで同じ MAC アドレスが使用されている必要があります。一方、フェイルオーバー時には VF の 1 つで MAC アドレスの変更が必要になります。MAC アドレスの変更は権限を必要とする操作なので、ゲストでボンディングを正しく設定するためには、該当する VF は信頼済みでなければなりません。

管理者は VF を信頼済みモードに設定できるようになりました。設定するには次の 2 つのステップを実施する必要があります。まず、nova.conf の「[pci] passthrough_whitelist」JSON 設定オプションの「trusted」の値を「true」に設定する必要があります。以下に例を示します。

    [pci]
    passthrough_whitelist = {"devname": "eth0", "trusted": "true",
                             "physical_network":"sriovnet1"}

次に、ポートの作成時にバインディングプロファイルを「trusted=true」に設定する必要があります。以下に例を示します。

    $ neutron port-create <net-id> \
        --name sriov_port \
        --vnic-type direct \
        --binding:profile type=dict trusted=true

信頼済みモードは SR-IOV VF にしか適用されないので、「vnic-type」は「hw_veb」または「direct」のどちらかに設定しなければなりません。
Heat テンプレートに「CephClusterName」パラメーターが含まれるようになりました。このパラメーターにより Ceph クラスター名をカスタマイズすることができます。外部の Ceph クラスターまたは Ceph RBDMirror を使用する場合に、この操作を実施しなければならない場合があります。
今回の更新で、アプリケーションの認証情報を作成して、アプリケーションの keystone に対する認証を許可できるようになりました。

https://docs.openstack.org/keystone/latest/user/application_credentials.html を参照してください。
機能:
nova-scheduler への重み付け関数 CPUWeigher の追加

理由:
CPUWeigher により、オペレーターは仮想 CPU をスタックするか分散するかのポリシーを設定することができます。

結果:
オペレーターは CPUWeigher を有効にしてスタックする (まず、1 つのノードの仮想 CPU をすべて使用する) または分散する (すべてのホストからほぼ同数の仮想 CPU を使用する) ポリシーを設定することができます。
今回の更新で、パケット破棄の削減用に、チューニング可能なオプションが新たに 2 つサポートされるようになりました。

強固なパーティション設定が使用されていても (isolcpus、tuned)、仮想 CPU (vCPU) がハイパーバイザーカーネルスレッドにより占有される場合があります。占有は頻繁ではなく 1 秒あたり数回ですが、virtio キュー 1 つあたりの記述子が 256 であれば、1 回の仮想 CPU 占有が発生しただけでパケットの破棄につながります (占有されている間 256 のスロットが埋まるため)。キュー 1 つあたりのパケットレートが 1 Mpps (1 秒あたり 100 万パケット) を超えているネットワーク機能仮想化 (NFV) の仮想マシンがこのケースです。

今回の更新で、2 つの新しいチューニング可能なオプション (「rx_queue_size」および「tx_queue_size」) がサポートされるようになりました。これらのオプションを使用して virtio NIC の受信キューサイズおよび送信キューサイズを設定し、パケットの破棄を削減します。
Nova がインスタンスを作成/起動/削除した正確な時間を追跡するために、インスタンスリソースに 3 つの新たな属性 (launched_at、deleted_at、および created_at) が追加されました。
OpenStack director が、オーバークラウドノードのソフトウェア設定に Ansible を使用するようになりました。Ansible によりオーバークラウドのデプロイメントが分りやすく、またデバッグがより簡単になります。Ansible を使用することで、heat とオーバークラウドノード上の heat エージェント (os-collect-config) 間の通信およびソフトウェア設定デプロイメントデータの移動が置き換えられます。

各オーバークラウドノード上で os-collect-config を動作させ heat からデプロイメントデータをポーリングするのに代わって、Ansible のコントロールノードが Ansible インベントリーファイルおよび Playbook とタスクのセットと共に ansible-playbook を実行し、設定を適用します。Ansible のコントロールノード (ansible-playbook を実行するノード) は、デフォルトではアンダークラウドです。
OpenStack Sahara が Cloudera Distribution Hadoop (CDH) プラグイン 5.13 をサポートするようになりました。
今回の更新で、OpenStack Sahara に s3 互換オブジェクトストアのサポートが追加されました。
今回のリリースで、Nova の libvirt ドライバーは、CPU モデルの設定時に CPU 機能のフラグをより細かく指定できるようになりました。

「Meltdown」CVE の修正を適用した後に、特定の Intel ベースの仮想 CPU モデルで実行しているゲストのパフォーマンスが低下していました。今回の変更の利点の 1 つは、このパフォーマンス低下が軽減されることです。ゲストのパフォーマンスに対する影響は、CPU 機能フラグ「PCID」(Process-Context ID) を *ゲスト* CPU に公開することによって軽減されます。これは、物理ハードウェア自体で PCID フラグが利用可能であることを前提とします。

使用方法についての詳しい情報は、「nova.conf」の「[libvirt]/cpu_model_extra_flag」の説明を参照してください。
今回の更新では、「neutron」ネットワークインターフェースを使用したマルチテナントベアメタルネットワーク設定が導入されています。

「neutron」ネットワークインターフェースを使用してベアメタルノードを設定すると、ベアメタルノードでのプロビジョニングとテナントトラフィック用に、独立した VLAN ネットワークを使用することができます。
QDR をサポートするために、新たな TripleO heat テンプレートが追加されています。
metrics_qdr サービスを有効にするとすべてのオーバークラウドノードに QDR サービスがデプロイされ、各オーバークラウドノード上で動作する collectd サービスからのメトリックデータをルーティングするのに使用されます。

該当する heat テンプレートのパラメーターを以下に示します。

MetricsQdrPort:
   default: '5666'
   description: Service name or port number on which the qdrouterd will accept connections. This argument must be string, even if the numeric form is used.
   type: string
 MetricsQdrUsername:
   default: 'guest'
   description: Username which should be used to authenticate to the deployed qdrouterd.
   type: string
 MetricsQdrPassword:
   default: 'guest'
   description: Password which should be used to authenticate to the deployed qdrouterd.
   type: string
   hidden: true
 MetricsQdrConnectors:
   default: []
   description: Connectors configuration (array of hashes).
   type: json
 MetricsQdrAddresses:
   default:
     - prefix: 'collectd/notify'
       distribution: multicast
     - prefix: 'collectd/telemetry'
       distribution: multicast
   description: Addresses configuration (array of hashes).
   type: json
 MetricsQdrUseSSL:
   default: false
   description: Set to true if it is required to use SSL or TLS on the connection for listener.
   type: boolean
 MetricsQdrUseEncryption:
   default: false
   description: Set to true if it is required to encrypt connection to the peer for listener.
   type: boolean
 MetricsQdrSaslMechanisms:
   default: 'ANONYMOUS'
   description: List of accepted SASL auth mechanisms for listener in format of comma separated list.
   type: string
 MetricsQdrSslCertDb:
   default: ''
   description: Path to SSL certificate db for listener.
   type: string
 MetricsQdrSslCertFile:
   default: ''
   description: Path to SSL certificate file for listener.
   type: string
 MetricsQdrSslKeyFile:
   default: ''
   description: Path to SSL private key file for listener.
   type: string
 MetricsQdrSslPwFile:
   default: ''
   description: Path to SSL password file for certificate key for listener.
   type: string
 MetricsQdrSslPassword:
   default: ''
   description: SSL password to be supplied for listener.
   type: string
 MetricsQdrTrustedCerts:
   default: ''
   description: Path to file containing trusted certificates for listener.
   type: string
Red Hat OpenStack Platform 14 が IBM POWER9 CPU 上でサポートされるようになりました。このサポートは「rhosp-director-images-ppc64lep9」および「rhosp-director-images-ipa-ppc64lep9」パッケージにより提供されます。
本リリースでは、テクノロジープレビューとして、cinder および nova の両方において、ボリュームを同時に複数のホストまたはサーバーに読み取り/書き込み (RW) モードでアタッチする機能が追加されています (この機能がバックエンドドライバーでサポートされる場合)。この機能は、一般的にアクティブ/アクティブまたはアクティブ/スタンバイのシナリオが求められる、クラスター化したアプリケーション負荷のユースケースに対応したものです。
この機能により、VXLAN IP ヘッダーでカプセル化されたテナントからの DSCP マーキングに基づき、テナントトラフィックを転送することができます。この機能は OSP14 ではテクノロジープレビューです。
先にインスタンスを移行せずにコンピュートノードがリブートした場合に、コンピュートノード上のインスタンスが自動的に再起動するように設定できるようになりました。Nova および libvirt-guests エージェントを設定して、インスタンスを安全にシャットダウンし、コンピュートノードのリブート時にインスタンスを起動することができます。

新たなパラメーター:
NovaResumeGuestsStateOnHostBoot (True/False)
NovaResumeGuestsShutdownTimeout (デフォルト: 300 秒)
コンテナー化された Ironic サービスに対応するために、「--http-boot」のデフォルト値が「/httpboot」から「/var/lib/ironic/httpboot」に変更されました。
今回の更新で、コンテナー化されたサービスのログローテーションに、デフォルトで logrotate の copytruncate が使用されるようになりました。古いログを保管するデフォルトの期間に変更はありません (14 日間)。
これまでテクノロジープレビューとして含まれていた OpenStack Rally が、本リリースから削除されました。
web-download 機能を使用する場合に、ステージングエリア (「node_staging_uri」オプションを使用して設定ファイルで定義する) が正しく消去されません。glance-api.conf ファイルの「glance_store」セクションで、「file」が「stores」設定オプションの一部であることを確認してください。
イメージ変換機能を使用する場合には、glance-api.conf ファイルの「glance_store」セクションで、「file」が「stores」設定オプションの一部であることを確認してください。
glance イメージを変換する場合、デフォルトでは glance-direct メソッドは有効になっていません。この機能を有効にするには、glance-api.conf の DEFAULT セクションで、「enabled_import_methods」を「[glance-direct,web-download]」または「[glance-direct]」に設定してください。
Red Hat OpenStack Platform 14 の新規インストールの場合、デフォルトでは Glance イメージ変換は有効になっていません。この機能を使用するには、glance-image-import.conf ファイルを編集します。
image_import_opts セクションに、以下の行を追加してください。
image_import_plugins = ['image_conversion']
テナントまたはプロバイダーネットワークに関して、OpenDaylight は IPv6 をサポートしません。したがって、IPv4 だけを使用してください。IPv4 ネットワークと共に IPv6 ネットワークが使用されていると、Floating IP に関する問題が生じる場合があります。
OvsDpdkMemoryChannels パラメーターは、DPDK パラメーター抽出ワークフローを使用して抽出することができません。デフォルトでは、値は 4 に設定されています。お使いのハードウェアに合わせて、この値をカスタム環境ファイルで変更することができます。
小規模な Nova フレーバーを使用するように Octavia が設定されている場合、Amphorae (Nova インスタンス) は正常に作成されますがロードバランサーが約 25 分間 PENDING の状態から遷移しない場合があります。本来であれば、ロードバランサーがエラー状態に遷移して Amphorae は削除されなければなりません。

小規模な Nova フレーバーの場合の回避策としては、[haproxy_amphora] セクションの Octavia 設定「connection_max_retries」、「connection_retry_interval」、「build_active_retries」、および「build_retry_interval」をより実稼働に適した値に変更する方法があります。これにより、小規模な Nova フレーバーの場合に、ロードバランサーが PENDING から ERROR 状態により迅速に遷移します。
Openstack rc ファイル生成のワークフロートリガーは python-tripleoclient にハードコーディングされています。
その結果、OpenStack 固有のワークフローは director が OpenShift をデプロイした後にトリガーされます。OpenStack 固有の URL が、stdout および作成される OpenStack rc ファイルに表示されます。
Fernet トークンのローテーションに関して、鍵がオーバークラウドに自動的にデプロイされないという既知の問題があります。ワークフロータスク「tripleo.fernet_keys.v1.rotate_fernet_keys」により鍵は生成されますが、それらが正しくオーバークラウドにプッシュされません。この問題は今後のリリースで対応する計画です。この更新の前にローテーションを実施する場合には、以下の回避策のいずれかに従ってください。
* ローテーションを実施する前に、オーバークラウドノード上で os-collect-config を実行する。os-collect-config が不要であれば、その後停止することができます。
* すべてのオーバークラウドノードで os-collect-config を有効にする。修正が適用された更新がリリースされたら、os-collect-config を無効にすることができます。
注記: 更新がリリースされる前に鍵をローテーションする必要がなければ、特にアクションは必要ありません。
/var/lib/gnocchi/ ディレクトリーへのアクセス権限が原因で、Gnocchi ファイルバックエンドを設定したオーバークラウドのデプロイに失敗する場合があります。

回避策: オーバークラウドをデプロイする前に、以下のように openstack/tripleo-heat-templates/docker/services/gnocchi-api.yaml ファイルでディレクトリーへのアクセス権限を設定する。

            - path:
                list_join:
                  - "/"
                  - - {get_param: GnocchiFileBasePath}
                    - "tmp"
              owner: gnocchi:gnocchi
              perm: '0600'
              recurse: true
director によりデプロイされた OpenShift 環境では、GlusterFS Playbook が実行されるたびに新しい heketi 秘密鍵が自動生成されます。
このため、CNS デプロイメントのスケールアウトまたは設定変更などの操作に失敗します。

回避策としては、以下の手順を実行する方法があります。
1. デプロイメント後に、heketi 秘密鍵を回収する。マスターノードのいずれかで、以下のコマンドを使用します。
sudo oc get secret heketi-storage-admin-secret --namespace glusterfs -o json | jq -r .data.key | base64 -d
2. 環境ファイルで、以下のパラメーターをその値に設定する。
  openshift_storage_glusterfs_heketi_admin_key
  openshift_storage_glusterfs_registry_heketi_admin_key

この回避策の結果、パラメーターが手動で抽出される限り、CNS デプロイメントのスケールアウトまたは設定変更などの操作が正常に機能します。
3 つのコントローラーノードをすべて再起動すると、オーバークラウドのテナントインスタンスを起動できない場合があります。「DuplicateMessageError」のメッセージがオーバークラウドログに記録されます。
回避策としては、オーバークラウドコントローラーのいずれかで、以下のコマンドを実行する方法があります。
pcs resource restart rabbitmq-bundle
インフラノード上のルーターへのプロキシリクエストのために、director はマスターノード上で実行中の HAProxy インスタンスのポート 443 をセットアップします。OpenShift API をバインドするために、OpenShift のマスターノードのポート 443 を使用することはできません。director によりデプロイされた OpenShift 環境では、OpenShift API をポート 443 に設定することはできません。
director の提供する overcloud-full イメージが原因で、OpenShift リポジトリーにより提供される python-setuptools との間で RPM 競合が生じます。デプロイメント後に OpenShift ノードで実施する yum update は、依存関係の不整合により常に失敗します。

この問題を修正するには、アンダークラウドで以下のコマンドを実行します。
source ~/stackrc
tripleo-ansible-inventory --stack openshift --static-yaml-inventory
/home/stack/openshift_inventory.yaml
export ANSIBLE_HOST_KEY_CHECKING=False
ansible -i openshift_inventory.yaml -m shell -b -a 'rpm -e --nodeps python-setuptools-0.9.8-7.el7.noarch; yum -y install python-setuptools' overcloud

このコマンドにより、overcloud-full イメージの提供する python-setuptools が OpenShift リポジトリーにより提供されるバージョンに置き換えられます。これ以降の yum update は正常に機能します。
一部の OVS バージョンでは、「updelay」および「downdelay」ボンディング設定が無視され、常にデフォルト設定が使用されます。
nova-compute ironic ドライバーは、BM ノードのクリーンアップ中にノードの更新を試みます。クリーンアップには約 5 分間かかりますが、nova-compute は約 2 分間ノードの更新を試みます。タイムアウト後、nova-compute は停止し nova インスタンスを ERROR 状態に切り替えます。

回避策としては、nova-compute サービスで以下の設定オプションを定義する方法があります。
[ironic]
api_max_retries = 180

この結果、nova-compute はより長時間 BM ノードの更新を試み続け、最終的には正常に完了します。
containers-prepare-parameter.yaml ファイルの「neutron_driver」パラメーターの値は「null」です。これにより、OpenDaylight デプロイメントのオーバークラウドのマイナーアップデートに失敗する場合があります。

回避策: オーバークラウドを更新する前に、「neutron_driver」パラメーターの値を「odl」に設定します。
director によりデプロイされた OpenShift 環境に追加の OpenShift マスターノードがある場合には、「The field 'vars' has an invalid value, which includes an undefined variable. The error was: 'openshift_master_etcd_urls' is undefined…」のようなメッセージと共にスケールアウトに失敗します。
CNS が有効な director によりデプロイされた OpenShift 環境に追加のインフラノードがある場合には、「fatal: [openshift-master-2]: FAILED! => {"changed": false, "msg": "Error mounting /tmp/openshift-glusterfs-registry-c8qImT: Mount failed.」のようなメッセージと共にスケールアウトに失敗します。
director と openshift-ansible とでは、イメージタグに対する考え方が異なります。たとえば、リモートコンテナーイメージをローカルにインポートする場合、director は、イメージメタデータの「バージョン」および「リリース」ラベルを元に、全般タグをイメージを一意に識別するタグに変換します。一方 Openshift-ansible は、すべての openshift イメージタグについて固有の「openshift_image_tag」変数に依存しているので、イメージのタグを個別に識別することができません。リモートコンテナーイメージレジストリーのフローティング v3.11 タグがポイントするイメージで、メタデータの「リリース」または「バージョン」ラベルが異なる場合には、director を使用した OCP のデプロイメントに失敗します。

OpenShift をデプロイする前にアンダークラウドからラベルの異なるイメージをインポートし、すべての openshift イメージについて同一のタグを設定します。

  skopeo --tls-verify=false copy docker://registry.access.redhat.com/openshift3/prometheus:v3.11.51-1 docker://192.168.24.1:8787/openshift3/prometheus:v3.11.51-2

director からの OpenShift デプロイメントは、イメージを失うことなく正常に完了します。
director によりデプロイされた OpenShift 環境では、director がトリガーとなり Red Hat Enterprise Linux OS および OpenShift Container Platform が更新されることはありません。director によりデプロイされた OpenShift 環境をマイナーアップデートすることはできません。
config-download によりオーバークラウドの Playbook を生成した後に、--check パラメーターを指定して ansible-playbook を実行すると、正常に動作しません。ftype の stdout 未定義に起因するエラーが発生します。この問題は、次のバージョンで修正される計画です。
Ansible の既知の問題 (https://github.com/ansible/ansible/issues/24449) により、/etc/ssh/ssh_known_hosts に加えた変更が、コンピュートホスト追加後に環境内の既存の nova_compute および nova_libvirt コンテナーに反映されません。

したがって、元のホストが必要な SSH 公開鍵を持たないため、新たに追加したコンピュートホストを使用したライブマイグレーション、コールドマイグレーション、およびインスタンスのサイズ変更操作に失敗します。

回避策:
すべての nova_compute および nova_libvirt コンテナーを再起動することで、/etc/ssh/ssh_known_hosts に対する更新が正しく書き込まれます。

詳細な手順は、以下に示す KCS の記事に記載されています。

[OSP14] After successful scale out, live/cold migration and resize fails to the new added compute with 'Host key verification failed'
https://access.redhat.com/solutions/3792021
昨今の変更で、NUMA トポロジーを持つインスタンスのメモリー割り当てにページサイズが考慮されるようになりました。この変更で、NUMA トポロジーを持つインスタンスのメモリーをオーバーサブスクライブできなくなりました。

従来、オーバーサブスクリプションが使えないのはヒュージページを持つインスタンスだけでしたが、現在は NUMA トポロジーを持つすべてのインスタンスで、メモリーのオーバーサブスクリプションが無効になっています。この変更は、明示的な NUMA トポロジーを持つインスタンスおよび暗示的な NUMA トポロジーを持つインスタンスに影響を及ぼします。ヒュージページまたは CPU ピニングにより、インスタンスが暗示的な NUMA トポロジーを持つ場合があります。

可能であれば、明示的な NUMA トポロジーの使用は避けてください。CPU ピニングが必要な場合に、暗示的な NUMA トポロジーが生じてしまいます。これに対する回避策はありません。
OpenDaylight は OSP 13 で初めて導入され、OSP 14 では非推奨となっています。

OpenDaylight と OpenStack を組み合わせたソリューションでは、新たな機能拡張のリクエストは受け付けられなくなりました。OpenDaylight が組み込まれた Red Hat ソリューションが必要なお客様は、代替のシステムをお探しください。

OSP 14 の非推奨化サイクル期間中、OpenDaylight のサポートは継続されバグ修正のリクエストは受け付けられますが、OSP 13 のライフサイクル終了の時点で、サポートは完全に廃止される予定です (2021 年 6 月 27 日)。
以前のリリースでは、Satele URL がロールに正しく設定されていませんでした。このためシステムは Satellite サーバーのバージョンを取得できず、登録に失敗していました。今回の修正で、デフォルトで rhsm_baseurl パラメーターから rhsm_satellite_url の値を取得し、URL を登録タスクに渡して強制的に登録する機能が追加されました。さらに、登録証のエラーを無視するオプションが追加されました。必要に応じて、デフォルト値の上書きやオプションの設定が可能です。
これまでテクノロジープレビューとして含まれていた OpenStack Rally が、本リリースから削除されました。
今回の更新で、aodh サービスがイベントタイプの入力クエリーを検証するようになりました。
今回の更新以前は、入力クエリーは検証されていませんでした。無効な入力クエリーのために、警告の発行に失敗する場合がありました。
Nova がインスタンスを作成/起動/削除した正確な時間を追跡するために、インスタンスリソースに 3 つの新たな属性 (launched_at、deleted_at、および created_at) が追加されました。
OpenStack Metrics サービス (Ceilometer) が、Monitoring サービス (Gnocchi) で計測されないメトリックを作成していました。今回の修正で、不必要なメトリックが削除されました。Ceilometer は、Gnocchi で計測されるメトリックだけを作成するようになりました。
本リリースでは、テクノロジープレビューとして、cinder および nova の両方において、ボリュームを同時に複数のホストまたはサーバーに読み取り/書き込み (RW) モードでアタッチする機能が追加されています (この機能がバックエンドドライバーでサポートされる場合)。この機能は、一般的にアクティブ/アクティブまたはアクティブ/スタンバイのシナリオが求められる、クラスター化したアプリケーション負荷のユースケースに対応したものです。
今回の機能拡張により、ボリュームが同じ Ceph クラスター内にある場合に、Cinder バックエンド間の RBD ボリュームの移行が最適化されるようになりました。両方のボリュームが同じ Ceph クラスターにある場合には、データ移行が cinder-volume プロセスではなく Ceph 自体で実施されます。これにより、移行に要する時間が短縮されます。
OpenStack Bare Metal サービス (Ironic) から BMC/IPMI ハードウェアに送信されるコマンドの中には、ハードウェアドライバーのエラーにより正常に機能しないものがありました。このため、ベアメタルノードの起動が妨げられていました。今回の修正で ipmi_disable_boot_timeout ハードウェアドライバーオプションが追加され、これらのコマンドが Ironic から IPMI ハードウェアに送信されなくなりました。
今回の更新で、Dell EMC PowerEdge 13 および 14 世代サーバーに対する UEFI 永続ブートモードサポートの問題が修正されています。これらのサーバーは、どちらの永続ブートモード (BIOS および UEFI) であっても、デプロイしたオペレーティングシステムに正常に起動するようになりました。
この修正は、ironic.drivers.modules.drac.management の ironic integrated Dell Remote Access Controller (iDRAC) 管理ハードウェア実装 (「idrac」) 機能により管理されるサーバーに適用されます。

PowerEdge 12 世代以前のサーバーについてはバグは解決されていませんが、BIOS ブートモードは引き続きサポートされます。

今回の更新以前は、サーバーのブートモードが BIOS に設定されている場合にしか、それ以降のリブートでブートデバイスが維持されませんでした。
今回の更新では、「neutron」ネットワークインターフェースを使用したマルチテナントベアメタルネットワーク設定が導入されています。

「neutron」ネットワークインターフェースを使用してベアメタルノードを設定すると、ベアメタルノードでのプロビジョニングとテナントトラフィック用に、独立した VLAN ネットワークを使用することができます。
本リリース以前は、ironic-conductor ハッシュリングコードに競合状態が存在していました。動作中ハッシュリングを None に設定することはできますが、これにより内部サーバーエラー「'NoneType' object has no attribute '__getitem__'」が発生していました。本リリースでは競合状態が修正され、ironic API 操作がエラー「'NoneType' object has no attribute '__getitem__'」で失敗することはなくなりました。
今回の更新で、アプリケーションの認証情報を作成して、アプリケーションの keystone に対する認証を許可できるようになりました。

https://docs.openstack.org/keystone/latest/user/application_credentials.html を参照してください。
Manilla 用の OpenStack Dashboard (Horizon) プラグインは、プロジェクトクォータ情報を取得できませんでした。そのため、共有ファイルシステムのダッシュボードでファイル共有を作成できず、またレンダリングの問題が生じていました。今回の修正でクォータ情報取得の操作が想定どおりに機能するようになり、共有ファイルシステムを表示してダッシュボードでファイル共有を作成できるようになりました。
linuxbridge ml2 ドライバーを使用している場合、権限のないテナントが IP アドレスを指定せずにポートを作成してそれをアタッチすることができるので、IP アドレスの検証が省略されてしまいます。その後、許可された割り当てプール以外から既存のゲストまたはルーターと競合する IP アドレスが割り当てられると、サービス拒否が発生する可能性があります。
今回の更新で、パケット破棄の削減用に、チューニング可能なオプションが新たに 2 つサポートされるようになりました。

強固なパーティション設定が使用されていても (isolcpus、tuned)、仮想 CPU (vCPU) がハイパーバイザーカーネルスレッドにより占有される場合があります。占有は頻繁ではなく 1 秒あたり数回ですが、virtio キュー 1 つあたりの記述子が 256 であれば、1 回の仮想 CPU 占有が発生しただけでパケットの破棄につながります (占有されている間 256 のスロットが埋まるため)。キュー 1 つあたりのパケットレートが 1 Mpps (1 秒あたり 100 万パケット) を超えているネットワーク機能仮想化 (NFV) の仮想マシンがこのケースです。

今回の更新で、2 つの新しいチューニング可能なオプション (「rx_queue_size」および「tx_queue_size」) がサポートされるようになりました。これらのオプションを使用して virtio NIC の受信キューサイズおよび送信キューサイズを設定し、パケットの破棄を削減します。
Nova の libvirt ドライバーは、ゲスト CPU モデルの設定時に CPU 機能のフラグをより細かく指定できるようになりました。

たとえば、「Meltdown」CVE の修正を適用した後に特定の Intel ベースの仮想 CPU モデルを実行することで生じるゲストパフォーマンスの低下を、この機能により軽減することができます。ゲストのパフォーマンスに対する影響は、CPU 機能フラグ「PCID」(Process-Context ID) をゲスト CPU に公開することによって軽減されます。これは、物理ハードウェア自体で PCID フラグが利用可能であることを前提とします。

CPU フラグのより細かな指定方法についての詳しい情報は、nova.conf の [libvirt]/cpu_model_extra_flags の説明を参照してください。
今回の更新で、libvirt コンピュートドライバーが信頼済み SR-IOV Virtual Function を持つインスタンスの作成を許可するようになりました。信頼済みの場合、ゲストの VF の MAC アドレスを変更するなど特定の操作を実施することができます。

インターフェースをボンディングするためには、すべてのスレーブで同じ MAC アドレスが使用されている必要があります。一方、フェイルオーバー時には VF の 1 つで MAC アドレスの変更が必要になります。MAC アドレスの変更は権限を必要とする操作なので、ゲストでボンディングを正しく設定するためには、該当する VF は信頼済みでなければなりません。

管理者は VF を信頼済みモードに設定できるようになりました。設定するには次の 2 つのステップを実施する必要があります。まず、nova.conf の「[pci] passthrough_whitelist」JSON 設定オプションの「trusted」の値を「true」に設定する必要があります。以下に例を示します。

[pci]
passthrough_whitelist = {"devname": "eth0", "trusted": "true",
                         "physical_network":"sriovnet1"}

次に、ポートの作成時にバインディングプロファイルを「trusted=true」に設定する必要があります。以下に例を示します。

$ neutron port-create <net-id> \
    --name sriov_port \
    --vnic-type direct \
    --binding:profile type=dict trusted=true

信頼済みモードは SR-IOV VF にしか適用されないので、「vnic-type」は「hw_veb」または「direct」のどちらかに設定しなければなりません。
機能:
nova-scheduler への重み付け関数 CPUWeigher の追加

理由:
CPUWeigher により、オペレーターは仮想 CPU をスタックするか分散するかのポリシーを設定することができます。

結果:
オペレーターは CPUWeigher を有効にしてスタックする (まず、1 つのノードの仮想 CPU をすべて使用する) または分散する (すべてのホストからほぼ同数の仮想 CPU を使用する) ポリシーを設定することができます。
今回の更新で、ヒュージページを持つインスタンスを起動する際に、Nova がホストヒュージページの NUMA アフィニティーをスクリーニングするようになりました。Nova は、十分なヒュージページのない NUMA ノードを拒否します。

今回の更新以前は、Nova はホストヒュージページの NUMA アフィニティーをスクリーニングしていませんでした。ホストに十分な NUMA ページがなければ、CPU の数が十分であってもインスタンスは起動に失敗していました。
OpenStack Sahara が Cloudera Distribution Hadoop (CDH) プラグイン 5.13 をサポートするようになりました。
今回の更新で、OpenStack Sahara に s3 互換オブジェクトストアのサポートが追加されました。
QDR をサポートするために、新たな TripleO heat テンプレートが追加されています。
metrics_qdr サービスを有効にするとすべてのオーバークラウドノードに QDR サービスがデプロイされ、各オーバークラウドノード上で動作する collectd サービスからのメトリックデータをルーティングするのに使用されます。

該当する heat テンプレートのパラメーターを以下に示します。

MetricsQdrPort:
default: '5666'
description: Service name or port number on which the qdrouterd will accept connections. This argument must be string, even if the numeric form is used.
type: string
MetricsQdrUsername:
default: 'guest'
description: Username which should be used to authenticate to the deployed qdrouterd.
type: string
MetricsQdrPassword:
default: 'guest'
description: Password which should be used to authenticate to the deployed qdrouterd.
type: string
hidden: true
MetricsQdrConnectors:
default: []
description: Connectors configuration (array of hashes).
type: json
MetricsQdrAddresses:
default:
 - prefix: 'collectd/notify'
   distribution: multicast
 - prefix: 'collectd/telemetry'
   distribution: multicast
description: Addresses configuration (array of hashes).
type: json
MetricsQdrUseSSL:
default: false
description: Set to true if it is required to use SSL or TLS on the connection for listener.
type: boolean
MetricsQdrUseEncryption:
default: false
description: Set to true if it is required to encrypt connection to the peer
for listener.
type: boolean
MetricsQdrSaslMechanisms:
default: 'ANONYMOUS'
description: List of accepted SASL auth mechanisms for listener in format of comma separated list.
type: string
MetricsQdrSslCertDb:
default: ''
description: Path to SSL certificate db for listener.
type: string
MetricsQdrSslCertFile:
default: ''
description: Path to SSL certificate file for listener.
type: string
MetricsQdrSslKeyFile:
default: ''
description: Path to SSL private key file for listener.
type: string
MetricsQdrSslPwFile:
default: ''
description: Path to SSL password file for certificate key for listener.
type: string
MetricsQdrSslPassword:
default: ''
description: SSL password to be supplied for listener.
type: string
MetricsQdrTrustedCerts:
default: ''
description: Path to file containing trusted certificates for listener.
type: string
OvsDpdkMemoryChannels パラメーターは、DPDK パラメーター抽出ワークフローを使用して抽出することができません。デフォルトでは、値は 4 に設定されています。お使いのハードウェアに合わせて、この値をカスタム環境ファイルで変更することができます。
今回の更新以前は、/var/lib/nova/instances の共有ストレージ (nfs 等) の場合、任意のコンピュートノードで nova_compute コンテナーを再起動すると、インスタンスの仮想エフェメラルディスクと console.log の所有者/グループが変更されていました。その結果、インスタンスは仮想エフェメラルディスクにアクセスできなくなり、機能しなくなっていました。
今回の更新で、/var/lib/nova/instances 内のインスタンスのファイルの所有権を変更するメソッドが改善され、必要なファイル/ディレクトリーだけを対象とするようになりました。
nova compute の再起動中にインスタンスのファイルへのアクセスが失われなくなりました。
専用モニターノードのスケールアップやモニターの置き換えによって、stack update コマンドが失敗したり、このコマンドで Ceph モニターがクォーラムから外れたりしなくなりました。
instack_undercloud 機能が非推奨になった後、管理者ユーザーがアンダークラウドをアップグレードすると、アクセス権限エラーで失敗していました。これは、管理者ユーザーに member ロールがなかったためです。今回の修正で、member ロールが puppet-keystone モジュールおよび tripleo-teat-templates から管理者ユーザーに戻されました。
ODL の設定されたコントローラーノードを置き換える場合、従来は、再デプロイメント時に ODL の設定ファイルが見つからないため失敗していました。今回の修正で、/opt/opendaylight/data ディレクトリーがホストからアンマウントされ、これがトリガーになって置き換えプロセス時に ODL の設定ファイルが再生成されるようになりました。
従来 OpenStack director は、ソースバランスではなくラウンドロビンを使用して HAProxy ロードバランシングを設定していたため、スティッキーセッションが失敗していました。今回の修正で、director は HAProxy 設定のロードバランシングにソースバランスを使用するようになり、スティッキーセッションが想定どおりに動作するようになりました。
従来 OpenStack director は、openshift_master_cluster_hostname および openshift_master_cluster_public_hostname パラメーターには必ず IP アドレスを使用していたため、OpenShiftGlobalVariables Heat パラメーターからのホスト名が無視されていました。今回の修正で、director はホスト名が提供されていればホスト名を、提供されていなければ IP アドレスを使用するようになりました。
今回の更新により、ルーティング対応スパイン/リーフ型ネットワークを使用する場合、OSP 14 でそれぞれのロールのノードごとに特定の IP アドレスを設定できるようになりました。

今回の更新以前は、それぞれのノードに特定の IP アドレスを設定できるのは、ルーティング対応スパイン/リーフ型ネットワークを使用しないデプロイメントの場合だけでした。OSP 13 でそれぞれのネットワークに特定の IP アドレスを設定することは可能ですが、ドキュメントおよびテストが不十分だったため、この機能はテクノロジープレビューとして扱われていました。

OSP 14 では、ルーティング対応スパイン/リーフ型ネットワークを使用する場合、それぞれのロールの各ノードのネットワークごとに使用する IP アドレスを選択できるようになりました。これには、同一ネットワーク内のルーティングされた複数サブネットも含まれます。
コンテナー設定およびデプロイメントの失敗を防ぐために、今回の更新で NTP 時刻がデプロイメントプロセスの初期に同期されるようになりました。NTP サーバーにアクセスできず同期できない場合には、デプロイメントは直ちに失敗します。
今回の更新以前は、不明確なエラーメッセージと共にデプロイメントプロセスの遅い段階で失敗していました。
Service Assurance Framework の実装をサポートするために、今回の機能拡張で、メトリックデータをローカルの QPID ディスパッチルーターサービスに送信するように collectd を設定できるようになりました。

新たな collectd TripleO heat テンプレートパラメーターにより、amqp1 書き込みプラグインを設定することができます。
CollectdConnectionType パラメーターを「amqp1」に設定します。
これにより、以下に示すパラメーターで明示的に上書きしない限り、すべてのメトリックデータがローカルの QDR に送信されます。

ローカルの QDR をデプロイするには、環境ファイル /usr/share/openstack-tripleo-heat-templates/environments/metrics-collectd-qdr.yaml を使用します。

該当する heat テンプレートのパラメーターを以下に示します。
CollectdAmqpHost:
type: string
description: Hostname or IP address of the AMQP 1.0 intermediary.
default: nil
CollectdAmqpPort:
type: string
description: >
  Service name or port number on which the AMQP 1.0 intermediary accepts
  connections. This argument must be a string, even if the numeric form
  is used.
default: '5666'
CollectdAmqpUser:
type: string
description: >
  User part of credentials used to authenticate to the AMQP 1.0 intermediary.
default: guest
CollectdAmqpPassword:
type: string
description: >
  Password part of credentials used to authenticate to the AMQP 1.0 intermediary.
default: guest
hidden: true
CollectdAmqpTransportName:
type: string
description: Name of the AMQP 1.0 transport.
default: metrics
CollectdAmqpAddress:
type: string
description: >
  This option specifies the prefix for the send-to value in the message.
default: collectd
CollectdAmqpInstances:
type: json
description: >
  Hash of hashes. Each inner hash represent Instance block in plugin
  configuration file. Key of outer hash represents instance name.
  The 'address' value concatenated with the 'name' given will be used
  as the send-to address for communications over the messaging link.
default: {}
CollectdAmqpRetryDelay:
type: number
description: >
  When the AMQP 1.0 connection is lost, defines the time in seconds to wait
  before attempting to reconnect.
default: 1
CollectdAmqpInterval:
type: number
description: >
  Interval on which metrics should be sent to AMQP intermediary. If not set
  the default for all collectd plugins is used.
default: -666
VNC の tls-everywhere シナリオでは、以下の TLS 接続が存在します。

- クライアント -> HAproxy
- novncproxy -> vnc サーバー (インスタンス)

しかし、HAproxy から nova novncproxy への接続は暗号化されていなかったため、コントローラー上の HAproxy から nova novnc-proxy サービスへのローカル接続は暗号化されていませんでした。今回のリリースで、HAproxy から nova novnc-proxy サービスへの接続が暗号化されるようになりました。
本リリース以前は、nova::compute::libvirt::rx_queue_size/nova::compute::libvirt::tx_queue_size を使用して受送信キューのサイズを設定することができましたが、専用の TripleO heat テンプレートパラメーターはありませんでした。今回のリリースで、以下のようにロールベースで受送信キューのサイズを設定できるようになりました。

parameter_defaults:
ComputeParameters:
NovaLibvirtRxQueueSize: 1024
NovaLibvirtTxQueueSize: 1024

結果的に、rx_queue_size/tx_queue_size は新たなパラメーターを使用して設定されます。
今回の更新で、コンテナー化されたアンダークラウドへの切り替え後、アンダークラウドで gnocchiclient を使用できるようになりました。これにより、ユーザーは Telemetry データをクエリーすることができます。
Ceph ノードに対する設定の更新をブラックリストに登録しても、デプロイメントに失敗しなくなりました。
/var/lib/gnocchi/ ディレクトリーへのアクセス権限が原因で、Gnocchi ファイルバックエンドを設定したオーバークラウドのデプロイに失敗する場合があります。

回避策: オーバークラウドをデプロイする前に、以下のように openstack/tripleo-heat-templates/docker/services/gnocchi-api.yaml ファイルでディレクトリーへのアクセス権限を設定する。

        - path:
            list_join:
              - "/"
              - - {get_param: GnocchiFileBasePath}
                - "tmp"
          owner: gnocchi:gnocchi
          perm: '0600'
          recurse: true
OpenStack Platform director は、Block Storage サービス (cinder) が nova API の要権限部分にアクセスするのに必要な認証データを設定していませんでした。このため、nova の要権限 API を使用するボリュームでの操作 (例: 使用中のボリュームの移行) に失敗していました。今回の更新で、director が cinder に nova の認証データを設定するようになりました。その結果、権限を必要とするボリュームでの操作が正常に機能するようになりました。
containers-prepare-parameter.yaml ファイルの neutron_driver は null です。
そのため、一般的な OSP の更新ガイドに従うと、OSP14 + ODL のマイナーアップデートは失敗します。

回避策:
オーバークラウドを更新する前に、containers-prepare-parameter.yaml の neutron_driver を「odl」に変更します (https://bugzilla.redhat.com/show_bug.cgi?id=1660454 を参照してください)。

この回避策で、OSP14 + ODL のマイナーアップデートが正常に完了します。
今回の更新で、「openstack port list」コマンドの出力にホスト名およびネットワーク名が追加されました。
追加の情報により、Neutron ポートおよび IP アドレスと特定のホストを容易に関連付けられるようになりました。
OSP-director で、他のネットワークに設定するのと同じ手法で、コントロールプレーン (プロビジョニング) ネットワークに特定の IP アドレスを設定できるようになりました。プロビジョニング時に使用される IP アドレスを設定するには、「ctlplane」ネットワークで IP アドレスを設定します (改行区切り)。これらが順番にノードに割り当てられます (コンピュート-0、コンピュート-1、・・・)。

例:

parameter_defaults:
ControllerIPs:
ctlplane:
- 192.168.24.251
ComputeIPs:
ctlplane:
- 192.168.24.252
- 192.168.24.253

使用例については、/usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-ctlplane.yaml のファイルを参照してください。

今回の更新以前は、OSP-director でそれぞれのネットワークの各オーバークラウドノードで使用する IP アドレスは選択できましたが、プロビジョニング用 IP アドレスはランダムでした。今回の更新により、OSP-director ですべてのネットワークでロールごとに特定の IP アドレスを選択できるようになりました。
今回の更新で、cinder ボリュームを作成する際に TripleO がデフォルトボリュームタイプ「tripleo」を割り当てるようになりました。今回の更新以前は、ボリュームタイプが設定されていないため、ボリュームのタイプ変更および移行操作時にエラーが発生していました。
CinderDefaultVolumeType パラメーターを上書きして、cinder のボリュームタイプを変更することができます。
注記: cinder のデフォルトボリュームタイプが手動で設定されている場合には (例: TripleO director 以外で設定)、オーバークラウドノードを更新する際に CinderDefaultVolumeType パラメーターを手動で定義した値に設定してください。これにより、デフォルトボリュームタイプの名前がデフォルト値「tripleo」に変更されなくなります。
今回の変更により、nova_metadata コンテナーで nova-metadata-api が の httpd wsgi 経由で提供されるようになりました。
アップストリームでは、nova-api および nova-metadata-api を含め、すべての WSGI-run サービスについて eventlet の使用を非推奨にする計画です。詳細は、https://review.openstack.org/#/c/549510/ を参照してください。
先にインスタンスを移行せずにコンピュートノードがリブートした場合に、コンピュートノード上のインスタンスが自動的に再起動するように設定できるようになりました。Nova および libvirt-guests エージェントを設定して、インスタンスを安全にシャットダウンし、コンピュートノードのリブート時にインスタンスを起動することができます。

新たなパラメーター:
NovaResumeGuestsStateOnHostBoot (True/False)
NovaResumeGuestsShutdownTimeout (デフォルト: 300 秒)
以前のリリースでは、システムの再起動後に Cinder iSCSI/LVM バックエンドのループバックデバイスが再作成されなかったため、cinder-volume サービスが再起動しませんでした。今回の修正でループバックデバイスを再作成する systemd サービスが追加され、再起動後に Cinder iSCSI/LVM バックエンドが維持されるようになりました。
バケットを持たないグループが原因で、Open vSwitch がデーモンをクラッシュさせていました。今回の更新でコードが変更され、バケットを持たないグループが許容されるようになりました。バケットを持つ/持たないにかかわらず、グループがアサートのトリガーになることが無くなりました。
サービスを再起動すると、内部ポートが別のネットワーク名前空間に移動し、そこで再作成されます。この状況が発生すると、ポートはネットワーク設定を失い、間違ったネットワーク名前空間で再作成されます。今回のリリースでコードが変更され、サービスの再起動時にポートが再作成されなくなり、ポートがネットワーク設定を維持できるようになりました。
一部の OVS バージョンでは、updelay および downdelay ボンディング設定が無視され、常にデフォルト設定が使用されます。
今回のリリースで、Nova の libvirt ドライバーは、CPU モデルの設定時に CPU 機能のフラグをより細かく指定できるようになりました。

「Meltdown」CVE の修正を適用した後に、特定の Intel ベースの仮想 CPU モデルで実行しているゲストのパフォーマンスが低下していました。今回の変更の利点の 1 つは、このパフォーマンス低下が軽減されることです。ゲストのパフォーマンスに対する影響は、CPU 機能フラグ「PCID」(Process-Context ID) を ゲスト CPU に公開することによって軽減されます。これは、物理ハードウェア自体で PCID フラグが利用可能であることを前提とします。

使用方法についての詳しい情報は、nova.conf の [libvirt]/cpu_model_extra_flags の説明を参照してください。
今回の更新で、コンテナー化されたサービスのログローテーションに、デフォルトで logrotate の copytruncate が使用されるようになりました。古いログを保管するデフォルトの期間に変更はありません (14 日間)。
原因: ホスト名を解決する際に、python-amqp が A および AAAA レコードの両方を要求する。

結果: A レコードの取得に成功した場合でも、引き続き AAAA を取得するリクエストが送信されます。リゾルバーが AAAA レコードのリクエストを解決できない場合には、プロセス全体が AAAA リクエストのタイムアウトを待たなければなりません。これにより、名前解決に必要以上の時間がかかり、AMQP メッセージ操作が遅くなったり完全にタイムアウトしたりする場合があります。

修正: A レコードが正しく返された場合には、AAAA レコードを要求しません。取得に成功した A レコードだけが使用されます。

結論: 名前のルックアップが迅速に解決されるようになりました。
OpenStack TripleO Heat テンプレートの一部のバージョンで、Neutron service_plugins パラメーターに誤った設定が含まれていました。そのため、OVN を使用した場合に Octavia が機能しませんでした。本リリースでは openstack-tripleo-heat-templates-9.0.1-0 パッケージにより OVN がアップグレードされ、Octavia がサポートされるようになりました。
以前のリリースでは、eventlet を使用してイベントをスレッド化すると不必要なシステムコールが作成され、REST API のパフォーマンスが低下し、Tempest のタイムアウトエラーが生じていました。今回の修正で REST API コールの応答時間が向上し、Tempest のタイムアウトエラー発生が軽減されるようになりました。
リブート時のシステムのシャットダウンが不適切なため、コンテナーが停止するのを待たないという問題がありました。今回の更新で、この問題が修正されています。
この問題により、コンテナーは安全に停止する前に強制終了されていました。
今回の更新により新たなサービスが追加され、コンテナーが完全に停止するのを待ってから、システムがリブートプロセスを続行するようになりました。
以前のリリースでは、非管理者ユーザーのアクセス権限を確認するためにポリシーファイルに API リクエストを行うと、再度ファイル全体が読み込まれ解析されていました。そのため処理時間が長くなり、パフォーマンスが低下していました。

今回のバグ修正で、ファイルへのクエリーで再度ファイル全体が読み込まれないように、ポリシーファイルをキャッシュする機能が追加されました。ファイルの変更部分だけが再読み込みされ、再解析されるようになりました。
パッケージが以下のバージョンにリベースされました。
python-tempestconf-2.0.0

このリベースで python-tempestconf ツールが大幅なリファクタリングを受け、tempest.conf の生成プロセスが簡素化されました。
このリベースで多くの未対応のバグも修正され、新たなサービスのサポートも追加されました。
新しいリリースに移行することで、tempest ユーザーに多くのメリットがもたらされるようになりました。
詳細は、https://docs.openstack.org/releasenotes/python-tempestconf/unreleased.html#relnotes-2-0-0 で OpenStack のリリースノートを参照してください。
OpenStack director が、オーバークラウドノードのソフトウェア設定に Ansible を使用するようになりました。Ansible によりオーバークラウドのデプロイメントが分りやすく、またデバッグがより簡単になります。Ansible を使用することで、heat とオーバークラウドノード上の heat エージェント (os-collect-config) 間の通信およびソフトウェア設定デプロイメントデータの移動が置き換えられます。

各オーバークラウドノード上で os-collect-config を動作させ heat からデプロイメントデータをポーリングするのに代わって、Ansible のコントロールノードが Ansible インベントリーファイルおよび Playbook とタスクのセットと共に ansible-playbook を実行し、設定を適用します。Ansible のコントロールノード (ansible-playbook を実行するノード) は、デフォルトではアンダークラウドです。
コンテナー化された Ironic サービスに対応するために、--http-boot のデフォルト値が /httpboot から /var/lib/ironic/httpboot に変更されました。
以前のリリースでは、IPMI bootdev コマンドを送信すると、一部のハードウェアでブートデバイスの順序が意図せず変わっていました。そのため、一部のノードが正しい NIC から起動しなくなったり、PXE がどの場所からも起動しなくなったりしていました。

本リリースで、IPMI ドライバーに noop 管理インターフェースが追加されました。このインターフェースがブートコマンドを処理し、bootdev が使用されないようにします。noop インターフェースを準備するには、正しい NIC から PXE ブートモードを試みるようにノードを事前設定し、その後ローカルのハードドライブにフォールバックする必要があります。
今回の更新で、デバッグモードを有効にして応答をレンダリングするとサーバークラッシュを起こすデバッグメッセージの補完に関するバグが修正されています。
パッケージのインストール中、virtualbmc パッケージの RPM 仕様のバグのために、virtualbmc サービスを実行する特殊ユーザーまたはグループが作成されませんでした。今回の更新で RPM の仕様が修正され、ユーザー管理操作が正しく実施されるようになりました。パッケージがインストールされると、virtualbmc サービスが正常に開始されます。
VirtualBMC (VBMC) はサポートされなくなったので、本番環境では使用しないでください。テストの目的であれば、pip を使用して直接 VBMC をインストールすることができます。

リポジトリー名	リポジトリーラベル
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 14 for RHEL 7 (RPMs)	`rhel-7-server-openstack-14-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 14 Operational Tools for RHEL 7 (RPMs)	`rhel-7-server-openstack-14-optools-rpms`

リポジトリー名	リポジトリーラベル
Red Hat Enterprise Linux for IBM Power, little endian	`rhel-7-for-power-le-rpms`
Red Hat OpenStack Platform 14 for RHEL 7 (RPMs)	`rhel-7-server-openstack-14-for-power-le-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"`

Language and Page Formatting Options

Red Hat Training

リリースノート

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

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. Bare Metal サービス

2.3. Ceph Storage

2.4. Compute

2.5. メトリックとモニタリング

2.6. ネットワーク機能仮想化

2.7. OpenStack Networking

2.8. ストレージ

2.9. テクノロジープレビュー

2.9.1. 新規テクノロジープレビュー

第3章 リリースの情報

3.1. Red Hat OpenStack Platform 14 GA

3.1.1. 機能拡張

3.1.2. テクノロジープレビュー

3.1.3. リリースノート

3.1.4. 既知の問題

3.1.5. 非推奨の機能

第4章 テクニカルノート

4.1. RHEA-2019:0045: OpenStack director のバグ修正アドバイザリー

Quick Links

Help

Site Info

Related Sites

Systems Status

About

Red Hat legal and privacy links

Red Hat legal and privacy links

第1章はじめに

第2章最も重要な新機能

第3章リリースの情報

第4章テクニカルノート