第3章 リリースの情報

今回の更新以前は、Leapp のアップグレードを実行する前に、director は Red Hat Ceph Storage OSD に noout フラグを設定していませんでした。その結果、アップグレード後に OSD がバランスをとり直すのに追加の時間が必要でした。

今回の更新により、ディレクターは Leapp のアップグレード前に noout フラグを設定するようになり、これによりアップグレードプロセスが迅速化されました。また、director は Leapp のアップグレード後に noout フラグの設定を解除します。

PowerMax 設定オプションは、OSP10 newton から変更されています。今回の更新により最新の PowerMax 設定オプションが追加され、iSCSI ドライバーと FC ドライバーの両方がサポートされるようになりました。

CinderPowermaxBackend パラメーターも、複数のバックエンドをサポートします。CinderPowermaxBackendName はバックエンドのリストをサポートし、新しい CinderPowermaxMultiConfig パラメーターを使用して各バックエンドのパラメーター値を指定することができます。構文の例は、environments/cinder-droidmc-powermax-config.yaml を参照してください。

今回の更新以前は、IPv6 内部 API ネットワークを使用した DCN と HCI の組み合わせのデプロイメントでは、Block Storage サービス (cinder) および etcd サービスは不適切な etcd URI で設定され、Block Storage サービスおよび etcd サービスが起動時に失敗していました。

今回の更新により、etcd URI の IPv6 アドレスが正しくなり、Block Storage サービスおよび etcd サービスが正常に起動するようになりました。

今回の更新以前は、IPv6 内部 API ネットワークを使用したデプロイメントでは、Block Storage サービス (cinder) および Compute サービス (nova) は不適切な glance-api エンドポイントの URI で設定されていました。その結果、DCN またはエッジデプロイメントの Block Storage サービスおよび Compute サービスは、Image サービス (glance) にアクセスできませんでした。

今回の更新により、glance-api エンドポイントの URI の IPv6 アドレスが正しくなり、エッジサイトの Block Storage サービスおよび Compute サービスが正しく Image サービスにアクセスできるようになりました。

今回の更新以前は、Block Storage サービス (cinder) は、ボリューム種別を指定する代替方法を無視して volume create 要求のデフォルトボリューム種別を割り当てていました。

今回の更新により、Block Storage サービスが正しく機能するようになりました。

今回の更新以前は、Bare Metal Provisioning サービス (ironic) の直接デプロイインターフェイスを使用して最終的なインスタンスイメージをダウンロードする際に、リトライやタイムアウトがありませんでした。その結果、イメージをホストするサーバーが応答に失敗すると、デプロイメントに失敗する可能性がありました。

今回の更新により、イメージのダウンロードプロセスに 60 秒の接続タイムアウトが設定され、リトライを 2 回試みます。

ipmitool-1.8.18-11 にリグレッションが生じ、Get Cipher Suites をサポートしない特定の BMC の場合、IPMI アクセスに 2 分以上の時間がかかっていました。その結果、イントロスペクションに失敗し、デプロイメントにかかる時間が以前よりも大幅に長くなる可能性がありました。

今回の更新により、ipmitool のリトライ処理が変更され、イントロスペクションにパスし、デプロイメントに成功するようになりました。

今回の更新以前は、ExtraConfigPre per_node スクリプトは Python 3 と互換性がありませんでした。その結果、オーバークラウドのデプロイメントは、TASK [Run deployment NodeSpecificDeployment] のステップで SyntaxError: invalid syntax のメッセージと共に失敗していました。

今回の更新により、ExtraConfigPre per_node スクリプトが Python 3 と互換性を持ち、カスタムの per_node hieradata をプロビジョニングできるようになりました。

今回の更新以前は、ceph osd stat -f json コマンドが返すデータ構造の形式が変更されていました。その結果、一定の割合の Red Hat Ceph Storage (RHCS) OSD が実行されていない限りデプロイメントを停止する検証が正常に機能せず、動作中の OSD の数にかかわらずデプロイメントを停止していました。

今回の更新により、新しいバージョンの openstack-tripleo-validations が動作中の RHCS OSD の割合を正しく計算し、定義した割合の RHCS OSD が実行されていない場合に、デプロイメントが早期に停止するようになりました。パラメーター CephOsdPercentageMin を使用して、動作していなければならない RHCS OSD の割合をカスタマイズすることができます。デフォルト値は 66% です。検証を無効にするには、このパラメーターを 0 に設定します。

