2.3. リリース情報 RHOSO 18.0.8

Compute サービスの電源管理機能はデフォルトで無効化される

Compute サービス (nova) の電源管理機能は、デフォルトでは無効になっています。次の nova-compute 設定でこれを有効にできます。

デフォルトのポリシーにより、デプロイメントの最後に nftables が確実にリロードされます

この更新前は、後方互換性を確保するために、iptables のデフォルトテーブルが nftables に追加されていました。しかし、デフォルトの DROP ルールの代わりにデフォルトの ALLOW INPUT ルールがあり、デプロイメントの最後に nftables がリロードされませんでした。この更新により、正しいルールが適用され、デプロイメントの最後に nftables が確実にリロードされます。

データプレーンサービスのデフォルトリストに redhat サービスを手動で追加する

redhat サービスは、データプレーンサービスのデフォルトリストから一時的に削除されました。その結果、コンピュートノードにサブスクリプションまたはリポジトリーをアタッチし、データプレーンシークレットを作成するときにドキュメント化された rhc_* パラメーターを使用すると、ノードは登録されず、データプレーンのデプロイメントは失敗します。

マルチパスブロックストレージを備えたベアメタルデータプレーンノードは、プロビジョニング後に起動します。

この更新前は、事前にビルドされたディスク全体のイメージに device-mapper-multipath パッケージが含まれていなかったため、ペアになったブート RAM ディスクがマルチパスブロックストレージをサポートできませんでした。その結果、マルチパスブロックストレージがあるベアメタルノードは、デプロイメント後に起動できず、緊急シェルでスタックしていました。この更新により、事前にビルドされたディスク全体のイメージには device-mapper-multipath パッケージが含まれ、デプロイされたベアメタルノードでデプロイ後に緊急シェルが発生しなくなりました。

FRR サービスのログが利用可能になりました

この更新前は、RHOSO が BGP による動的ルーティングを使用するように設定されている場合にデータプレーンノードにデプロイされる Free Range Routing (FRR) サービスのログは使用できませんでした。この更新により、これらのログが利用できるようになります。

レガシーの Tripleo Networking サービスは導入後に削除されます

この更新前は、edpm_tripleo_cleanup タスクの後にレガシーの tripleo Networking サービス (neutron) サービスが存在し、これを手動で削除する必要がありました。これらのサービスは導入後に停止されるため、RHOSO サービスは影響を受けませんでした。この更新により、すべての tripleo Networking サービスは、データプレーンノードの導入後に削除されます。

外部 MTU が内部 MTU より大きい場合、パケットは通知されることなくドロップされます

外部 MTU が内部 MTU より大きい場合、RHOSO は想定どおりに north-south パケットを断片化しません。代わりに、Ingress パケットは通知なしにドロップされます。

例

たとえば、外部ネットワーク datacentre の MTU が 1500 であるとします。

ポート更新により、VLAN またはフラットネットワークポートの QoS 情報が削除される。

Egress QoS ポリシールール (最大帯域幅および/または最小帯域幅) を持つすべての VLAN またはフラットネットワークポートは、この情報を Logical_Switch_Port. options ディクショナリーに保存します。ポート名の変更やライブマイグレーションなど、このポートを更新すると、この QoS 情報が削除されます。

Physical Function が仮想マシンインスタンスにアタッチされている場合に導入が失敗する

Physical Function (PF) がインスタンスにアタッチされている場合、os-net-config を再実行すると、os-net-config はホスト内の SR-IOV PF を見つけることができず、デプロイメント、更新または導入が失敗します。

SELinux が有効な場合、NetworkManager-dispatcher スクリプトの実行が失敗する

os-net-config 設定ツールは、ドライバーバインディングに NetworkManager-dispatcher スクリプトを使用します。SELinux が有効になっている場合、これらのスクリプトは実行に失敗し、os-net-config ネットワークのデプロイメントは失敗します。

失敗したサービス更新は、デプロイメントステータスに正確に反映されます

この更新前は、サービス設定の更新が失敗すると、その失敗はデプロイメントの状態ステータスに反映されませんでした。代わりに、更新により作成された新しい Pod はデプロイメントの準備状況の確認時に考慮されないため、Ready 状態が True と表示されました。この更新により、設定の更新中に作成された新しい Pod は、デプロイメントの準備状況の評価時に考慮されるようになりました。新しい Pod のロールアウトに失敗すると、それを反映してデプロイメントは Deployment in progress でスタックしていることが示されます。

マイナー更新中はコントロールプレーンが一時的に利用できない

マイナー更新中、RHOSO コントロールプレーンは一時的に利用できなくなります。API リクエストは、エラー 500 などの HTTP エラーコードで失敗する可能性があります。または、API リクエストは成功しても、基礎となるライフサイクル操作が失敗する可能性があります。たとえば、マイナー更新中に openstack server create コマンドで作成された仮想マシン (VM) は、ACTIVE 状態に到達しません。コントロールプレーンの停止は一時的なものであり、マイナー更新が完了すると自動的に回復します。コントロールプレーンの停止は、すでに実行中のワークロードには影響しません。

生成された CA バンドルはデータプレーンノードにインストールされます

この更新前は、RHOSO コントロールプレーンによって生成された CA バンドルは、デプロイ済みまたは実行中のサービスのデータプレーンノードにデプロイされていましたが、データプレーンノード自体に CA バンドルとしてインストールされませんでした。CA バンドルには、Satellite にアクセスするためなど、カスタムサードパーティー CA ファイルを含めることができます。この更新により、CA バンドルがデータプレーンノードにインストールされます。