第4章 テクニカルノート

本章には、コンテンツ配信ネットワークからリリースされる Red Hat OpenStack Platform「Train」のエラータアドバイザリーの補足情報を記載します。

4.1. RHEA-2020:0283: Red Hat OpenStack Platform 16.0 の一般提供アドバイザリー

本項に記載するバグは、アドバイザリー RHEA-2020:0283 で対応しています。このアドバイザリーについての詳しい情報は、「RHEA-2020:0283 - Product Enhancement Advisory」を参照してください。

ディストリビューションコンポーネントに対する変更:

  • Red Hat OpenStack Platform 16.0 では、Telemetry サービスの一部である ceilometer クライアント (RHOSP の以前のリリースで非推奨となっていた) はサポートされなくなり、廃止されています。ceilometer は、エージェントのみのサービスとして引き続き RHOSP の一部である点に注意してください (クライアントおよび API は非対応)。(BZ#1518222)

openstack-cinder コンポーネントに対する変更:

  • 以前のリリースでは、Red Hat Ceph Storage を Block Storage サービス (cinder) ボリュームとバックアップ両方のバックエンドとして使用している場合には、初回のフルバックアップを実行した後は、フルバックアップを試みても警告が表示されることなく差分バックアップが実行されていました。Red Hat OpenStack Platform 16.0 のテクノロジープレビュー機能により、この問題が修正されました。(BZ#1375207)
  • Red Hat OpenStack Platform Block Storage サービス (cinder) は、ボリュームのクローン時に暗号鍵を自動的に変更するようになりました。Red Hat Ceph Storage を cinder バックエンドとして使用している場合には、現在、この機能はサポートされない点に注意してください。(BZ#1545700)

openstack-glance コンポーネントに対する変更:

  • 以前のリリースでは、暗号化された Block Storage サービス (cinder) ボリュームイメージが削除されても、対応する鍵は削除されませんでした。

    Red Hat OpenStack Platform 16.0 では、この問題が解決されています。Image サービスが cinder ボリュームイメージを削除すると、そのイメージの鍵も削除されます。(BZ#1481814)

  • Red Hat OpenStack Platform 16.0 では、イメージを事前にキャッシュするテクノロジープレビューが Image サービス (glance) に追加されています。これにより、オペレーターはインスタンスをブートする前にキャッシュを温めることができます。(BZ#1706896)

openstack-heat コンポーネントに対する変更:

  • Red Hat OpenStack Platform Orchestration サービス (heat) に、新たなリソースタイプ OS::Glance::WebImage が追加されました。このリソースタイプは、Glance v2 API を使用して URL から Image サービス (glance) のイメージを作成するのに使用します。この新しいリソースタイプは、以前の OS::Glance::Image に置き換わるものです。(BZ#1649264)

openstack-keystone コンポーネントに対する変更:

  • keystone において、Red Hat OpenStack Platform director のデプロイメント後にシステムに存在するデフォルトロールの基本セット (例: admin、member、および reader) がサポートされるようになりました。これらのデフォルトロールは、すべての認可ターゲット (例: システム、ドメイン、およびプロジェクト) について、デフォルトの director ポリシーに組み込まれています。(BZ#1228474)

openstack-manila コンポーネントに対する変更:

  • Red Hat OpenStack Platform 16.0 では、IPv6 が CephFS NFS ドライバーで機能するように、Shared File Systems サービス (manila) にテクノロジープレビュー機能が追加されています。(BZ#1575079)

openstack-neutron コンポーネントに対する変更:

  • Linux ブリッジ ML2 ドライバーおよびエージェントを使用する Red Hat OpenStack Platform デプロイメントは、アドレス解決プロトコル (ARP) スプーフィングに対して保護されません。Red Hat Enterprise Linux 8 に含まれる Ethernet bridge frame table 管理 (ebtables) のバージョンは、Linux ブリッジ ML2 ドライバーと互換性がありません。

    Linux ブリッジ ML2 ドライバーおよびエージェントは Red Hat OpenStack Platform 11 で非推奨になりました。したがって、使用すべきではありません。

    Red Hat では、その代わりに ML2 Open Virtual Network (OVN) ドライバーおよびサービス (Red Hat OpenStack Platform director によりデプロイされるデフォルト) の使用を推奨します。(BZ#1779221)

  • TCP、UDP、または Floating IP アドレスのその他のプロトコルポートから、TCP、UDP、または neutron ポートの Fixed IP アドレスのいずれかに関連付けられたその他のプロトコルポートに、トラフィックを転送できるようになりました。転送されたトラフィックは、neutron API に対する機能拡張および OpenStack Networking プラグインにより管理されます。Floating IP アドレスには、複数の転送定義を設定することができます。ただし、すでに OpenStack Networking ポートと関連のある IP アドレスのトラフィックを転送することはできません。転送することができるのは、ネットワーク上の集中ルーター (レガシー、HA、および DVR+HA) によって管理される Floating IP アドレスのトラフィックだけです。

    Floating IP アドレスのポートのトラフィックを転送するには、以下の OpenStack Networking プラグインコマンドを使用します。

    openstack floating ip port forwarding create
    --internal-ip-address <internal-ip-address>
    --port <port>
    --internal-protocol-port <port-number>
    --external-protocol-port <port-number>
    --protocol <protocol>
    <floating-ip>

    --internal-ip-address <internal-ip-address>: 転送されたトラフィックを受信する neutron ポートの内部 Fixed IP アドレス (IPv4)。

    --port <port>: 転送されたトラフィックを受信する neutron ポートの名前または ID。

    --internal-protocol-port <port-number>: 転送されたトラフィックを受信する neutron ポート Fixed IP アドレスのプロトコルポート番号。

    --external-protocol-port <port-number> トラフィックの転送元である Floating IP アドレスのポートのプロトコルポート番号。

    --protocol <protocol>: Floating IP アドレスのポートが使用するプロトコル (例: TCP、UDP)。

    <floating-ip>: トラフィックの転送元であるポートの Floating IP (IP アドレスまたは ID)。

    以下に例を示します。

    openstack floating ip port forwarding create \ --internal-ip-address 192.168.1.2 \ --port f7a08fe4-e79e-4b67-bbb8-a5002455a493 \ --internal-protocol-port 18343 \ --external-protocol-port 8343 \ --protocol tcp \ 10.0.0.100 (BZ#1749483)

openstack-nova コンポーネントに対する変更:

  • 今回の機能拡張により、NUMA トポロジーが設定されたインスタンスのライブマイグレーションがサポートされるようになりました。以前のリリースでは、この操作はデフォルトで無効でした。この操作は、回避措置として enable_numa_live_migration 設定オプションを使用して有効にすることができましたが、この設定オプションはデフォルトでは False に設定されていました。このようなインスタンスのライブマイグレーションを実施すると、ベースとなる NUMA ゲスト/ホスト間のマッピングやリソース使用状況をまったく更新せずに、インスタンスが移行先ホストに移動されるためです。新たな NUMA 対応ライブマイグレーション機能により、移行先ホストがインスタンスに適さない場合には、別の移行先ホストでライブマイグレーションが試みられます (要求に代替ホストが設定されている場合)。移行先ホストがインスタンスに適する場合には、新たなホストを反映するために NUMA ゲスト/ホスト間のマッピングが再計算され、そのリソース使用状況が更新されます。(BZ#1222414)
  • 今回の機能拡張により、SR-IOV ベースの neutron インターフェースが設定されたインスタンスのライブマイグレーションがサポートされるようになりました。neutron SR-IOV インターフェースは、直接モードと間接モードという 2 つのカテゴリーにグループ分けすることができます。直接モードの SR-IOV インターフェースは、ゲストに直接接続され、ゲスト OS に公開されます。間接モードの SR-IOV インターフェースは、ゲストと SR-IOV デバイス間に macvtap 等のソフトウェアインターフェースを持ちます。この機能により、間接モードの SR-IOV デバイスを持つインスタンスの透過的なライブマイグレーションが可能になります。ライブマイグレーション中にハードウェアの状態をコピーする一般的な方法がないため、直接モードの移行はゲストに対して透過的ではありません。直接モードのインターフェースの場合には、既存の休止/再開のワークフローを模擬します。たとえば、SR-IOV デバイスを使用する場合には、移行前に直接モードのインターフェースの接続を解除し、移行後に再度接続します。その結果、ライブマイグレーションの可能なインターフェースとのボンディングをゲスト内に作成しない限り、直接モードの SR-IOV ポートを持つインスタンスでは、移行中にネットワーク接続が失われます。

    以前のリリースでは、SR-IOV ベースのネットワークインターフェースが設定されたインスタンスのライブマイグレーションを行うことはできませんでした。ホストのメンテナンス等にライブマイグレーションが頻繁に使用されているため、このことが問題となっていました。以前のリリースでは、コールドマイグレーションでインスタンスを移行する必要がありましたが、ゲストにダウンタイムが発生していました。

    今回の機能拡張により、SR-IOV ベースのネットワークインターフェースが設定されたインスタンスのライブマイグレーションが可能になりました。(BZ#1360970)

  • Red Hat OpenStack Platform 16.0 では、ネットワークインターフェースの作成時に、QoS の最小帯域幅ルールを指定できるようになりました。今回の機能拡張により、利用可能なネットワーク帯域幅として指定した値が、インスタンスに対して保証されるようになりました。現在、サポートされている操作は、サイズ変更およびコールドマイグレーションだけです。(BZ#1463838)
  • インスタンスの再ビルド時に NUMATopologyFilter が無効になるようになりました。以前のリリースではこのフィルターが常に実行され、新たなイメージおよび既存フレーバーを使用する第 2 のインスタンス用にホストに十分な追加容量がある場合に限り、再ビルドは成功していました。これは適切ではない不必要な動作でした。(BZ#1775246)
  • インスタンスレベルで PCI NUMA アフィニティーを設定できるようになりました。この機能は、SR-IOV ベースのネットワークインターフェースを持つインスタンスに NUMA アフィニティーを設定する際に必要です。以前のリリースでは、NUMA アフィニティーは PCI パススルーデバイスに対してホストレベルでしか設定することができませんでした。(BZ#1775575)
  • 今回の機能拡張により、以下のパラメーターを使用して、同じコンピュートノードで専用の (ピニングされた) インスタンスと共有の (ピニングされていない) インスタンスをスケジューリングできるようになりました。

    • NovaComputeCpuDedicatedSet: ピニングされたインスタンス CPU のプロセスをスケジューリングすることができる物理ホスト CPU 番号のコンマ区切りリストまたは範囲。非推奨となった NovaVcpuPinSet パラメーターに置き換わるものです。
    • NovaComputeCpuSharedSet: vCPU インベントリーを提供するのに使用される物理ホスト CPU 番号のコンマ区切りリストまたは範囲。ピニングされていないインスタンスをスケジューリングすることができるホスト CPU を定義し、共有エミュレータースレッドポリシー hw:emulator_threads_policy=share が設定されたインスタンスのエミュレータースレッドをオフロードするホスト CPU を定義します。注記: このオプションは従来から存在していましたが、その用途がこの機能により拡張されています。

      ホストアグリゲートを使用して、これらのインスタンス種別が別個のホスト上で実行されるようにする必要がなくなりました。また、[DEFAULT] reserved_host_cpus 設定オプションは不要になり、未設定にすることができます。

      アップグレードするには、以下を実行します。

    • これまでピニングされたインスタンス用に使用されていたホストの場合には、NovaVcpuPinSet の値を NovaComputeCpuDedicatedSet に変更する必要があります。
    • これまでピニングされていないインスタンス用に使用されていたホストの場合には、NovaVcpuPinSet の値を NovaComputeCpuSharedSet に変更する必要があります。
    • NovaVcpuPinSet に値が設定されていない場合には、実行中のインスタンスの種別に応じて、すべてのホストコアを NovaComputeCpuDedicatedSet または NovaComputeCpuSharedSet のどちらかに割り当てる必要があります。

      アップグレードが完了したら、同一のホストで両方のオプションの設定を始めることができます。ただし、そのためには、すべてのインスタンスをホストから移行する必要があります。ピニングされていないインスタンスのコアが NovaComputeCpuSharedSet の一覧に含まれていない場合、またはピニングされたインスタンスのコアが NovaComputeCpuDedicatedSet の一覧に含まれていない場合には、Compute サービスは起動することができないためです。(BZ#1693372)

openstack-octavia コンポーネントに対する変更:

  • Octavia API を使用して VIP アクセス制御リスト (ACL) を作成し、リスナーへの着信トラフィックを、許可されたソース IP アドレス (CIDR) のセットに制限できるようになりました。その他の着信トラフィックは、すべて拒否されます。詳細は、『ネットワークガイド』の「アクセス制御リストを使用したロードバランサーの保護」を参照してください。(BZ#1691025)
  • Red Hat OpenStack Platform 16.0 では、テクノロジープレビューとして Load-balancing サービス (octavia) が UDP プロトコルをサポートするようになりました。(BZ#1703956)

openstack-placement コンポーネントに対する変更:

  • Placement サービスが、Compute (nova) サービスから抽出されるようになりました。このサービスは director によってデプロイおよび管理され、アンダークラウド上およびオーバークラウドのコントローラーノード上で追加コンテナーとして動作します。(BZ#1625244)

openstack-tripleo-common コンポーネントに対する変更:

  • Red Hat OpenStack Platform 16.0 では、テクノロジープレビュー機能の Workflow サービス (mistral) タスクにより、以下の手順に従ってパスワードのローテーションを実装することができます。

    • rotate-password ワークフローを実行し、新しいパスワードを生成してそれをプラン環境に保管する。
    • オーバークラウドを再デプロイする。

      パスワードの変更後にパスワードを取得することもできます。

      パスワードのローテーションを実装するには、以下の手順に従います。

      注記

      ワークフロータスクにより、デフォルトのパスワードが変更されます。このタスクは、ユーザー定義の環境ファイルで指定されたパスワードを変更しません。

      1. 新しいワークフロータスクを実行してパスワードを再生成します。

        $ source ./stackrc
        $ openstack workflow execution create tripleo.plan_management.v1.rotate_passwords '{"container": "overcloud"}'
        This command generates new passwords for all passwords except for BarbicanSimpleCryptoKek and KeystoneFernet* and KeystoneCredential*. There are special procedures to rotate these passwords.
        It is also possible to specify specific passwords to be rotated. The following command rotates only the specified passwords.
        $ openstack workflow execution create tripleo.plan_management.v1.rotate_passwords '{"container": "overcloud", "password_list": ["BarbicanPassword", "SaharaPassword", "ManilaPassword"]}'
      2. オーバークラウドを再デプロイします。

        $ ./overcloud-deploy.sh

        パスワード (新たに生成したパスワードを含む) を取得するには、以下の手順に従います。

      3. 次のコマンドを実行します。

        $ openstack workflow execution create tripleo.plan_management.v1.get_passwords '{"container": "overcloud"}'
        You should see output from the command, similar to the following:
        +--------------------+---------------------------------------------+
        | Field              | Value                                       |
        +--------------------+---------------------------------------------+
        | ID                 | edcf9103-e1a8-42f9-85c1-e505c055e0ed        |
        | Workflow ID        | 8aa2ac9b-22ee-4e7d-8240-877237ef0d0a        |
        | Workflow name      | tripleo.plan_management.v1.rotate_passwords |
        | Workflow namespace |                                             |
        | Description        |                                             |
        | Task Execution ID  | <none>                                      |
        | Root Execution ID  | <none>                                      |
        | State              | RUNNING                                     |
        | State info         | None                                        |
        | Created at         | 2020-01-22 15:47:57                         |
        | Updated at         | 2020-01-22 15:47:57                         |
        +--------------------+---------------------------------------------+
        In the earlier example output, the value of State is RUNNING. State should eventually read SUCCESS.
      4. State の値を再度確認します。

        $ openstack workflow execution show edcf9103-e1a8-42f9-85c1-e505c055e0ed
        +--------------------+---------------------------------------------+
        | Field              | Value                                       |
        +--------------------+---------------------------------------------+
        | ID                 | edcf9103-e1a8-42f9-85c1-e505c055e0ed        |
        | Workflow ID        | 8aa2ac9b-22ee-4e7d-8240-877237ef0d0a        |
        | Workflow name      | tripleo.plan_management.v1.rotate_passwords |
        | Workflow namespace |                                             |
        | Description        |                                             |
        | Task Execution ID  | <none>                                      |
        | Root Execution ID  | <none>                                      |
        | State              | SUCCESS                                     |
        | State info         | None                                        |
        | Created at         | 2020-01-22 15:47:57                         |
        | Updated at         | 2020-01-22 15:48:39                         |
        +--------------------+---------------------------------------------+
      5. State の値が SUCCESS であれば、パスワードを取得することができます。

        $ openstack workflow execution output show edcf9103-e1a8-42f9-85c1-e505c055e0ed
        You should see output similar to the following:
           {
               "status": "SUCCESS",
               "message": {
                   "AdminPassword": "FSn0sS1aAHp8YK2fU5niM3rxu",
                   "AdminToken": "dTP0Wdy7DtblG80M54r4a2yoC",
                   "AodhPassword": "fB5NQdRe37BaBVEWDHVuj4etk",
                   "BarbicanPassword": "rn7yk7KPafKw2PWN71MvXpnBt",
                   "BarbicanSimpleCryptoKek": "lrC3sGlV7-D7-V_PI4vbDfF1Ujm5OjnAVFcnihOpbCg=",
                   "CeilometerMeteringSecret": "DQ69HdlJobhnGWoBC0jM3drPF",
                   "CeilometerPassword": "qI6xOpofuiXZnG95iUe8Oxv5d",
                   "CephAdminKey": "AQDGVPpdAAAAABAAZMP56/VY+zCVcDT81+TOjg==",
                   "CephClientKey": "AQDGVPpdAAAAABAAanYtA0ggpcoCbS1nLeDN7w==",
                   "CephClusterFSID": "141a5ede-21b4-11ea-8132-52540031f76b",
                   "CephDashboardAdminPassword": "AQDGVPpdAAAAABAAKhsx630YKDhQrocS4o4KzA==",
                   "CephGrafanaAdminPassword": "AQDGVPpdAAAAABAAKBojG+CO72B0TdBRR0paEg==",
                   "CephManilaClientKey": "AQDGVPpdAAAAABAAA1TVHrTVCC8xQ4skG4+d5A=="
               }
           }
        (BZ#1600967)

openstack-tripleo-heat-templates コンポーネントに対する変更:

  • nova-compute ironic ドライバーは、BM ノードのクリーンアップ中にノードの更新を試みます。クリーンアップには約 5 分間かかりますが、nova-compute は約 2 分間しかノードの更新を試みません。タイムアウト後、nova-compute は停止し、nova インスタンスを ERROR 状態にします。

    回避策は、nova-compute サービスに以下の設定オプションを定義することです。

    [ironic]
    api_max_retries = 180

    その結果、nova-compute はより長時間 BM ノードの更新を試み続け、最終的に成功します。(BZ#1647005)

  • Red Hat OpenStack Platform 16.0 には、OpenStack インスタンスの設定に必要なメタデータ情報が利用できず、ネットワークに接続されていない状態でインスタンスが起動するという既知の問題があります。

    順序付けの問題が原因で、ovn_metadata_agent の haproxy ラッパーが更新されません。

    クラウドオペレーターが実施することのできる回避策は、更新後に以下の Ansible コマンドを実行して、選択したノードの ovn_metadata_agent を再起動することです。これにより、ovn_metadata_agent は更新バージョンの haproxy ラッパースクリプトを使用するようになります。

    ansible -b <nodes> -i /usr/bin/tripleo-ansible-inventory -m shell -a "status=`sudo systemctl is-active tripleo_ovn_metadata_agent; if test \"$status\" == \"active\"; then sudo systemctl restart tripleo_ovn_metadata_agent; echo restarted; fi"`

    上記の Ansible コマンドで、nodes を単一のノード (例: compute-0)、すべてのコンピュート (例: compute*)、または「all」に設定します。

    ovn_metadata_agent はコンピュートノードで最も一般的に使用されているので、以下の Ansible コマンドにより、クラウド内のすべてのコンピュートノードのエージェントが再起動されます。

    ansible -b compute* -i /usr/bin/tripleo-ansible-inventory -m shell -a "status=`sudo systemctl is-active tripleo_ovn_metadata_agent; if test \"$status\" == \"active\"; then sudo systemctl restart tripleo_ovn_metadata_agent; echo restarted; fi"`

    ovn_metadata_agent サービスを再起動すると、更新された haproxy ラッパースクリプトが使用され、仮想マシンの起動時にメタデータを提供することができます。すでに実行中の問題のある仮想マシンは、回避策の適用後に再起動すると、通常どおりに動作するはずです。(BZ#1790467)

  • Red Hat OpenStack Platform 16.0 director は、マルチコンピュートセルのデプロイメントをサポートするようになりました。今回の機能拡張により、お使いのクラウドのスケールアウトがより容易になります。それぞれの個々のセルはセルコントローラー上に専用のデータベースおよびメッセージキューを持ち、中央のコントロールプレーンの負荷を減らすためです。詳しい情報は、『Instances and Images』の「Scaling deployments with Compute cells」を参照してください。(BZ#1328124)
  • 今回の更新で、OVSDB サーバーへの接続が完全に暗号化されたことから、全 OVN サービス間の通信が完全に暗号化されるようになりました。すべての OVN クライアント (ovn-controller、neutron-server、および ovn-metadata-agent) が、Mutual TLS 暗号化を使用して OVSDB サーバーに接続するようになりました。(BZ#1601926)
  • Red Hat OpenStack Platform 16.0 では、rsyslog の変更に対応することができるように、Orchestration サービス (heat) にテクノロジープレビュー機能が追加されています。

    • rsyslog は、fluentd インストールと機能的に等価となるように、コンテナーログを収集して転送するよう設定されます。
    • 管理者は、fluentd と同じように rsyslog のログ転送を設定することができます。(BZ#1623152)
  • Red Hat OpenStack Platform 16.0 では、director を使用して Block Storage サービス (cinder) バックエンドタイプのアベイラビリティーゾーンを指定できるようになりました。(BZ#1700396)
  • Red Hat OpenStack Platform director により、追加のノードをデプロイできるようになりました。このノードを使用して、デプロイメント中のシステムプロビジョニング用に、さらに Bare Metal Provisioning コンダクターサービスリソースを追加することができます。(BZ#1710093)
  • Red Hat OpenStack Platform 16.0 では、Elastic Compute Cloud (EC2) API はサポートされなくなりました。director では EC2 API のサポートは非推奨になり、今後の RHOSP リリースで廃止される計画です。(BZ#1754560)
  • Red Hat OpenStack Platform 16.0 では、controller-v6.yaml ファイルが廃止されました。controller-v6.yaml で定義されていたルートは、controller.yaml で定義されるようになりました。(controller.yaml ファイルは、roles_data.yaml で設定される値からレンダリングされる NIC 設定ファイルです。)

    以前のバージョンの Red Hat OpenStack Platform director には、2 つのデフォルトルートが含まれていました (外部ネットワーク上の IPv6 用ルートおよびコントロールプレーン上の IPv4 用ルート)。

    両方のデフォルトルートを使用するには、roles_data.yaml のコントローラー定義の default_route_networks に、両方のネットワークが含まれるようにしてください (例: default_route_networks: ['External', 'ControlPlane'])。(BZ#1631508)

  • Red Hat OpenStack Platform 16.0 では、ceph.conf の任意のセクションにカスタム Red Hat Ceph Storage 構成設定を追加できるようになりました。以前のリリースでは、カスタム設定は ceph.conf の [global] セクションにしか追加することができませんでした。(BZ#1666973)
  • Red Hat OpenStack Platform 16.0 では、Orchestration サービス (heat) の新たなデプロイメントパラメーターを利用することができ、管理者はセルコントローラーで nova メタデータサービスを有効にすることができます。

    parameter_defaults:
       NovaLocalMetadataPerCell: True

    この新たなパラメーターにより、セルコンピュートの OVN メタデータエージェントからセルコントローラーがホストする nova メタデータ API サービスに、トラフィックが自動的に転送されます。

    RHOSP トポロジーによっては、セルコントローラーでメタデータサービスを実行する機能により、中央のコントロールプレーンのトラフィックを減らすことができます。(BZ#1689816)

  • Red Hat OpenStack Platform 16.0 では、Orchestration サービス (heat) にテクノロジープレビュー機能が追加されています。新たに追加されたパラメーター NovaSchedulerQueryImageType により、イメージの種別に応じて Compute サービス (nova) の配置およびスケジューラーコンポーネントクエリーの配置が制御されます (scheduler/query_placement_for_image_type_support)。

    true に設定すると (デフォルト)、NovaSchedulerQueryImageType はブート要求で使用されるイメージのディスク形式をサポートしないコンピュートノードを除外します。

    たとえば、libvirt ドライバーはエフェメラルバックエンドに Red Hat Ceph Storage を使用し、qcow2 イメージをサポートしません (非常にコストのかかる変換ステップを経ない場合)。この場合には、NovaSchedulerQueryImageType を有効にすると、スケジューラーは Red Hat Ceph Storage を使用するコンピュートノードには qcow2 イメージをブートする要求を送信しません。(BZ#1710634)

puppet-tripleo コンポーネントに対する変更:

  • Red Hat OpenStack Platform director により、テクノロジープレビュー機能として Redfish API のフェンスエージェントである fence_redfish を利用できるようになりました。(BZ#1699449)

python-django-horizon コンポーネントに対する変更:

  • Red Hat OpenStack Platform 16.0 の Dashboard (horizon) に、ユーザーパスワードの変更用に新たなフォームが追加されました。ユーザーが期限切れのパスワードでサインオンしようとすると、このフォームが自動的に表示されます。(BZ#1628541)

python-networking-ansible コンポーネントに対する変更:

  • Red Hat OpenStack Platform 16.0 では、Arista Extensible Operating System (Arista EOS) スイッチと共に ML2 networking-ansible 機能を設定することができるように、OpenStack Bare Metal サービス (ironic) にテクノロジープレビュー機能が追加されています。詳しくは、『ベアメタルプロビジョニング』の「networking-ansible ML2 機能の有効化」を参照してください。(BZ#1621701)
  • Red Hat OpenStack Platform 16.0 では、スイッチポートを変更してトランクモードに設定し、複数の VLAN をポートに割り当てることができるように、テクノロジープレビュー機能が追加されています。(BZ#1622233)

python-networking-ovn コンポーネントに対する変更:

  • フラグ live_migration_wait_for_vif_plug がデフォルトで有効なので、Red Hat OpenStack Platform 16.0 では、OVN を有効にした状態でライブマイグレーションが成功するようになりました。

    以前のリリースでは、OpenStack Networking (neutron) が vif_plugged の通知を送信するのをシステムが待機するため、ライブマイグレーションに失敗していました。(BZ#1716335)

  • 現時点では、メンバーからデータを取得する際に、OVN ロードバランサーは新しい接続を開始しません。ロードバランサーは送信先アドレスおよびポートを変更し、リクエストのパケットをメンバーに送信します。そのため、IPv4 ロードバランサーアドレスを使用している間、IPv6 メンバーを定義することができません (その逆も同様です)。現在、この問題に対する回避策はありません。(BZ#1734301)

python-novajoin コンポーネントに対する変更:

  • 以前のリリースでは、Novajoin が IPA サーバーへの接続を失うと、直ちに再接続を試みていました。そのため、タイミングの問題が発生し、接続の再確立が妨げられる場合がありました。今回の更新により、retry_delay を使用して、IPA サーバーへの接続をリトライするのを待機する秒数を設定できるようになりました。これにより、タイミングの問題が発生する可能性が低減されると期待されます。(BZ#1767481)

python-oslo-utils コンポーネントに対する変更:

  • 以前のリリースでは、oslo.util ライブラリーの正規表現が更新されておらず、より新しいバージョンのエミュレーター (qemu バージョン 4.1.0) からの出力フォーマットを認識できませんでした。Red Hat OpenStack 16.0 の今回のフィックスにより、正規表現が更新され、oslo.util.imageutils ライブラリーが正しく機能するようになりました。(BZ#1758302)

python-tripleoclient コンポーネントに対する変更:

  • director に overcloud undercloud minion install コマンドが追加されました。このコマンドを使用すると、追加のホストを設定してアンダークラウドサービスを強化することができます。(BZ#1710089)
  • director により、追加のホストをデプロイできるようになりました。このホストを使用して、デプロイメントに関する操作用にさらに heat-engine リソースを追加することができます。(BZ#1710092)
  • Red Hat OpenStack Platform 16.0 では、ローカルレジストリーのイメージをプッシュ、一覧表示、削除、および表示 (メタデータの表示) できるようになりました。

    • イメージをリモートリポジトリーからメインのリポジトリーにプッシュするには、以下のコマンドを実行します。

      $ sudo openstack tripleo container image push docker.io/library/centos
    • リポジトリーの内容を一覧表示するには、以下のコマンドを実行します。

      $ openstack tripleo container image list
    • イメージを削除するには、以下のコマンドを実行します。

      $ sudo openstack tripleo container image delete
    • イメージのメタデータを表示するには、以下のコマンドを実行します。

      $ openstack tripleo container image show (BZ#1545855)
  • アクションが意図せず実行されてしまう可能性を低減するために、今回の機能拡張により、オーバークラウドノードの削除には、アクションを実行する前にユーザーの確認が必要になりました。openstack overcloud node delete <node> コマンドには、アクションを実行する前に y/n の確認が必要です。この確認を省略するには、コマンドラインに --yes を追加します。(BZ#1593057)