今回の更新以前は、Red Hat Ceph Storage ダッシュボードが無効であっても、ダッシュボードリスナーが HA Proxy 設定に作成されていました。その結果、Ceph Storage を使用する Red Hat OpenStack Platform のアップグレードに失敗する可能性がありました。

今回の更新によりサービス定義が更新され、Ceph MGR サービスをダッシュボードサービスと区別し、ダッシュボードサービスが有効でなければ設定されないようになりました。これにより、アップグレードが正常に実行されます。

今回の更新以前は、NFS 共有がマウントされていると、Leapp のアップグレードに失敗する場合がありました。特に、Compute サービス (nova) または Image サービス (glance) を実行するノードで NFS マウントが使用されている場合、これらのノードがハングアップしていました。

今回の更新により、Leapp のアップグレード前に、director は /var/lib/nova/instances、/var/lib/glance/images、および GlanceNodeStagingUri パラメーターで定義する Image サービスのステージングエリアをアンマウントするようになりました。

今回の機能拡張により、openstack tripleo container image push コマンドに、ソースレジストリーの認証情報を指定するための新しいオプションが追加されています。新しいオプションは --source-username および --source-password です。

今回の更新以前は、認証を必要とするソースレジストリーからコンテナーイメージをプッシュする際に、認証情報を指定できませんでした。この場合、コンテナーをプッシュする唯一の方法は、イメージを手動でプルし、ローカルシステムからプッシュすることでした。

今回の機能拡張で、Red Hat OpenStack Platform ノードにポリシーベースのルーティングを使用できるようになりました。これにより、os-net-config で複数のルーティングテーブルおよびルーティングルールを設定することができます。

複数のリンクを持つホストでは、ポリシーベースのルーティングはルーティングテーブルを使用し、送信元のアドレスに応じて特定のインターフェイス経由でトラフィックを送信することができます。インターフェイスごとにルーティングルールを定義することもできます。

今回の更新で、undercloud.conf ファイルの container_images_file パラメーターが必須のオプションになりました。アンダークラウドをインストールする前に、このパラメーターを設定する必要があります。

コンテナーソースに registry.redhat.io を使用する昨今の変更により、コンテナーを取得する際に認証が必要となります。アンダークラウドについては、container_images_file が、インストール実行時に認証情報を指定するための推奨オプションです。この更新以前は、このパラメーターが設定されていないと、コンテナーの取得を試みる際に認証エラーでデプロイメントが失敗していました。

今回の機能拡張により、新たな 2 つのパラメーター NovaPMEMMappings および NovaPMEMNamespaces を使用して、vPMEMEM を管理できるようになりました。

NovaPMEMMappings を使用して、vPMEM と物理 PMEM 名前空間の間のマッピングを反映する nova 設定オプション pmem_namespaces を定義します。

NovaPMEMNamespaces を使用して、vPMEM のバックエンドとして使用する物理 PMEM 名前空間を作成および管理します。

Red Hat OpenStack Platform 16.1 では、ML2/OVS メカニズムドライバーを使用するルーティング対応プロバイダーネットワークがテクノロジープレビューとして提供されます。ルーティング対応プロバイダーネットワークを使用すると、1 つのプロバイダーネットワークを有効にして、複数のレイヤー 2 ネットワーク (ブロードキャストドメイン) またはセグメントに対応することができます。これにより、オペレーターはユーザーに対して 1 つのネットワークだけを提供することができます。これは、エッジ DCN デプロイメントおよびスパイン/リーフ型ルーティング対応データセンターデプロイメントの一般的なネットワーク種別です。

Compute サービス (nova) スケジューラーはセグメントを認識しないため、それぞれのリーフ、ラックセグメント、または DCN エッジサイトを Compute サービスのホストアグリゲートまたはアベイラビリティーゾーンにマッピングする必要があります。デプロイメントで DHCP またはメタデータサービスが必要な場合には、それぞれのエッジサイトまたはセグメントに Compute サービスのアベイラビリティーゾーンを定義する必要もあります。

既知の制限

glance イメージの変換メソッドとして、glance-direct はデフォルトでは有効ではありません。この機能を有効にするには、glance-api.conf ファイルの DEFAULT セクションで、enabled_import_methods を [glaince-direct,web-download] または [glaince-direct] に設定します。

glance-direct インポートメソッドを使用する場合、Image サービス (glance) にはステージングエリアが必要です。glance-api.conf ファイルの DEFAULT セクションで、node_staging_uri オプションを file://<absolute-directory-path> に設定します。このパスは、すべての Image サービス API ノードからアクセス可能な共有ファイルシステム上になければなりません。

