3.2.2. 既知の問題
現時点における Red Hat OpenStack Platform の既知の問題は以下のとおりです。
- BZ#1769880
- ML2/OVS から OVN への移行に失敗するという既知の問題があります。この失敗は、Red Hat OpenStack Platform director の新たな保護メカニズム (メカニズムドライバーを変更している間はアップグレードを拒否する) によるものです。
回避策については、『Networking with Open Virtual Network』の「Preparing for the migration」を参照してください。https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/16.0/html/networking_with_open_virtual_network/migrating-ml2ovs-to-ovn#preparing_for_the_migration
- BZ#1790467
- 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"`
このコマンドでは、ノード を単一ノード（例： compute-0）、すべてのコンピュートノード（例： compute*）、または 「all」 にすることができます。
ovn_metadata_agent サービスを再起動すると、サービスは更新された haproxy ラッパースクリプトを使用し、起動時に仮想マシンにメタデータを提供できます。回避策を適用した後、再起動後にすでに実行されている影響を受ける仮想マシンが正常に動作します。
- BZ#1793440
-
Red Hat OpenStack 16.0 には、エージェントが実際に存続し、クラウドが機能していると、
openstack network agent listintermittently コマンドで OVN エージェントがダウンしていることを示しているという既知の問題があります。
該当するエージェントは、OVN Controller エージェント、OVN Metadata エージェント、および OVN Controller Gateway エージェントです。
現在、この問題に対する回避策はありません。「openstack network agent list」コマンドの出力を無視します。
- BZ#1795165
- OpenStack Networking (neutron) には、作成されたすべてのインスタンスが、内部 DNS に設定された dns_domain の値ではなく、ネットワークに関連付けられた dns_domain の値を継承するという既知の問題があります。
この問題の原因は、ネットワークの dns_domain 属性が neutron の dns_domain 設定オプションを上書きすることです。
この問題を回避するには、内部 DNS 機能を使用する場合は、ネットワークの dns_domain 属性を設定しないでください。
- BZ#1795688
neutron_api サービスがコントローラーノード上の Placement サービスにアクセスできるようにします。たとえば Novacontrol ロールを使用する場合には、以下の hieradata 設定をコントローラー環境ファイルに追加します。
service_config_settings: placement: neutron::server::placement::password: <Nova password> neutron::server::placement::www_authenticate_uri: <Keystone Internal API URL> neutron::server::placement::project_domain_name: 'Default' neutron::server::placement::project_name: 'service' neutron::server::placement::user_domain_name: 'Default' neutron::server::placement::username: nova neutron::server::placement::auth_url: <Keystone Internal API URL> neutron::server::placement::auth_type: 'password' neutron::server::placement::region_name: <Keystone Region>
Puppet を使用してロール用 hieradata をカスタマイズする方法は、https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/16.0/html-single/advanced_overcloud_customization/index#sect-Customizing_Puppet_Configuration_Data を参照してください。
注記： この設定は、Placement が neutron_api と同じノードで実行されないカスタムロールでオーバークラウドをデプロイする場合に必要です。
- BZ#1797892
-
Red Hat OpenStack Platform 16.0 には、ハードシャットダウンが発生した場合にハードシャットダウンが発生した場合に、ノードの再起動時に podman の
Created状態にコンテナーを実行するという既知の問題があります。
回避策として、以下の Ansible コマンドを実行して Created 状態のすべての haproxy コンテナーをクリーンアップできます。
ansible -b <nodes> -i /usr/bin/tripleo-ansible-inventory -m shell -a "podman ps -a --format {{'{{'}}.ID{{'}}'}} -f name=haproxy,status=created | xargs podman rm -f || :"
< ;nodes& gt; をインベントリーからの単一ホスト、ホストのグループ、または すべて のものに置き換えます。このコマンドを実行すると、metadata-agent は指定されたネットワーク用に新しいコンテナーを生成します。
- BZ#1802573
- マイナーアップデート中に Mistral コンテナーが再起動せず、10 時間後に更新の準備がタイムアウトするという既知の問題があります。
回避策として、コンテナーを手動で再起動します。
- BZ#1804848
- 以下の条件がすべて存在する場合に、既知の問題が存在します。
(0)OpenStack Train リリース（またはマスター（Usuri 開発）からのコード）を使用している。
(1)cinder_encryption_key_id および cinder_encryption_key_deletion_policy は nova.conf の non_inheritable_image_properties 設定に含まれていません。これらのプロパティーはデフォルトで含まれません。
(2)ユーザーが Block Storage サービス(cinder)に暗号化されたボリューム種別のボリュームを作成しています。たとえば、volume-1 です。
(3)Block Storage サービスを使用して、ユーザーは暗号化されたボリュームを Image サービス(glance)にアップロードした。例： Image-1
(4)Compute サービス(nova)を使用して、ユーザーがイメージから直接サーバーをブートしようとしました。注記： これはサポートされていないアクションで、サポートされるワークフローはイメージを使用して boot-from-volume を使用します。
(5)サポートされていないアクションですが、ユーザーが(4)であると、現在サーバーのステータスが ACTIVE になりますが、オペレーティングシステムが見つからない場合は使用できなくなります。
(6)Compute サービスを使用すると、ユーザーは使用不可能なサーバーで createImage アクションを要求するので、Image-2 が作成されます。
Image サービスを使用すると、ユーザーは Image-1 から cinder_encryption_key_* プロパティーを継承し、暗号化キーが削除されている Image-2 を削除します。
その結果、Image-1 は暗号不可能でレンダリングされ、通常の boot-from-volume ワークフローで使用できなくなります。
この問題を回避するには、nova.conf の [DEFAULT] セクションの non_inheritable_image_properties オプションに cinder_encryption_key_id,cinder_encryption_key_deletion_policy プロパティーを追加します。Image-2 は削除でき、Image-1 で使用される暗号化キーは引き続き利用できます。