Red Hat OpenStack Platform (RHOSP) 13 DCN から RHOSP 16.1 DCN にアップグレードする場合、単一スタックの RHOSP 13 デプロイメントからマルチスタックの RHOSP 16.1 デプロイメントに移行することはできません。RHOSP 13 スタックは、RHOSP 16.1 にアップグレードした後も引き続き Orchestration サービス (heat) の単一スタックとして管理されます。

RHOSP 16.1 にアップグレードした後に、新たな DCN サイトを新規スタックとしてデプロイすることができます。詳細は、RHOSP 16.1 DCN のマルチスタックに関するドキュメントを参照してください。

Red Hat OpenStack Platform 16.1 では、以下のように PowerMax ドライバーが更新されています。

機能の更新:

sg-bridge コンテナーは、sg-bridge RPM を使用して sg-core の AMQP1/unix 間のソケットインターフェイスを提供します。どちらのコンポーネントも Service Telemetry Framework の一部です。

これは、sg-bridge コンポーネントの初期リリースです。

sg-bridge および sg-core コンテナーイメージは、Service Telemetry Framework に collectd メトリックのの新しいデータパスを提供します。

sg-bridge コンポーネントは AMQP1/unix 間のソケット変換を sg-core に提供します。その結果、従来の Smart Gateway コンポーネントに比べて 500% パフォーマンスが向上します。

これは、sg-bridge および sg-core コンテナーイメージコンポーネントの初期リリースです。

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

回避策: OS::TripleO::Services::NeutronDhcpAgent を OS::TripleO::Services::NeutronDhcpAgent: deployment/neutron/neutron-dhcp-container-puppet.yaml に変更します。

Red Hat OpenStack Platform Load-balancing サービス (octavia) インスタンス (amphora) の keepalived インスタンスが、異常な状態で終了して UDP トラフィックを中断する可能性があります。この問題の原因は、UDP ヘルスモニターのタイムアウト値が短すぎることです。

回避策: 新しいタイムアウト値として 2 秒を超える値を指定します (例: $ openstack loadbalancer healthmonitor set --timeout 3 <heath_monitor_id>)。

詳細は、コマンドラインインターフェイスの参考ドキュメントで loadbalancer healthmonitor を検索してください。

16.0 から 16.1 に更新する際に、Orchestration サービス (heat) の TLS 定義が不完全で、更新に失敗します。

この失敗を防ぐには、パラメーターおよび値を InternalTLSCAFile: '' と設定する必要があります。

パブリック TLS または TLS-Everywhere が使用されている場合、16.0 から 16.1 への更新に失敗する既知の問題があります。

パラメーター InternalTLSCAFile は、オーバークラウドインスタンスの CA 証明書バンドルの場所を定義します。このパラメーターが正しく設定されていないと、アップグレードおよび更新に失敗します。新規デプロイメントでは、heat がこのパラメーターを正しく設定しますが、古い heat テンプレートを使用するデプロイメントをアップグレードする場合、デフォルト値が正しくない可能性があります。

回避策: アンダークラウドがデフォルトのトラストストアの証明書を使用するように、InternalTLSCAFile パラメーターを空の文字列 '' に設定します。

RHOSP 13 から RHOSP 16.1 にアップグレードする際に、既知の問題があります。HostnameFormatDefault の値が %stackname%-compute-%index% から %stackname%-novacompute-%index% に変更されています。このデフォルト値の変更により、サービスエントリーが重複し、さらにライブマイグレーション等の操作に影響を及ぼす可能性があります。

回避策: RHOSP 13 から RHOSP 16.1 にアップグレードする場合、HostnameFormatDefault の値を上書きして以前のデフォルト値を設定し、以前のホスト名の形式が維持されるようにしなければなりません。RHOSP 15 または RHOSP 16.0 からアップグレードする場合は、特別な対応は必要ありません。

RHOSP 16.1 では、tripleo-ansible-inventory の出力形式が変更されました。これにより、generate-inventory ステップで失敗します。

回避策: インベントリーを手動で作成します。

アンダークラウドが外部の (パブリック) エンドポイントに接続して初期リソースおよびプロジェクトを作成する際に、デプロイメント時に heat パラメーター InternalTLSCAFile が使用されるという既知の問題があります。内部インターフェイスとパブリックインターフェイスの証明書が異なる認証局 (CA) からの証明書である場合、デプロイメントに失敗します。アンダークラウドが keystone パブリックインターフェイスへの接続に失敗するか、内部インターフェイスが不適切な設定を受け取ります。

IPA サーバーは内部インターフェイスを提供するが、パブリックインターフェイスがオペレーターの提供する証明書を持つ場合に、このシナリオは TLS Everywhere が設定されたデプロイメントに影響を及ぼします。また、既存のパブリック証明書が設定されたデプロイメントが TLS Everywhere の再デプロイおよび設定を試みるブラウンフィールドデプロイメントも阻害されます。

現在、この問題に対する回避策はありません。

以下の条件により、Block Storage サービス (cinder) には既知の問題があります。

Object Storage サービス (swift) には既知の問題があります。事前にデプロイされたノードを使用する場合、/var/log/containers/stdouts/swift_rsync.log に以下のエラーメッセージが記録される場合があります。

failed to create pid file /var/run/rsyncd.pid: File exists

回避策: 事前にデプロイされているすべてのコントローラーノードで以下のコマンドを入力します。

for d in $(podman inspect swift_rsync | jq '.[].GraphDriver.Data.UpperDir') /var/lib/config-data/puppet-generated/swift; do sed -i -e '/pid file/d' $d/etc/rsyncd.conf; done

python3-tripleoclient を更新またはアップグレードすると、Ansible は更新またはアップグレードを受け取らず、Ansible または ceph-ansible のタスクが失敗します。

更新またはアップグレードする際は、Playbook タスクが正常に実行されるように Ansible も更新を受け取るようにしてください。

ovn-controller が生成するパケットに対する OVN フィルターには既知の問題があります。OVN の ACL 処理を受信するルーター広告は、このトラフィックを許可する明示的な ACL ルールがない場合にドロップされます。

回避策: 以下のコマンドを入力してセキュリティールールを作成します。

openstack security group rule create --ethertype IPv6 --protocol icmp --icmp-type 134 <SECURITY_GROUP>

OVS OFFLOAD デプロイメント時の VF LAG モード、SRIOV Switchdev モードの Mellanox ConnectX-5 アダプターカードには、いくつか既知の制限事項があります。

Mellanox ConnectX-5 アダプターカードを OVS OFFLOAD デプロイメント時の Virtual Function (VF) リンクアグリゲーショングループ (LAG) 設定、SRIOV Switchdev モードで使用した場合、以下に示す既知の問題および制限事項に当面する可能性があります。

dashboard_protocol パラメーターがヒートテンプレートから不適切に削除されたため、現在 Ceph Dashboard は TLS Everywhere のフレームワークでは機能しません。その結果、HAproxy の起動時にバックエンドが表示されません。

一時的なソリューションとしては、Dashboard_protocol パラメーターが含まれる新しい環境ファイルを作成し、-e オプションを使用してその環境ファイルをオーバークラウドデプロイメントに追加します。

parameter_defaults:
  CephAnsibleExtraConfig:
    dashboard_protocol: 'https'

このソリューションにより、ceph-ansible のバグが生じます。詳細は、BZ#1860815 を参照してください。

強制的なシャットダウン後に、Ceph コンテナーがシステムのリブート時に自動的に起動しないという既知の問題があります。

回避策: podman rm コマンドを使用して、古いコンテナー ID を手動で削除します。詳細は、https://bugzilla.redhat.com/show_bug.cgi?id=1858865#c2 を参照してください。

ゲスト仮想マシン内で realtime-virtual-host tuned プロファイルを有効にすると、スループットが低下し、予測不可能なパフォーマンスを示すという既知の問題があります。ovs-dpdk PMD は、ハウスキーピング用の CPU に不適切に固定されます。

回避策: ゲスト仮想マシン内で cpu-partitioning tuned プロファイルを使用し、tuned.conf ファイルを更新するデプロイメント後のスクリプトを作成し、ノードをリブートしてください。

ps_blacklist=ksoftirqd.*;rcuc.*;rcub.*;ktimersoftd.*;.*pmd.*;.*PMD.*;^DPDK;.*qemu-kvm.*

Red Hat OpenStack Platform(RHOSP)13 から RHOSP 16.1 への Fast Forward Upgrade(FFU) 中に、hugepages パラメーターの値などの TRIPLEO_HEAT_TEMPLATE_KERNEL_ARGS を変更すると、カーネル引数のエントリーが重複しているため、アップグレードが失敗します。

FFU 中にカーネル引数を変更することは回避してください。

回避策: RHOSP 16.1 では、通常 /usr/share/ansible/roles/tripleo-kernel/tasks/kernelargs.yml で、カーネル引数を手動で変更することができます。