リリースノート
このリリースに関連する機能、機能拡張、解決された問題、および既知の問題
概要
第1章 OpenShift AI の概要 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift AI は、人工知能および機械学習 (AI/ML) アプリケーションのデータサイエンティストおよび開発者向けのプラットフォームです。
OpenShift AI は、オンプレミスまたはクラウドで AI/ML モデルとアプリケーションを開発、トレーニング、提供、テスト、監視するための環境を提供します。
OpenShift AI には、データサイエンティスト向けに、Jupyter のほか、モデル開発に必要なツールとライブラリーで最適化されたデフォルトのワークベンチイメージ群、そして TensorFlow および PyTorch フレームワークが含まれています。モデルのデプロイおよびホスト、モデルの外部アプリケーションへの統合、任意のハイブリッドクラウド環境でホストするためのモデルのエクスポートを行います。Docker コンテナーを使用して、データサイエンスパイプラインを備えたポータブル機械学習 (ML) ワークフローを構築することで、OpenShift AI でデータサイエンスプロジェクトを強化できます。グラフィックスプロセッシングユニット (GPU) と Intel Gaudi AI アクセラレーターを使用して、データサイエンスの実験を加速することもできます。
管理者向けに、OpenShift AI は、既存の Red Hat OpenShift または ROSA 環境で、データサイエンスワークロードを有効にします。既存の OpenShift アイデンティティープロバイダーを使用してユーザーを管理し、ワークベンチで利用可能なリソースを管理し、データサイエンティストがモデルの作成、トレーニング、ホストに必要なリソースを確実に入手できるようにします。アクセラレーターを使用するとコストを削減でき、データサイエンティストはグラフィックスプロセッシングユニット (GPU) と Intel Gaudi AI アクセラレーターを使用して、エンドツーエンドのデータサイエンスワークフローのパフォーマンスを向上できます。
OpenShift AI には、次の 2 つのデプロイ方法があります。
- オンプレミスまたはクラウドにインストールできる セルフマネージド型ソフトウェア。OpenShift AI Self-Managed は、OpenShift Container Platform などのセルフマネージド環境、または Red Hat OpenShift Dedicated (AWS または GCP の Customer Cloud Subscription 付き)、Red Hat OpenShift Service on Amazon Web Services (ROSA classic または ROSA HCP)、Microsoft Azure Red Hat OpenShift などの Red Hat が管理するクラウド環境にインストールできます。
Red Hat OpenShift Dedicated (AWS または GCP の Customer Cloud Subscription を使用) または Red Hat OpenShift Service on Amazon Web Services (ROSA classic) にアドオンとしてインストールされる マネージドクラウドサービス。
OpenShift AI Cloud Service の詳細は、Red Hat OpenShift AI の製品ドキュメント を参照してください。
OpenShift AI でサポートされているソフトウェアプラットフォーム、コンポーネント、依存関係の詳細は、ナレッジベースの記事 Red Hat OpenShift AI: サポートされる構成 を参照してください。
2.22 リリースのライフサイクル (フルサポートフェーズ期間を含む) の詳細は、ナレッジベース記事 Red Hat OpenShift AI Self-Managed のライフサイクル を参照してください。
第2章 新機能および機能拡張 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、Red Hat OpenShift AI 2.22 の新機能と機能拡張を説明します。
2.1. 新機能 リンクのコピーリンクがクリップボードにコピーされました!
- モデルサービングランタイムのバージョン情報の表示
この更新により、各モデルサービングランタイムのバージョンを表示できるようになりました。ランタイムバージョンはダッシュボードの次の場所に表示されます。
- Serving runtimes ページ
- Settings の Serving runtimes
- Models and model servers ページの Serving runtimes 列
カスタムランタイムのバージョンは自動的に表示されません。カスタムランタイムのランタイムバージョンを表示するには、ServingRuntime オブジェクトに opendatahub.io/runtime-version をアノテーションとして追加してください。
- ストレージクラスのアクセスモードを選択する機能
- データサイエンスプロジェクトまたはワークベンチにクラスターストレージを追加するときに、管理者の設定に基づいてストレージクラスのアクセスモードを選択できるようになりました。アクセスモードは、ノードがボリュームにアクセスする方法を定義する Kubernetes 設定です。この更新により、ワークベンチの共有データの管理における柔軟性と効率性が向上します。以前は、すべてのストレージクラスのデフォルトが ReadWriteOnce (RWO) に設定されていたため、複数のユーザーが共同作業のために同じストレージクラスを共有することができませんでした。
2.2. 機能拡張 リンクのコピーリンクがクリップボードにコピーされました!
- vLLM コンポーネントのバージョンの更新
OpenShift AI は、記載されている各コンポーネントに対して次の vLLM バージョンをサポートしています。
- vLLM CUDA v0.9.0.1 (FIPS 向けに設計)
- vLLM ROCm v0.8.4.3 (FIPS 向けに設計)
- vLLM Power v0.9.1
- vLLM Z v0.9.1 (FIPS 向けに設計)
vLLM Gaudi v0.7.2.post1
詳細は、GitHub の
vllmを参照してください。
- LLM-as-a-Judge メトリクスのサポートの追加
TrustyAI の LM-Eval で LLM-as-a-Judge メトリクスを使用できるようになりました。大規模言語モデル (LLM) を人間のような評価者として使用し、創造的な文章の評価など、簡単に定量化できない別の LLM の出力品質を評価できます。これは、LLM-as-a-Judge (LLMaaJ) と呼ばれています。
評価例は、LM-Eval の設定例 を参照してください。
- 分散ワークロード: 追加のトレーニングイメージがテストおよび検証済み
次の追加のトレーニングイメージは、テスト済みおよび検証済みです。
CUDA 互換の Ray クラスターイメージ
新しい Ray ベースのトレーニングイメージ
quay.io/modh/ray:2.46.0-py311-cu121がテストおよび検証されました。このイメージは、CUDA 12.1 でサポートされている AMD アクセラレーターと互換性があります。ROCm 互換の Ray クラスターイメージ
ROCm 互換の Ray クラスターイメージ
quay.io/modh/ray:2.46.0-py311-rocm62がテストおよび検証されました。このイメージは、ROCm 6.2 でサポートされている AMD アクセラレーターと互換性があります。
これらのイメージは AMD64 イメージであり、他のアーキテクチャーでは動作しない可能性があります。Red Hat OpenShift AI で利用可能な最新のトレーニングイメージの詳細は、Red Hat OpenShift AI でサポートされる構成 を参照してください。
- OpenShift AI Operator の信頼性の向上
- OpenShift AI Operator が、1 つのインスタンスではなく 3 つのレプリカで実行されるようになり、実稼働ワークロードの回復力と信頼性が向上しました。この機能拡張により、OpenShift AI サービスの中断が低減し、Webhook 操作が複数のインスタンスに分散されます。
- データサイエンスパイプラインにおける Kubeflow Pipelines 2.5.0 のサポート
- データサイエンスパイプラインが Kubeflow Pipelines (KFP) バージョン 2.5.0 にアップグレードされました。詳細は、Kubeflow Pipelines のリリースドキュメント を参照してください。
- ノートブックコントローラーによる Elyra リソースの自動作成
以前は、
elyra-pipelines-<notebook-name> RoleBindingおよびds-pipeline-config Secretリソースがダッシュボードコンポーネントによってプロビジョニングされていました。しかし、このコンポーネントにはコントローラーのライフサイクル管理との統合が欠けていました。また、このような依存関係により、パイプライン機能のみが必要な場合でも、OpenShift AI ダッシュボードをデプロイする必要がありました。このリリースでは、ノートブックコントローラーによってこれらのリソースが自動的に作成されます。そのため、ダッシュボードコンポーネントに依存せずにワークベンチとパイプラインを使用できます。この変更により、セットアップが簡素化され、ライフサイクル管理の一貫性が向上します。
- Seldon MLServer バージョン 1.6.1 ランタイムがテストおよび検証済み
Red Hat は、Seldon MLServer バージョン 1.6.1 ランタイムをテストおよび検証し、一般的な予測 AI モデルとの互換性を向上させました。KServe (REST および gRPC) で次のモデルをテストしました。
- Scikit-learn
- XGBoost
- LightGBM
- CatBoost
- MLflow
- Hugging Face
- モデルレジストリーの Operator 依存関係の削除
OpenShift AI のモデルレジストリーコンポーネントを使用するために、Red Hat Authorino、Red Hat OpenShift Serverless、および Red Hat OpenShift Service Mesh Operator が必要なくなりました。
既存のモデルレジストリーインスタンスは、OpenShift OAuth プロキシー認証を使用するように自動的に移行されます。OpenShift AI ダッシュボードから作成された新しいモデルレジストリーインスタンスは、デフォルトで OAuth プロキシーを使用します。古い
v1alpha1API と Istio 設定を使用して作成された新しいインスタンスは、OAuth プロキシーを使用するように自動的に更新されます。Kubernetes RBAC リソースなど、古いモデルレジストリーインスタンスの既存の認可設定は、引き続き期待どおりに機能します。
第3章 テクノロジープレビュー機能 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、Red Hat OpenShift AI 2.22 のテクノロジープレビュー機能を説明します。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat では、実稼働環境での使用を推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
- プロジェクト内の全パイプラインのキャッシングを無効にする新しいオプション
-
クラスター管理者は、パイプラインサーバー内の全データサイエンスパイプラインのキャッシングを無効にできるようになりました。このグローバル設定は、デバッグ、開発、確定的な再実行が必要な場合などに役立ちます。この設定を適用するには、
DataSciencePipelinesApplication(DSPA) カスタムリソースでspec.apiServer.cacheEnabledフィールドをfalseに設定します。詳細は、データサイエンスパイプラインのキャッシングの概要 を参照してください。
- Kubernetes API を使用したパイプラインの定義および管理
-
Kubernetes API を使用してデータサイエンスパイプラインとパイプラインバージョンを定義および管理できるようになりました。この方法では、パイプラインとパイプラインバージョンが、内部データベースではなくクラスター内のカスタムリソースとして保存されます。このテクノロジープレビュー機能により、OpenShift GitOps (Argo CD) または同様のツールを使用してパイプラインを管理しやすくなります。同時に、引き続き OpenShift AI ユーザーインターフェイス、API、
kfpSDK を使用してパイプラインを管理することもできます。この機能を有効にするには、DataSciencePipelinesApplication (DSPA) カスタムリソースの spec.apiServer.pipelineStore フィールドを kubernetes に設定します。詳細は、Kubernetes API を使用したパイプラインの定義 を参照してください。 - LAB-tuning によるモデルのカスタマイズ
LAB-tuning がテクノロジープレビュー機能として提供され、データサイエンティストは大規模言語モデル (LLM) をカスタマイズするためのエンドツーエンドのワークフローを実行できるようになりました。LAB (Large-scale Alignment for chatBots) メソッドは、タクソノミーガイドによる合成データ生成 (SDG) と多段階のトレーニングアプローチを活用して、従来のファインチューニングに代わるより効率的な方法を提供します。
データサイエンティストは、新しい事前設定済みの InstructLab パイプラインを使用して、OpenShift AI ダッシュボードから直接 LAB-tuning ワークフローを実行できるため、チューニングプロセスが簡素化されます。LAB-tuning の有効化と使用の詳細は、LAB-tuning の有効化 および LAB-tuning を使用したモデルのカスタマイズ を参照してください。
重要LAB-tuning 機能は、現在、非接続環境ではサポートされていません。
- Red Hat OpenShift AI モデルカタログ
Red Hat OpenShift AI モデルカタログがテクノロジープレビュー機能として利用可能になりました。この機能は、ユーザーを Granite ファミリーのモデル、および LAB-tuning で使用される教師モデルとジャッジモデルに接続するところから始まります。
注記モデルカタログ機能は現在、非接続環境ではサポートされていません。
- 新しい Feature Store コンポーネント
Red Hat OpenShift AI Operator で、Feature Store を設定可能なコンポーネントとしてインストールおよび管理できるようになりました。オープンソースの Feast プロジェクトをベースにした Feature Store は、ML モデルとデータ間の橋渡しとして機能し、ML ライフサイクル全体にわたって一貫性のあるスケーラブルな機能管理を可能にします。
このテクノロジープレビューリリースでは、次の機能が導入されています。
- 機能を一貫して再利用できるようにする集中型機能リポジトリー
- ML モデルの特徴量を定義、管理、取得するためのプログラムおよびコマンドライン操作用の Python SDK および CLI
- 機能の定義と管理
- 幅広いデータソースのサポート
- 特徴量の具体化によるデータ取り込み
- オンラインモデル推論とオフラインモデルトレーニングの両方のための特徴量検索
- ロールベースのアクセス制御 (RBAC) による機密機能の保護
- サードパーティーのデータおよびコンピュートプロバイダーとの拡張性と統合
- 企業の ML 要件を満たすスケーラビリティー
- 検索可能な特徴量カタログ
可観測性を高めるデータ系統追跡
設定の詳細は、Feature Store の設定 を参照してください。
- IBM Power および IBM Z アーキテクチャーのサポート
- IBM Power (ppc64le) および IBM Z (s390x) アーキテクチャーがテクノロジープレビュー機能としてサポートされるようになりました。現在、これらのアーキテクチャーでは standard モードでのみモデルをデプロイできます。
- IBM Power および IBM Z アーキテクチャーでの vLLM のサポート
- vLLM ランタイムテンプレートは、テクノロジープレビューとして IBM Power および IBM Z アーキテクチャーで使用できます。
- ノードセレクターを使用して、Red Hat OpenShift AI ダッシュボードの特定ワーカーノードに対するワークベンチのターゲットデプロイメントを有効にします。
ハードウェアプロファイルがテクノロジープレビューとして利用できるようになりました。ハードウェアプロファイル機能を使用すると、ユーザーはワークベンチまたはモデルサービングワークロードの特定のワーカーノードをターゲットにすることができます。これにより、ユーザーは特定のアクセラレータータイプまたは CPU のみのノードをターゲットにすることができます。
この機能は、現在のアクセラレータープロファイル機能とコンテナーサイズセレクターフィールドに代わるもので、さまざまなハードウェア設定を対象とするより幅広い機能セットを提供します。アクセラレータープロファイル、taint、および toleration は、ワークロードをハードウェアにマッチングする機能を提供しますが、特に一部のノードに適切な taint がない場合、ワークロードが特定のノードに配置されるかどうかは保証されません。
ハードウェアプロファイル機能は、アクセラレーターと CPU のみの設定の両方とノードセレクターをサポートします。これにより、特定のワーカーノードのターゲット設定機能が強化されます。管理者は設定メニューでハードウェアプロファイルを設定できます。該当する場合、ユーザーはワークベンチ、モデルサービング、およびデータサイエンスパイプラインの UI を使用して、有効なプロファイルを選択できます。
- Ray クラスターと PyTorchJob 作成のための必須の Kueue ローカルキューラベル付けポリシー
クラスター管理者は、Validating Admission Policy 機能を使用して、Ray クラスターと PyTorchJob リソースに Kueue ローカルキュー識別子を強制的にラベル付けできます。このラベル付けにより、キュー管理ポリシーに基づいてワークロードが適切に分類およびルーティングされるようになり、リソースの競合が防止され、運用効率が向上します。
ローカルキューのラベル付けポリシーが適用されると、Ray クラスターと PyTorchJob はローカルキューを使用するように設定されている場合にのみ作成され、Ray クラスターと PyTorchJob リソースは Kueue によって管理されます。ローカルキューのラベル付けポリシーは、デフォルトではすべてのプロジェクトに適用されますが、一部またはすべてのプロジェクトに対して無効にできます。ローカルキューのラベル付けポリシーの詳細は、ローカルキューの使用の強制 を参照してください。
注記これまで Kueue ローカルキューを使用して Ray クラスターおよび PyTorchJob リソースを管理していなかった場合は、この機能により、重大な変更が生じる可能性があります。
- RStudio Server ワークベンチイメージ
RStudio Server ワークベンチイメージを使用すると、R の統合開発環境である RStudio IDE にアクセスできます。R プログラミング言語は、データ分析と予測をサポートする統計コンピューティングとグラフィックスに使用されます。
RStudio Serverノートブックイメージを使用するには、まずシークレットを作成し、BuildConfig をトリガーしてイメージをビルドします。次に、rstudio-rhel9イメージストリームを編集して OpenShift AI UI でイメージを有効にする必要があります。詳細は、RStudio Server ワークベンチイメージのビルド を参照してください。重要免責事項: Red Hat は、OpenShift AI のワークベンチの管理をサポートしています。ただし、Red Hat は RStudio ソフトウェアのサポートを提供していません。RStudio Server は rstudio.org から入手できます。RStudio Server には RStudio のライセンス条項が適用されます。このサンプルワークベンチを使用する前に、ライセンス条項を確認してください。
- CUDA - RStudio Server ワークベンチイメージ
CUDA - RStudio Server ワークベンチイメージを使用すると、RStudio IDE および NVIDIA CUDA Toolkit にアクセスできます。RStudio IDE は、統計コンピューティングおよびグラフィックス用の R プログラミング言語の統合開発環境です。NVIDIA CUDA Toolkit を使用すると、GPU により高速化されたライブラリーと最適化ツールを使用して作業を強化できます。
CUDA - RStudio Serverワークベンチイメージを使用するには、まずシークレットを作成し、BuildConfig をトリガーしてイメージをビルドします。次に、rstudio-rhel9イメージストリームを編集して OpenShift AI UI でイメージを有効にする必要があります。詳細は、RStudio Server ワークベンチイメージのビルド を参照してください。重要免責事項: Red Hat は、OpenShift AI のワークベンチの管理をサポートしています。ただし、Red Hat は RStudio ソフトウェアのサポートを提供していません。RStudio Server は rstudio.org から入手できます。RStudio Server には RStudio のライセンス条項が適用されます。このサンプルワークベンチを使用する前に、ライセンス条項を確認してください。
CUDA - RStudio Server ワークベンチイメージには、NVIDIA CUDA テクノロジーが含まれています。CUDA のライセンス情報は、CUDA Toolkit のドキュメントで入手できます。このサンプルワークベンチを使用する前に、ライセンス条項を確認してください。
- モデルレジストリー
- OpenShift AI が Model Registry Operator をサポートするようになりました。Model Registry Operator は、テクノロジープレビューモードではデフォルトではインストールされていません。モデルレジストリーは、機械学習モデルの開始からデプロイメントまでに関するメタデータを格納する中央リポジトリーです。
- 非常に大規模なモデルのマルチノードデプロイメントのサポート
- シングルモデルサービングランタイムの使用時に、複数のグラフィカルプロセッシングユニット (GPU) ノードを介してモデルを提供することが、テクノロジープレビュー機能として利用できるようになりました。大規模言語モデル (LLM) などの大規模なモデルをデプロイする際の効率を向上させるには、複数の GPU ノードにモデルをデプロイします。詳細は、複数の GPU ノードにわたるモデルのデプロイ を参照してください。
第4章 開発者プレビュー機能 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、Red Hat OpenShift AI 2.22 の開発者プレビュー機能を説明します。開発者プレビュー機能は、Red Hat ではいかなる形でもサポートされていません。また、機能的には完全ではなく、実稼働環境に対応していません。開発者プレビュー機能を実稼働ワークロードまたはビジネスクリティカルなワークロードには使用しないでください。開発者プレビュー機能は、Red Hat 製品に追加される可能性がある機能をいち早く提供することを目的としています。お客様はこの機能を使用してテストし、開発プロセス中にフィードバックを提供できます。開発者プレビュー機能は、ドキュメントが提供されていない場合があり、随時変更または削除される可能性があります。また、限定的なテストしか行われていません。Red Hat は、関連する SLA なしで、開発者プレビュー機能に関するフィードバックを送信する方法を提供する場合があります。
Red Hat 開発者プレビュー機能のサポート範囲の詳細は、開発者プレビューのサポート範囲 を参照してください。
- Llama Stack 開発者プレビュー: OpenShift AI による生成 AI アプリケーションの構築
このリリースでは、OpenShift AI の Llama Stack 開発者プレビュー機能により、次世代の生成 AI アプリケーションを構築するための Retrieval-Augmented Generation (RAG) とエージェントワークフローが可能になります。この機能は、リモート推論、組み込みのエンベディング、ベクトルデータベース操作をサポートしています。また、安全性を担当する TrustyAI のプロバイダーや、評価を担当する Trusty AI の LM-Eval プロバイダーなどのプロバイダーと統合します。
このプレビューには、Llama Stack Operator を有効にし、RAG ツールを操作し、PDF の取り込みとキーワード検索機能を自動化してドキュメントの検出を強化するためのツール、コンポーネント、ガイダンスが含まれています。
- TrustyAI-Llama Stack の安全性とガードレールの評価の実行
開発者プレビュー機能として、組み込みの LM-Eval コンポーネントと高度なコンテンツモデレーションツールを使用しながら、Llama Stack 上で TrustyAI を使用して評価を実行し、ガードレールを適用できるようになりました。この機能を使用するには、TrustyAI が有効になっていること、FMS Orchestrator とディテクターが設定されていること、および必要に応じて完全な互換性を確保するために KServe RawDeployment モードが使用されていることを確認してください。手動でのセットアップは必要ありません。
その後、Red Hat OpenShift AI Operator の
DataScienceClusterカスタムリソースで、spec.llamastackoperator.managementStateフィールドをManagedに設定します。詳細は、GitHub の次のリソースを参照してください。
- LLM Compressor の統合
LLM Compressor 機能が、開発者プレビュー機能として Red Hat OpenShift AI で利用できるようになりました。
llm-compressorライブラリーを含む新しいワークベンチイメージと対応するデータサイエンスパイプラインランタイムイメージにより、大規模言語モデル (LLM) の圧縮と最適化が容易になり、vLLM を使用した効率的なデプロイメントが可能になります。詳細は、GitHub のllm-compressorを参照してください。LLM コンプレッサーの機能は次の 2 つの方法で使用できます。
-
Red Hat Quay.io:
opendatahub / llmcompressor-workbenchからのワークベンチイメージ Jupyter ノートブックを使用します。
Jupyter ノートブックの例は、red-hat-ai-examplesリポジトリーのexamples/llmcompressor/workbench_example.ipynbを参照してください。 -
データサイエンスパイプラインを実行します。このデータサイエンスパイプラインは、Red Hat Quay.io:
opendatahub / llmcompressor-pipeline-runtimeからのランタイムイメージを使用して、モデル圧縮をバッチプロセスとして実行します。
パイプラインの例は、red-hat-ai-examplesリポジトリーのexamples/llmcompressor/oneshot_pipeline.pyを参照してください。
-
Red Hat Quay.io:
- Kueue での AppWrapper のサポート
- Kueue での AppWrapper のサポートは、開発者プレビュー機能として利用できます。実験的な API により、分散ワークロード機能で AppWrapper ベースのワークロードを使用できます。
第5章 サポートの削除 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、Red Hat OpenShift AI のユーザー向け機能のサポートにおける主な変更を説明します。OpenShift AI でサポートされているソフトウェアプラットフォーム、コンポーネント、依存関係の詳細は、ナレッジベースの記事 Red Hat OpenShift AI: サポートされる構成 を参照してください。
5.1. 非推奨の機能 リンクのコピーリンクがクリップボードにコピーされました!
5.1.1. マルチモデルサービングプラットフォーム (ModelMesh) リンクのコピーリンクがクリップボードにコピーされました!
OpenShift AI バージョン 2.19 以降、ModelMesh をベースとしたマルチモデルサービングプラットフォームは非推奨になりました。引き続きモデルをマルチモデルサービングプラットフォームにデプロイできますが、シングルモデルサービングプラットフォームに移行することが推奨されます。
詳細情報やシングルモデルサービングプラットフォームの使用に関するヘルプは、アカウントマネージャーにお問い合わせください。
5.1.2. Text Generation Inference Server (TGIS) が非推奨に リンクのコピーリンクがクリップボードにコピーされました!
OpenShift AI バージョン 2.19 以降、Text Generation Inference Server (TGIS) は非推奨になりました。TGIS は、OpenShift AI 2.16 EUS ライフサイクルで引き続きサポートされます。Caikit-TGIS および Caikit は影響を受けず、引き続きサポートされます。すぐに使用できるサービングランタイムテンプレートはデプロイされなくなりました。TGIS の代替ランタイムとして vLLM が推奨されます。
5.1.3. アクセラレータープロファイルが非推奨に リンクのコピーリンクがクリップボードにコピーされました!
アクセラレータープロファイルは非推奨になりました。ワークベンチまたはモデルサービングワークロードの特定のワーカーノードをターゲットにするには、ハードウェアプロファイルを使用します。
5.1.4. 非推奨の OpenVINO Model Server (OVMS) プラグイン リンクのコピーリンクがクリップボードにコピーされました!
OpenVINO Model Server (OVMS) の CUDA プラグインは非推奨となり、OpenShift AI の今後のリリースでは使用できなくなります。
5.1.5. OpenShift AI ダッシュボードのユーザー管理が OdhDashboardConfig から Auth リソースに移動された リンクのコピーリンクがクリップボードにコピーされました!
以前は、クラスター管理者は、OdhDashboardConfig リソースの groupsConfig オプションを使用して、OpenShift AI ダッシュボードにアクセスできる OpenShift グループ (管理者と非管理者の両方) を管理していました。OpenShift AI 2.17 以降、この機能は Auth リソースに移動されました。OdhDashboardConfig と対話するワークフロー (GitOps ワークフローなど) がある場合は、代わりに Auth リソースを参照するように更新する必要があります。
| リソース | 2.16 以前 | 2.17 以降のバージョン |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
| Admin groups |
|
|
| User groups |
|
|
5.1.6. 非推奨のクラスター設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
CodeFlare SDK を使用して Red Hat OpenShift AI で分散ワークロードを実行する場合、Ray クラスター設定の次のパラメーターは非推奨となり、示されているように新しいパラメーターに置き換える必要があります。
| 非推奨パラメーター | 後継パラメーター |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
必要に応じて、新しい extended_resource_mapping および overwrite_default_resource_mapping パラメーターを使用することもできます。これらの新しいパラメーターの詳細は、CodeFlare SDK のドキュメント (外部) を参照してください。
5.2. 削除された機能 リンクのコピーリンクがクリップボードにコピーされました!
5.2.1. Embedded サブスクリプションチャネルは一部のバージョンでは使用されない リンクのコピーリンクがクリップボードにコピーされました!
OpenShift AI 2.8 から 2.20 および 2.22 の場合、embedded サブスクリプションチャネルは使用されません。これらのバージョンの Operator の新規インストールでは、embedded チャネルを選択できません。サブスクリプションチャネルの詳細は、Red Hat OpenShift AI Operator のインストール を参照してください。
5.2.2. InstructLab のスタンドアロンスクリプトを削除 リンクのコピーリンクがクリップボードにコピーされました!
Distributed InstructLab トレーニングを実行するためのスタンドアロンスクリプトが削除されました。InstructLab トレーニングフローを実行するには、LAB-tuning テクノロジープレビュー機能を使用します。詳細は、LAB-tuning の有効化 および LAB-tuning を使用したモデルのカスタマイズ を参照してください。
LAB-tuning 機能は現在、非接続環境ではサポートされていません。
5.2.3. Anaconda の削除 リンクのコピーリンクがクリップボードにコピーされました!
Anaconda は、Python および R プログラミング言語のオープンソースディストリビューションです。OpenShift AI バージョン 2.18 以降、Anaconda は OpenShift AI に含まれなくなり、Anaconda リソースは OpenShift AI でサポートまたは管理されなくなりました。
以前に OpenShift AI から Anaconda をインストールした場合は、クラスター管理者は OpenShift コマンドラインインターフェイスから次の手順を実行して、Anaconda 関連のアーティファクトを削除する必要があります。
Anaconda パスワードを含むシークレットを削除します。
oc delete secret -n redhat-ods-applications anaconda-ce-accessAnaconda 検証 cronjob の
ConfigMapを削除します。oc delete configmap -n redhat-ods-applications anaconda-ce-validation-resultAnaconda イメージストリームを削除します。
oc delete imagestream -n redhat-ods-applications s2i-minimal-notebook-anacondaイメージのダウンロードを検証した Anaconda ジョブを削除します。
oc delete job -n redhat-ods-applications anaconda-ce-periodic-validator-job-custom-runAnaconda cronjob の実行に関連するすべての Pod を削除します。
oc get pods n redhat-ods-applications --no-headers=true | awk '/anaconda-ce-periodic-validator-job-custom-run*/'
5.2.4. データサイエンスパイプライン v1 のサポートの削除 リンクのコピーリンクがクリップボードにコピーされました!
これまで、OpenShift AI のデータサイエンスパイプラインは KubeFlow Pipelines v1 をベースにしていました。OpenShift AI 2.9 以降、データサイエンスパイプラインは、異なるワークフローエンジンを使用する KubeFlow Pipelines v2 をベースにしています。OpenShift AI では、デフォルトで Data Science Pipelines 2.0 が有効化され、デプロイされます。
OpenShift AI 2.16 以降、Data Science Pipelines 1.0 リソースは OpenShift AI によってサポートまたは管理されなくなりました。ダッシュボードまたは KFP API サーバーから、Data Science Pipelines 1.0 に基づくパイプラインの詳細をデプロイ、表示、または編集することはできなくなりました。
OpenShift AI は、既存の Data Science Pipelines 1.0 インスタンスを 2.0 に自動的に移行しません。OpenShift AI 2.16 以降にアップグレードする場合は、既存の Data Science Pipelines 1.0 インスタンスを手動で移行する必要があります。詳細は、Data Science Pipelines 2.0 への移行 を参照してください。
Data Science Pipelines 2.0 には、Argo Workflows のインストールが含まれています。Red Hat は、この Argo Workflows インストールの、お客様による直接使用をサポートしていません。Data Science Pipelines 2.0 を備えた OpenShift AI 2.16 以降をインストールまたはアップグレードするには、クラスターに Argo Workflows がインストールされていないことを確認してください。
5.2.5. Elyra パイプラインで実行される Python スクリプトのパイプラインログは S3 に保存されない リンクのコピーリンクがクリップボードにコピーされました!
Elyra パイプラインで実行されている Python スクリプトのログは、S3 互換ストレージに保存されなくなりました。OpenShift AI バージョン 2.11 以降では、OpenShift AI ダッシュボードのパイプラインログビューアーでこれらのログを表示できます。
この変更を有効にするには、バージョン 2024.1 以降のワークベンチイメージで提供される Elyra ランタイムイメージを使用する必要があります。
古いバージョンのワークベンチイメージがある場合は、プロジェクトワークベンチの更新 の説明に従って、Version selection フィールドを互換性のあるワークベンチイメージバージョン (例: 2024.1) に更新します。
ワークベンチイメージバージョンを更新すると、パイプラインの既存のランタイムイメージの選択がすべて消去されます。ワークベンチのバージョンを更新したら、ワークベンチ IDE を開き、パイプラインのプロパティーを更新してランタイムイメージを選択します。
5.2.6. ワークベンチのバージョン 1.2 コンテナーイメージのサポートを終了 リンクのコピーリンクがクリップボードにコピーされました!
ワークベンチを作成するときは、ワークベンチで使用するコンテナーイメージを指定します。OpenShift AI 2.5 以降では、新しいワークベンチを作成するときに、バージョン 1.2 のコンテナーイメージを選択できません。バージョン 1.2 イメージですでに実行されているワークベンチは、引き続き正常に動作します。ただし、Red Hat では、最新のコンテナーイメージを使用するようにワークベンチを更新することを推奨します。
5.2.7. beta サブスクリプションチャネルの使用を終了 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift AI 2.5 以降では、beta サブスクリプションチャネルを使用しなくなりました。Operator の新規インストール用の beta チャネルを選択できなくなりました。サブスクリプションチャネルの詳細は、Red Hat OpenShift AI Operator のインストール を参照してください。
5.2.8. HabanaAI ワークベンチイメージの削除 リンクのコピーリンクがクリップボードにコピーされました!
HabanaAI 1.10 ワークベンチイメージのサポートが削除されました。OpenShift AI バージョン 2.14 以降の新規インストールには、HabanaAI ワークベンチイメージは含まれません。ただし、OpenShift AI を以前のバージョンからアップグレードする場合は、HabanaAI ワークベンチイメージは使用可能なままとなるため、既存の HabanaAI ワークベンチイメージは引き続き機能します。
第6章 解決された問題 リンクのコピーリンクがクリップボードにコピーされました!
以下の注目すべき問題は Red Hat OpenShift AI 2.22.3 で解決されています。Red Hat OpenShift AI 2.22 のセキュリティー更新、バグ修正、機能拡張は、非同期エラータとしてリリースされます。すべての OpenShift AI エラータアドバイザリーは Red Hat カスタマーポータル で公開されています。
6.1. Red Hat OpenShift AI 2.22.3 におけるセキュリティー更新(2025 年 12 月) リンクのコピーリンクがクリップボードにコピーされました!
このリリースではセキュリティー更新が提供されます。更新の完全なリストについては、Red Hat カスタマーポータル の関連するエラータアドバイザリーを参照してください。
6.2. Red Hat OpenShift AI 2.22.1 におけるセキュリティー更新(2025 以上) リンクのコピーリンクがクリップボードにコピーされました!
このリリースではセキュリティー更新が提供されます。更新の完全なリストについては、Red Hat カスタマーポータル の関連するエラータアドバイザリーを参照してください。
6.3. Red Hat OpenShift AI 2.22 で解決された問題 リンクのコピーリンクがクリップボードにコピーされました!
RHOAIENG-26537 - OpenShift AI 2.21 をインストールした後、ユーザーがダッシュボードにアクセスできない
OpenShift AI 2.21 をインストールし、新しいクラスターに DataScienceCluster を作成した後、Auth カスタムリソースがデフォルトのグループ設定なしで作成されるため、ダッシュボードにアクセスできませんでした。この問題は解決されています。
RHOAIENG-26464 - RHOAI 2.21 でデフォルト値を使用すると、メモリー不足のため InstructLab トレーニング phase1 Pod が再起動する
train_memory_per_worker 入力パラメーターのデフォルト値 (100 GiB) を使用して InstructLab パイプラインを実行すると、Pod メモリーが不足するため phase1 のトレーニングタスクが失敗していました。この問題は解決されています。
RHOAIENG-26263 - ワークベンチまたはモデルデプロイメントのハードウェアプロファイルを変更するときにノードセレクターが消去されない
既存のワークベンチまたはモデルのデプロイメントを編集して、ハードウェアプロファイルをノードセレクターを含むものから含まないものに変更すると、以前のノード配置設定を削除できないことがありました。このリリースにより、この問題は解決されました。
RHOAIENG-26099 - 環境変数 HTTP_PROXY と HTTPS_PROXY がノートブックに追加される
以前は、ノートブックコントローラーが、新しく作成され再起動されたすべてのワークベンチに、クラスター全体の OpenShift Proxy 設定を注入していました。このリリースでは、クラスター管理者が ConfigMap を通じてプロキシー設定を有効にしない限り、プロキシー設定は注入されません。
プロキシー設定を有効にするには、次のコマンドを実行します。
oc create configmap notebook-controller-setting-config --from-literal=INJECT_CLUSTER_PROXY_ENV=true -n redhat-ods-applications
$ oc create configmap notebook-controller-setting-config --from-literal=INJECT_CLUSTER_PROXY_ENV=true -n redhat-ods-applications
config map の INJECT_CLUSTER_PROXY_ENV キーへの変更は、odh-notebook-controller Pod が再作成された後にのみ伝播されます。動作を更新するには、該当する Pod を削除するか、デプロイメントのロールアウトを実行する必要があります。
Pod を削除するには、次のコマンドを実行します。
oc delete pod -l app=odh-notebook-controller -A
$ oc delete pod -l app=odh-notebook-controller -A
デプロイメントのロールアウトを実行するには、次のコマンドを実行します。
oc rollout restart -n redhat-ods-applications deployment/odh-notebook-controller-manager
$ oc rollout restart -n redhat-ods-applications deployment/odh-notebook-controller-manager
RHOAIENG-23475 - 非接続環境での IBM Power への推論リクエストがタイムアウトエラーで失敗する
以前は、IBM Power アーキテクチャーを使用して、入力トークンが 100 を超える長いプロンプトを推論サービスに送信すると、推論サービスが応答しませんでした。このリリースにより、この問題は解決されました。
RHOAIENG-20595 - http_proxy 環境変数を定義するとパイプラインタスクの実行が失敗する
パイプラインタスクで http_proxy または https_proxy 環境変数を設定しようとすると、パイプラインタスクの実行が失敗していました。このリリースにより、この問題は解決されました。
RHOAIENG-16568 - JupyterLab ワークベンチからノートブックを PDF としてダウンロードできない
以前は、Jupyter でノートブックを PDF ファイルとしてダウンロードすることができませんでした。このリリースにより、この問題は解決されました。
RHOAIENG-14271 - Jupyter ノートブックを使用した Ray クラスターで異なる Python バージョンを使用すると互換性エラーが発生する
以前は、Jupyter ノートブックで Python バージョン 3.11 を使用して Ray クラスターを作成すると、そのクラスターで Ray バージョン 2.35 と Python バージョン 3.9 の両方を含むワークベンチイメージがデフォルトで使用されていました。これにより、互換性エラーが発生していました。このリリースにより、この問題は解決されました。
RHOAIENG-7947 - KServe でのクエリー中にモデルの提供が失敗する
以前は、ModelMesh コンポーネントをインストールしてマルチモデルサービングプラットフォームを有効にしてから、KServe コンポーネントをインストールしてシングルモデルサービングプラットフォームを有効にすると、シングルモデルサービングプラットフォームにデプロイされたモデルへの推論リクエストが失敗することがありました。この問題は発生しなくなりました。
RHOAIENG-580 (以前は RHODS-9412 として記録されていた問題) - 編集権限を持つユーザーがワークベンチを作成した場合、Elyra パイプラインが実行に失敗する
プロジェクトの編集権限が付与されている場合に、プロジェクトワークベンチを作成すると、次のような動作が見られました。
-
ワークベンチの作成プロセス中に、Kubernetes ロールバインディングの作成に関連する
Error creating workbenchメッセージが表示されていました。 - 上記のエラーメッセージにもかかわらず、OpenShift AI はワークベンチを作成していました。しかし、このエラーメッセージは、そのワークベンチを使用して Elyra データサイエンスパイプラインを実行できないことを意味していました。
ワークベンチを使用して Elyra パイプラインを実行しようとすると、初期化に失敗したことを示す
Error making requestメッセージが Jupyter に表示されていました。このリリースでは、これらの問題は解決されています。
RHOAIENG-24682 - [vLLM-Cuda] FIPS 対応クラスターにモデルをデプロイできない
以前は、FIPS 対応クラスターの NVIDIA アクセラレーターで vLLM NVIDIA GPU ServingRuntime for KServe または vLLM ServingRuntime Multi-Node for KServe ランタイムを使用してモデルをデプロイすると、デプロイメントが失敗する可能性がありました。この問題は解決されています。
RHOAIENG-23596 - IBM Power における、推論サービスに対する長いプロンプトでの推論リクエストがタイムアウトエラーで失敗する
以前は、IBM Power アーキテクチャーを使用して、入力トークンが 100 を超える長いプロンプトを推論サービスに送信すると、推論サービスが応答しませんでした。この問題は発生しなくなりました。
第7章 既知の問題 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、Red Hat OpenShift AI 2.22.3 の既知の問題と、これらの問題を回避する既知の方法を説明します。
RHOAIENG-34218 - TrustyAI は、認証されたすべてのユーザーに任意の namespace の Pod をリストするように指示
TrustyAI コンポーネントは、クラスター上の任意の namespace の Pod を get、list、および watch するためのすべてのサービスアカウントおよびユーザーに付与します。
- 回避策
- OpenShift AI の TrustyAI コンポーネントを "Removed" に設定します。
または、影響を受ける ClusterRole にパッチを適用します。
oc patch clusterrole trustyai-service-operator-lmeval-user-role -p '{"metadata":{"annotations": {"opendatahub.io/managed":"false"}}}'
oc patch clusterrole trustyai-service-operator-lmeval-user-role -p '{"metadata":{"annotations": {"opendatahub.io/managed":"false"}}}'
次に、ロール自体から以下を削除します。
oc edit clusterrole trustyai-service-operator-lmeval-user-role - apiGroups: - "" resources: - pods
oc edit clusterrole trustyai-service-operator-lmeval-user-role
- apiGroups:
- ""
resources:
- pods
RHOAIENG-29731 - OpenShift 4.19 を使用した IBM Power クラスターで推論サービスの作成が失敗する
OpenShift Container Platform バージョン 4.19 上の IBM Power クラスターで vLLM ランタイムを使用して推論サービスを作成しようとすると、Non-Uniform Memory Access (NUMA) に関連するエラーが原因で失敗します。
- 回避策
-
推論サービスを作成するときに、環境変数
VLLM_CPU_OMP_THREADS_BINDをallに設定します。
RHOAIENG-29352 - Documentation および Support メニュー項目がない
OpenShift AI の上部ナビゲーションバーで、ヘルプアイコン (
) をクリックしても、メニューに About メニュー項目しか表示されません。Documentation および Support メニュー項目がありません。
- 回避策
- なし。
RHOAIENG-29292 - IBM Z 上で、使用状況統計ディレクトリーへのアクセスが原因で、vLLM が権限エラーをログに記録する
IBM Z アーキテクチャーで vLLM を実行すると、推論サービスは正常に起動しますが、使用状況統計レポートに関連するバックグラウンドスレッドにエラーが記録されます。これは、サービスがアクセス権限のない制限された場所 (/.config) に使用状況データを書き込もうとするために発生します。
以下のエラーがログに記録されます。
Exception in thread Thread-2 (_report_usage_worker): Traceback (most recent call last): ... PermissionError: [Error 13] Permission denied: '/.config'
Exception in thread Thread-2 (_report_usage_worker):
Traceback (most recent call last):
...
PermissionError: [Error 13] Permission denied: '/.config'
- 回避策
-
このエラーを防止し、使用状況統計のロギングを抑制するには、推論サービスのデプロイメントで
VLLM_NO_USAGE_STATS=1環境変数を設定します。これにより、使用状況の自動レポートが無効になり、システムディレクトリーへの書き込み時に権限の問題が発生するのを回避できます。
RHOAIENG-28910 - 2.16 から 2.19 以降にアップグレードすると、Unmanaged 状態の KServe リソースが削除される
OpenShift AI 2.16 から 2.22 へのアップグレード中に、関連する KServe 関連リソースから所有者参照が完全に削除される前に、FeatureTracker カスタムリソース (CR) が削除されます。その結果、Red Hat OpenShift AI Operator によって最初に Managed 状態で作成され、その後 DataScienceCluster (DSC) カスタムリソース (CR) で Unmanaged に変更されたリソースが、意図せず削除される可能性があります。この問題により、リソースが手動で復元されるまでモデルサービング機能が停止する可能性があります。
次のリソースは、2.16 で Unmanaged に変更された場合、2.22 で削除される可能性があります。
| 種類 | namespace | 名前 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 回避策
OpenShift AI 2.16 から 2.22 にすでにアップグレードしている場合は、次のいずれかの操作を実行してください。
-
既存のバックアップがある場合は、
FeatureTrackerCR への所有者参照なしで削除されたリソースを手動で再作成します。 既存のバックアップがない場合は、Operator を使用して、削除されたリソースを再作成できます。
- 再作成済みのリソースをバックアップします。
DSC で、
spec.components.kserve.serving.managementStateをManagedに設定し、変更を保存して、Operator がリソースを再作成できるようにします。Operator がリソースを再作成するまで待機します。
-
DSC で、
spec.components.kserve.serving.managementStateをUnmanagedに戻し、変更を保存します。 -
再作成された
KnativeServing、ServiceMeshMember、およびGatewayCR リソースに以前のカスタムの変更を再適用します。
まだアップグレードしていない場合は、この問題を防ぐために、アップグレードする前に次の操作を実行してください。
-
DSC で、
spec.components.kserve.serving.managementStateをUnmanagedに設定します。 -
上記の表にリストされている影響を受ける
KnativeServing、ServiceMeshMember、およびGatewayリソースごとに、FeatureTrackerの所有者参照を削除して CR を編集します。この編集により、FeatureTrackerに対するリソースの依存関係が削除され、アップグレードプロセス中にリソースが削除されなくなります。
-
既存のバックアップがある場合は、
NVPE-302、NVPE-303 - NIM モデルのストレージクラスがない
新しくインストールされた OpenShift AI クラスターの NVIDIA Inference Microservice (NIM) モデルサービングプラットフォームに NVIDIA NIM モデルをデプロイしようとすると、Model deployment ページの Storage class ドロップダウンメニューが表示されないか、メニューが表示されないことがあります。これは、OpenShift AI の新規インストールでは、ストレージクラスがユーザーインターフェイスにロードまたはキャッシュされないためです。その結果、デプロイメント用のストレージを設定できなくなります。
- 回避策
- OpenShift AI ダッシュボードから、Settings → Storage classes をクリックします。変更を加えないでください。
- Models → Model deployments をクリックして、NIM モデルデプロイメントを表示します。
- Deploy model をクリックします。
- Model deployment ページには、Storage class ドロップダウンメニューが表示され、使用可能なストレージクラスのオプションが追加されています。
RHOAIENG-27676 - 削除されたケースではアクセラレータープロファイルが正しく動作しない
ワークベンチ、デプロイメント、またはモデルサーバーを作成した後に accelerator プロファイルを削除すると、Edit ページでは既存の設定が使用されず、間違った Accelerator プロファイルが表示されます。
- 回避策
- なし。
RHOAIENG-25734 - ノートブックイメージの名前が重複する問題
ワークベンチ、デプロイメント、またはモデルサーバーを作成した後にワークベンチを削除し、製品スコープとグローバルスコープの両方のイメージストリームに同じ名前を使用すると、ワークベンチの表と Edit workbench フォームにワークベンチの名前が正しく表示されません。
- 回避策
- プロジェクトスコープとグローバルスコープの Accelerator プロファイルに同じ名前を使用しないでください。
RHOAIENG-25733 - アクセラレータープロファイルは重複した名前では正しく動作しない
ワークベンチ、デプロイメント、またはモデルを作成し、プロジェクトスコープの Accelerator プロファイルにグローバルスコープの Accelerator プロファイルと同じ名前を使用すると、Edit ページとサーバーフォームのそれぞれのテーブルとフォームに誤ったラベルが表示されます。
- 回避策
- プロジェクトスコープとグローバルスコープの Accelerator プロファイルに同じ名前を使用しないでください。
RHOAIENG-24545 - 初回の起動後にランタイムイメージがワークベンチに存在しない
ランタイムイメージのリストには、namespace で最初に実行されているワークベンチインスタンスが適切に入力されないため、Elyra パイプラインエディターで選択できるイメージが表示されません。
- 回避策
- ワークベンチを再起動します。ワークベンチを再起動すると、ランタイムイメージのリストがワークベンチと Elyra パイプラインエディターの選択ボックスの両方に表示されます。
RHOAIENG-25090 - モデル登録オプションが無効になっていると、InstructLab の prerequisites-check-op タスクが失敗する
Add model to <model registry name> チェックボックスを選択せずに LAB-tuning 実行を開始すると、InstructLab パイプラインは開始されますが、prerequisites-check-op タスクは失敗し、Pod ログに次のエラーが記録されます。
failed: failed to resolve inputs: the resolved input parameter is null: output_model_name
failed: failed to resolve inputs: the resolved input parameter is null: output_model_name
- 回避策
- LAB-tuning 実行を設定するときに Add model to <model registry name> チェックボックスをオンにします。
RHOAIENG-25056 - ネストされたパイプラインで使用されるオプションの入力パラメーターが設定されていない場合、データサイエンスパイプラインタスクが失敗する
パイプラインにオプションの入力パラメーターがあり、その入力パラメーターの値が指定されておらず、ネストされたパイプラインで使用されると、それらを使用するタスクは次のエラーで失敗します。
failed: failed to resolve inputs: resolving input parameter with spec component_input_parameter:"optional_input": parent DAG does not have input parameter optional_input
failed: failed to resolve inputs: resolving input parameter with spec component_input_parameter:"optional_input": parent DAG does not have input parameter optional_input
- 回避策
- ネストされたパイプラインタスクを使用する場合は、すべてのオプションパラメーターの値を指定します。
RHOAIENG-24786 - 非接続環境で Authorino Operator をテクニカルプレビューから Stable にアップグレードすると失敗する
非接続環境では、Red Hat Authorino Operator をテクニカルプレビューから Stable にアップグレードすると authconfig-migrator-qqttz Pod でエラーが発生して失敗します。
- 回避策
-
Red Hat Authorino Operator を
tech-preview-v1更新チャネルの最新バージョン (v1.1.2) に更新します。 次のスクリプトを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Red Hat Authorino Operator サブスクリプションを更新して、
stable更新チャネルを使用します。 - Authorino 1.2.1 の更新オプションを選択します。
-
Red Hat Authorino Operator を
RHOAIENG-20209 - 要求されたリソースがしきい値を超えても警告メッセージが表示されない
Distributed workloads → Project metrics をクリックし、Requested resources セクションを表示すると、チャートには要求されたリソースの値と各リソースの合計共有クォータ値 (CPU および メモリー) が表示されます。ただし、Requested by all projects の値が、そのリソースの Warning threshold の値を超えると、予想される警告メッセージは表示されません。
- 回避策
- なし。
SRVKS-1301 (以前は RHOAIENG-18590 として文書化されていました) - KServe を無効化にしてから有効化すると、KnativeServing リソースが失敗する
DataScienceCluster で kserve コンポーネントを無効にしてから有効にすると、KnativeServing リソースが失敗する可能性があります。
- 回避策
Knative に関連するすべての
ValidatingWebhookConfigurationおよびMutatingWebhookConfigurationWebhook を削除します。Webhook を取得します。
oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knativeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - KServe が無効になっていることを確認します。
Webhook を取得します。
oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knativeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Webhook を削除します。
- KServe を有効にします。
-
KServe Pod が正常に生成され、
knative-servingnamespace 内の Pod がアクティブで動作していることを確認します。
RHOAIENG-16247 - OpenShift AI ダッシュボードから実行を開始すると、Elyra パイプラインの実行出力が上書きされる
Elyra からパイプラインを作成して実行すると、パイプラインの実行によって生成された出力が、オブジェクトストレージのフォルダー bucket-name/pipeline-name-timestamp に保存されます。
Elyra からパイプラインを作成し、OpenShift AI ダッシュボードからパイプラインの実行を開始すると、タイムスタンプ値が更新されません。これにより、パイプラインの実行によって、同じパイプラインの以前のパイプライン実行によって作成されたファイルが上書きされる可能性があります。
この問題は、OpenShift AI ダッシュボードを使用してコンパイルおよびインポートされたパイプラインには影響しません。これは、オブジェクトストレージで使用されるフォルダーに runid が常に追加されるためです。データサイエンスパイプラインで使用されるストレージの場所の詳細は、データサイエンスパイプラインでのデータの保存 を参照してください。
- 回避策
- Elyra パイプラインにファイルを保存する場合は、パイプライン実行ごとに異なるサブフォルダー名を使用します。
OCPBUGS-49422 - 非接続環境内の AMD GPU および AMD ROCm ワークベンチイメージがサポートされていない
この OpenShift AI リリースでは、非接続環境内の AMD GPU および AMD ROCm ワークベンチイメージはサポートされていません。AMD GPU Operator をインストールするには、GPU ドライバーのコンパイルに必要な依存関係を取得するのにインターネットアクセスが必要であるためです。
- 回避策
- なし。
RHOAIENG-12516 - fast リリースが意図しないリリースチャネルで利用できる
ストリームイメージ配信プロセスに関する既知の問題により、現在、fast リリースは stable や stable-x.y などの意図しないストリーミングチャネルで利用可能です。正確なリリースタイプ、チャネル、サポートライフサイクル情報は、Red Hat OpenShift AI Self-Managed ライフサイクル ページの ライフサイクル日付 表を参照してください。
- 回避策
- なし。
RHOAIENG-8294 - OpenShift AI 2.8 をバージョン 2.10 以降にアップグレードするときに CodeFlare エラーが発生する
OpenShift AI 2.8 をバージョン 2.10 以降にアップグレードしようとすると、AppWrapper カスタムリソース定義 (CRD) バージョンとの不一致により、CodeFlare コンポーネントに関する次のエラーメッセージが表示されます。
ReconcileCompletedWithComponentErrors DataScienceCluster resource reconciled with component errors: 1 error occurred: * CustomResourceDefinition.apiextensions.k8s.io "appwrappers.workload.codeflare.dev" is invalid: status.storedVersions[0]: Invalid value: "v1beta1": must appear in spec.versions
ReconcileCompletedWithComponentErrors DataScienceCluster resource reconciled with component errors: 1 error occurred: * CustomResourceDefinition.apiextensions.k8s.io "appwrappers.workload.codeflare.dev" is invalid: status.storedVersions[0]: Invalid value: "v1beta1": must appear in spec.versions
- 回避策
既存の
AppWrapperCRD を削除します。oc delete crd appwrappers.workload.codeflare.dev
$ oc delete crd appwrappers.workload.codeflare.devCopy to Clipboard Copied! Toggle word wrap Toggle overflow 約 20 秒待ってから、次の例に示すように、新しい
AppWrapperCRD が自動的に適用されることを確認します。oc get crd appwrappers.workload.codeflare.dev NAME CREATED AT appwrappers.workload.codeflare.dev 2024-11-22T18:35:04Z
$ oc get crd appwrappers.workload.codeflare.dev NAME CREATED AT appwrappers.workload.codeflare.dev 2024-11-22T18:35:04ZCopy to Clipboard Copied! Toggle word wrap Toggle overflow
RHOAIENG-7716 - パイプライン条件グループのステータスが更新されない
ループ (dsl.ParallelFor) または条件グループ (dsl.lf) を含むパイプラインを実行すると、パイプラインの実行が完了した後でも、UI にループとグループの実行ステータスが表示されます。
- 回避策
アクティブな子タスクがないことを確認することで、パイプラインがまだ実行中かどうかを確認できます。
- OpenShift AI ダッシュボードから、Data Science Pipelines → Runs をクリックします。
- Project リストから、データサイエンスプロジェクトをクリックします。
- Runs タブから、ステータスを確認する必要があるパイプライン実行をクリックします。
条件グループを展開し、子タスクをクリックします。
子タスクに関する情報を含むパネルが表示されます。
パネルで、Task 詳細タブをクリックします。
Status フィールドに、子タスクの正しいステータスが表示されます。
RHOAIENG-6409 - 実行が成功しても、パイプラインログに Cannot save parameter というエラーが表示される
Data Science Pipelines 2.0 を使用してパイプラインを複数回実行すると、パイプラインの実行が成功してもパイプラインログに Cannot save parameter エラーが表示されます。これらのエラーは無視しても問題ありません。
- 回避策
- なし。
RHOAIENG-12294 (以前は RHOAIENG-4812 として文書化されていました) - 分散ワークロードメトリクスから GPU メトリクスが除外される
この OpenShift AI リリースでは、分散ワークロードメトリクスから GPU メトリクスが除外されます。
- 回避策
- なし。
RHOAIENG-4570 - 既存の Argo Workflows インストールがインストールまたはアップグレードと競合する
Data Science Pipelines 2.0 には、Argo Workflows のインストールが含まれています。Red Hat は、この Argo Workflows インストールの、お客様による直接使用をサポートしていません。Data Science Pipelines 2.0 を備えた OpenShift AI をインストールまたはアップグレードするには、クラスターに Argo Workflows がインストールされていないことを確認してください。詳細は、Data Science Pipelines 2.0 への移行 を参照してください。
- 回避策
-
既存の Argo Workflows インストールを削除するか、
datasciencepipelinesをRemovedに設定してから、インストールまたはアップグレードを続行します。
RHOAIENG-3913 - Red Hat OpenShift AI Operator が、エラーとともに Degraded 条件を False と誤表示する
OpenShift AI Operator が使用する DataScienceCluster (DSC) オブジェクトで KServe コンポーネントを有効にし、依存する Red Hat OpenShift Service Mesh および Red Hat OpenShift Serverless Operators をインストールしていない場合、DSC オブジェクトの kserveReady 条件は、KServe の準備ができていないことを正しく示します。しかし、Degraded 条件には False の値が誤表示されます。
- 回避策
- Red Hat OpenShift Serverless および Red Hat OpenShift Service Mesh Operators をインストールし、DSC を再作成します。
RHOAIENG-3025 - OVMS が要求するディレクトリーレイアウトが KServe StoragePuller レイアウトと競合する
OpenVINO Model Server (OVMS) ランタイムを使用してシングルモデルサービングプラットフォーム (KServe を使用) にモデルをデプロイすると、OVMS が要求するディレクトリーレイアウトと KServe で使用されるモデル取得ロジックのレイアウトの間に不一致が生じます。具体的には、OVMS はモデルファイルを /<mnt>/models/1/ ディレクトリーに配置することを要求しますが、KServe はモデルファイルを /<mnt>/models/ ディレクトリーに配置します。
- 回避策
次の操作を実行します。
-
S3 互換ストレージバケットで、モデルファイルを
1/というディレクトリーに置きます (例:/<s3_storage_bucket>/models/1/<model_files>)。 OVMS ランタイムを使用してシングルモデルサービングプラットフォームにモデルをデプロイするには、次のいずれかの方法を選択して、モデルファイルへのパスを指定します。
-
OpenShift AI ダッシュボードを使用してモデルをデプロイする場合は、データ接続の Path フィールドで、
/<s3_storage_bucket>/models/形式を使用してモデルファイルへのパスを指定します。パスの一部として1/ディレクトリーを指定しないでください。 -
独自の
InferenceServiceカスタムリソースを作成してモデルをデプロイする場合は、storageURIフィールドの値を/<s3_storage_bucket>/models/に設定します。パスの一部として1/ディレクトリーを指定しないでください。
-
OpenShift AI ダッシュボードを使用してモデルをデプロイする場合は、データ接続の Path フィールドで、
-
S3 互換ストレージバケットで、モデルファイルを
KServe は、指定したパスのサブディレクトリーからモデルファイルを取得します。この場合、KServe は S3 互換ストレージの /<s3_storage_bucket>/models/1/ ディレクトリーからモデルファイルを正しく取得します。
RHOAIENG-3018 - KServe 上の OVMS がダッシュボードに正しいエンドポイントを公開しない
OpenVINO Model Server (OVMS) ランタイムを使用してシングルモデルサービングプラットフォームにモデルをデプロイした場合、デプロイしたモデルの Inference endpoint フィールドに表示される URL が不完全なものになります。
- 回避策
-
モデルにクエリーを送信するには、URL の末尾に
/v2/models/_<model-name>_/infer文字列を追加する必要があります。_<model-name>_は、デプロイしたモデルの名前に置き換えてください。
RHOAIENG-2602 - ModelMesh Pod の再起動により、"平均応答時間" のサーバーメトリクスグラフに複数の行が表示される
ModelMesh Pod が再起動されると、平均応答時間 のサーバーメトリクスグラフに複数の行が表示されます。
- 回避策
- なし。
RHOAIENG-2585 - クラスターで UWM が有効になっていない場合、UI にエラー/警告が表示されない
クラスターで User Workload Monitoring (UWM) が 無効化 されている場合、Red Hat OpenShift AI はユーザーに正しく警告しません。UWM は、モデルメトリクスが正しく機能するために必要です。
- 回避策
- ユーザー定義プロジェクトのモニタリングの有効化 の説明に従って、クラスター内で UWM が有効になっていることを手動で確認します。
RHOAIENG-2555 - フォームでサービングランタイムを変更すると、モデルフレームワークセレクターがリセットされない
Deploy model ダイアログを使用してシングルモデルサービングプラットフォームにモデルをデプロイするときに、ランタイムとサポートされているフレームワークを選択した後で別のランタイムに切り替えても、既存のフレームワークの選択がリセットされません。そのため、選択したランタイムでサポートされていないフレームワークを使用してモデルをデプロイできます。
- 回避策
- モデルのデプロイ時に、選択したランタイムを変更する場合は、Select a framework リストを再度クリックして、サポートされているフレームワークを選択してください。
RHOAIENG-2468 - KServe と同じプロジェクト内のサービスが OpenShift でアクセスできなくなる場合がある
シングルモデルサービングプラットフォーム (KServe を使用) にデプロイされたモデルを含むデータサイエンスプロジェクトに OpenShift AI 以外のサービスをデプロイする場合、サービスのアクセシビリティーが、OpenShift クラスターのネットワーク設定の影響を受ける可能性があります。これは、OVN-Kubernetes ネットワークプラグイン をホストのネットワーク namespace と組み合わせて使用している場合に、特に発生しやすくなります。
- 回避策
次のいずれかの操作を実行します。
- シングルモデルサービングプラットフォームにデプロイされたモデルが含まれていない別のデータサイエンスプロジェクトに、サービスをデプロイします。または、別の OpenShift プロジェクトにサービスをデプロイします。
次の例に示すように、サービスが存在するデータサイエンスプロジェクトで、アプリケーション Pod への Ingress トラフィックを受け入れる ネットワークポリシー を追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
RHOAIENG-2228 - 間隔が 15 秒に設定されている場合、パフォーマンスメトリクスグラフが絶えず変化する
モデルメトリクス画面の Endpoint performance タブで、Refresh interval を 15 秒に、Time range を 1 時間に設定すると、グラフの結果は連続的に変化します。
- 回避策
- なし。
RHOAIENG-2183 - エンドポイントのパフォーマンスグラフに間違ったラベルが表示される場合がある
モデルメトリクス画面の Endpoint performance タブで、グラフツールチップに誤ったラベルが表示される場合があります。
- 回避策
- なし。
RHOAIENG-1919 - Model Serving ページが、デプロイメント直後にモデルルート URL の取得または報告に失敗する
OpenShift AI ダッシュボードからモデルをデプロイすると、システムは次の警告メッセージを表示し、モデルの Status 列には OK または緑色のチェックマークが付き、成功したことを示します。
Failed to get endpoint for this deployed model. routes.rout.openshift.io"<model_name>" not found
Failed to get endpoint for this deployed model. routes.rout.openshift.io"<model_name>" not found
- 回避策
- ブラウザーページを更新します。
RHOAIENG-404 - OpenShift AI のダッシュボードで、Enabled ページではなく No Components Found というページがランダムに表示される
Red Hat OpenShift AI ダッシュボードにアクセスすると、No Components Found というページが表示される場合があります。
- 回避策
- ブラウザーのページを更新します。
RHOAIENG-234 - 安全でないクラスターの VSCode で .ipynb ファイルを表示できない
安全でないクラスター内の Google Chrome で code-server workbench イメージを使用する場合、.ipynb ファイルを表示できません。
- 回避策
- 別のブラウザーを使用してください。
RHOAIENG-1128 - ワークベンチに接続されていない永続ボリューム (PV) のサイズを増やそうとすると、不明確なエラーメッセージが表示される
ワークベンチに接続されていない永続ボリューム (PV) のサイズを増やそうとすると、不明確なエラーメッセージが表示されます。
- 回避策
- サイズを増やす前に、PV がワークベンチに接続されていることを確認してください。
RHOAIENG-497 - DSCI を削除すると、OpenShift Service Mesh CR がユーザーへの通知なしに削除される
DSCInitialization リソースを削除すると、OpenShift Service Mesh CR も削除されます。警告メッセージは表示されません。
- 回避策
- なし。
RHOAIENG-282 - 必要なリソースが利用できない場合、ワークロードはディスパッチすべきではない
場合によっては、単一マシンインスタンスに RayCluster を正常にプロビジョニングするために十分なリソースがない場合でも、ワークロードがディスパッチされることがあります。AppWrapper CRD は Running 状態のままであり、関連する Pod は無期限に Pending 状態になります。
- 回避策
- 追加のリソースをクラスターに追加します。
RHOAIENG-131 - InferenceService が Loaded と報告した後、gRPC エンドポイントが適切に応答しない
多数の InferenceService インスタンスが生成され、リクエストがダイレクトされると、Service Mesh Control Plane (SMCP) が応答しなくなります。InferenceService インスタンスのステータスは Loaded ですが、gRPC エンドポイントへの呼び出しはエラーとともに返されます。
- 回避策
-
ServiceMeshControlPlaneカスタムリソース (CR) を編集して、Istio Egress Pod と Ingress Pod のメモリー制限を増やします。
RHOAIENG-130 - モデルが起動されたばかりの場合の同期の問題
KServe コンテナーのステータスが Ready の場合、TGIS コンテナーの準備ができていなくてもリクエストは受け入れられます。
- 回避策
- 数秒待って、すべての初期化が完了し、TGIS コンテナーが実際に準備完了であることを確認してから、リクエストの出力を確認します。
RHOAIENG-3115 - モデルが準備完了として表示された後も数秒間クエリーできない
マルチモデルサービングプラットフォームを使用してデプロイされたモデルは、ダッシュボードに Ready と表示されてもクエリーに応答しない場合があります。モデルエンドポイントにクエリーを実行すると、“Application is not available" という応答が表示されることがあります。
- 回避策
- 30 - 40 秒待ってから、ブラウザーでページを更新します。
RHOAIENG-1619 (以前は DATA-SCIENCE-PIPELINES-165 として記録されていた問題) - S3 バケットが書き込み可能でない場合の不適切なエラーメッセージ
データ接続を設定し、S3 バケットが書き込み可能でない場合にパイプラインをアップロードしようとすると、Failed to store pipelines というエラーメッセージが表示されますが、有用ではありません。
- 回避策
- データ接続の認証情報が正しいこと、および指定したバケットへの書き込みアクセス権があることを確認してください。
RHOAIENG-1207 (以前は ODH-DASHBOARD-1758 として記録されていた問題) - OOTB カスタムサービングランタイムを数回複製するときにエラーが発生する
モデルサービングランタイムを複数回複製すると、複製が失敗し、Serving runtime name "<name>" already exists というエラーメッセージが表示されます。
- 回避策
-
metadata.nameフィールドを一意の値に変更します。
RHOAIENG-1201 (以前は ODH-DASHBOARD-1908 として記録されていた問題) - 空の環境変数でワークベンチを作成できない
ワークベンチを作成するときに、Add variable をクリックしてもリストから環境変数のタイプを選択しないと、ワークベンチを作成できません。このフィールドは必須としてマークされておらず、エラーメッセージも表示されません。
- 回避策
- なし。
RHOAIENG-432 (以前は RHODS-12928 として記録されていた問題) - サポートされていない文字を使用すると、複数のダッシュを含む Kubernetes リソース名が生成される場合がある
リソースを作成し、サポートされていない文字を名前として指定すると、各スペースがダッシュに置き換えられ、他のサポートされていない文字が削除されるため、リソース名が無効になる可能性があります。
- 回避策
- なし。
RHOAIENG-226 (以前は RHODS-12432 として記録されていた問題) - notebook-culler ConfigMap を削除すると、ダッシュボードに Permission Denied と表示される
redhat-ods-applications namespace で notebook-controller-culler-config ConfigMap を削除すると、OpenShift AI ダッシュボードの Cluster Settings ページへの変更を保存できなくなります。保存操作は、HTTP request has failed というエラーで失敗します。
- 回避策
cluster-admin権限を持つユーザーとして以下の手順を実行します。-
ocクライアントを使用して、クラスターにログインします。 次のコマンドを入力して、
redhat-ods-applicationsアプリケーション namespace のOdhDashboardConfigカスタムリソースを更新します。oc patch OdhDashboardConfig odh-dashboard-config -n redhat-ods-applications --type=merge -p '{"spec": {"dashboardConfig": {"notebookController.enabled": true}}}'$ oc patch OdhDashboardConfig odh-dashboard-config -n redhat-ods-applications --type=merge -p '{"spec": {"dashboardConfig": {"notebookController.enabled": true}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
RHOAIENG-133 - 既存のワークベンチは、ワークベンチの再起動後に Elyra パイプラインを実行できない
Elyra JupyterLab エクステンションを使用して JupyterLab 内でデータサイエンスパイプラインを作成および実行し、ワークベンチを作成してワークベンチ内でワークベンチイメージを指定した 後に パイプラインサーバーを設定すると、ワークベンチを再起動した後でもパイプラインを実行できません。
- 回避策
- 実行中のワークベンチを停止します。
- ワークベンチを編集して小さな変更を加えます。たとえば、新しいダミー環境変数を追加したり、既存の不要な環境変数を削除したりします。変更を保存します。
- ワークベンチを再起動します。
- JupyterLab の左側のサイドバーで、Runtimes をクリックします。
- デフォルトのランタイムが選択されていることを確認します。
RHODS-12798 - Pod が "unable to init seccomp" エラーで失敗する
seccomp メモリーリークを引き起こす既知のカーネルバグが原因で、Pod は Running のステータスではなく CreateContainerError ステータスまたは Pending ステータスで失敗します。Pod が失敗した namespace でイベントをチェックするか、oc describe pod コマンドを実行すると、以下のエラーが表示されます。
runc create failed: unable to start container process: unable to init seccomp: error loading seccomp filter into kernel: error loading seccomp filter: errno 524
runc create failed: unable to start container process: unable to init seccomp: error loading seccomp filter into kernel: error loading seccomp filter: errno 524
- 回避策
-
Red Hat ナレッジベースのソリューション記事 Pods failing with error loading seccomp filter into kernel: errno 524 in OpenShift 4 の説明に従って、
net.core.bpf_jit_limitの値を増やします。
KUBEFLOW-177 - OAuth-proxy で転送されないアプリケーションのベアラートークン
アプリケーションの内部認証メカニズムがベアラートークンに基づいている場合、アプリケーションをカスタムワークベンチイメージとして使用できません。OAuth プロキシー設定によりヘッダーからベアラートークンが削除されるため、アプリケーションは適切に動作できなくなります。
- 回避策
- なし。
RHOAIENG-1210 (以前は ODH-DASHBOARD-1699 として記録されていた問題) - すべての設定変更に対してワークベンチが自動的に再起動しない
設定の変更を加えるとワークベンチが再起動されることを示す警告メッセージが、ワークベンチの設定の編集時に表示されます。次の場合、ワークベンチは自動的に再起動しないため、この警告は誤解を招きます。
- 名前を編集する
- 説明を編集する
- 既存の環境変数のキーおよび値を編集、追加、または削除する
- 回避策
- ワークベンチを手動で再起動します。
RHOAIENG-1208 (以前は ODH-DASHBOARD-1741 として記録されていた問題) - 名前が数字で始まるワークベンチを作成できない
名前が数字で始まるワークベンチを作成しようとすると、ワークベンチは起動しません。
- 回避策
- ワークベンチを削除し、文字で始まる名前を付けて新しいワークベンチを作成します。
KUBEFLOW-157: OpenShift AI ダッシュボードからすでにログアウトしている場合、JupyterLab からのログアウトが機能しない
JupyterLab からログアウトする前に OpenShift AI ダッシュボードからログアウトすると、JupyterLab から正常にログアウトされません。たとえば、Jupyter ノートブックの URL がわかっている場合は、これをブラウザーで再度開くことができます。
- 回避策
- OpenShift AI ダッシュボードからログアウトする前に、JupyterLab からログアウトします。
RHODS-9789: データベース名またはユーザー名フィールドにダッシュがあるカスタムデータベースが含まれる場合はパイプラインサーバーは起動に失敗する
カスタムデータベースを使用するパイプラインサーバーを作成する場合、dbname フィールドまたは username フィールドに設定した値にダッシュが含まれていると、パイプラインサーバーは起動に失敗します。
- 回避策
- パイプラインサーバーを編集して、対象のフィールドからダッシュを削除します。
RHODS-7718 - ダッシュボード権限のないユーザーが実行中のワークベンチを無期限に使い続けることができる
Red Hat OpenShift AI 管理者がユーザーの権限を取り消しても、引き続きユーザーは実行中のワークベンチを無期限で使用できます。
- 回避策
- OpenShift AI 管理者がユーザーの権限を取り消す場合、管理者はそのユーザーに対して実行中のワークベンチも停止する必要があります。
RHOAIENG-1157 (以前は RHODS-6955 として記録されていた問題) - ワークベンチを編集しようとするとエラーが発生することがある
ワークベンチの編集時に、以下のようなエラーが発生する可能性があります。
Error creating workbench Operation cannot be fulfilled on notebooks.kubeflow.org "workbench-name": the object has been modified; please apply your changes to the latest version and try again
Error creating workbench
Operation cannot be fulfilled on notebooks.kubeflow.org "workbench-name": the object has been modified; please apply your changes to the latest version and try again
- 回避策
- なし。
RHOAIENG-1152 (以前は RHODS-6356 として記録されていた問題) - ダッシュボードにログインしたことがないユーザーの basic-workbench 作成プロセスが失敗する
ダッシュボードの基本ワークベンチの Administration ページには、OpenShift のユーザーグループと管理者グループに属するユーザーが表示されます。ただし、管理者がダッシュボードにログインしたことのないユーザーに代わって基本ワークベンチを起動しようとすると、基本ワークベンチの作成プロセスは失敗し、次のエラーメッセージが表示されます。
Request invalid against a username that does not exist.
Request invalid against a username that does not exist.
- 回避策
- 該当するユーザーにダッシュボードへのログインを依頼します。
RHODS-5543: NVIDIA GPU Operator を使用すると、Node Autoscaler によって必要以上のノードが作成される
使用可能なリソースが不十分なために Pod をスケジュールできないと、Node Autoscaler は新しいノードを作成します。新しく作成されたノードが関連する GPU ワークロードを受け取るまで、遅延があります。したがって、Pod をスケジュールすることはできず、Node Autoscaler は、ノードの 1 つが GPU ワークロードを受け取る準備ができるまで、追加の新しいノードを継続的に作成します。この問題の詳細は、Red Hat ナレッジベースのソリューション記事 NVIDIA GPU Operator を使用すると、Node Autoscaler によって必要以上のノードが作成される を参照してください。
- 回避策
-
machineset.spec.template.spec.metadataでcluster-api/acceleratorラベルを適用します。これにより、オートスケーラーは、GPU ドライバーがデプロイされるまで、これらのノードを準備ができていないと見なします。
RHOAIENG-1149 (以前に文書化された RHODS-5216) - アプリケーション起動メニューに OpenShift Cluster Manager へのリンクが誤って表示される
Red Hat OpenShift AI は、アプリケーションランチャーメニューから OpenShift Cluster Manager へのリンクを誤って表示します。このリンクをクリックすると、URL が無効なため、"Page Not Found" エラーが発生します。
- 回避策
- なし。
RHOAIENG-1137 (以前は RHODS-5251 として記録されていた問題) - 基本ワークベンチの管理ページに権限へのアクセスを失ったユーザーが表示される
以前に基本ワークベンチを開始したユーザーがその権限を失った場合 (たとえば、OpenShift AI 管理者がユーザーのグループ設定を変更したり、許可されたグループからユーザーを削除したりした場合)、管理者は引き続き Administration ページでユーザーの基本ワークベンチを表示します。その結果、管理者は権限が取り消されたユーザーに属する基本ワークベンチを再起動できるようになります。
- 回避策
- なし。
RHODS-4799: Tensorboard を表示するには手動の手順が必要
TensorFlow または PyTorch ワークベンチイメージを使用しており、TensorBoard を使用してデータを表示する場合に、ワークベンチ環境に環境変数を追加して、独自のコードで使用する環境変数をインポートするといった手作業の手順が必要です。
- 回避策
基本ワークベンチを起動するときに、次のコードを使用して TENSORBOARD_PROXY_URL 環境変数の値を設定し、OpenShift AI ユーザー ID を使用します。
import os os.environ["TENSORBOARD_PROXY_URL"]= os.environ["NB_PREFIX"]+"/proxy/6006/"
import os os.environ["TENSORBOARD_PROXY_URL"]= os.environ["NB_PREFIX"]+"/proxy/6006/"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
RHODS-4718: Intel® oneAPI AI Analytics Toolkits のクイックスタートが、存在しないサンプルノートブックを参照している
ダッシュボードの Resources ページにある Intel® oneAPI AI アナリティクスツールキットクイックスタートでは、手順の一部としてサンプルノートブックをロードする必要がありますが、関連するリポジトリーに存在しないノートブックを参照しています。
- 回避策
- なし。
RHOAIENG-1141 (以前は RHODS-4502 として記録されていた問題) - ダッシュボード上の NVIDIA GPU Operator タイルに不必要にボタンが表示される
NVIDIA GPU Operator がインストールされると、Jupyter で GPU が自動的に使用可能になります。したがって、Explore ページの NVIDIA GPU Operator タイルにある Enable ボタンは不要です。さらに、Enable ボタンをクリックすると、Operator がインストールされていない場合でも、NVIDIA GPU Operator タイルが Enabled ページに移動します。
- 回避策
- なし。
RHODS-3984: ノートブックの選択時に誤ったパッケージバージョンが表示される
OpenShift AI インターフェイスで、Start a notebook server ページに、oneAPI AI Analytics Toolkit ノートブックイメージに含まれる JupyterLab パッケージおよび Notebook パッケージの誤ったバージョン番号が表示されます。このページには、このイメージが使用する Python バージョンの誤った値が表示される場合もあります。
- 回避策
-
oneAPI AI Analytics Toolkit ノートブックサーバーを起動するときに、ノートブックセルで
!pip listコマンドを実行すると、ノートブックサーバーにインストールされている Python パッケージと、所有しているパッケージのバージョンを確認できます。
RHODS-2956: ノートブックインスタンスの作成時にエラーが発生する可能性がある
Jupyter でノートブックインスタンスを作成すると、Directory not found エラーが断続的に表示されます。このエラーメッセージは、Dismiss をクリックすると無視できます。
- 回避策
- なし。
RHOAING-1147 (以前は RHODS-2881 として記録されていた問題) - ダッシュボード上のアクションが明確に表示されない
無効になったアプリケーションのライセンスを再検証し、無効になったアプリケーションのタイルを削除するダッシュボードアクションは、ユーザーには明確に表示されません。これらのアクションは、ユーザーがアプリケーションタイルの Disabled ラベルをクリックすると表示されます。その結果、意図したワークフローがユーザーにとって明確でない場合があります。
- 回避策
- なし。
RHOAIENG-1134 (以前は RHODS-2879 として記録されていた問題) - ライセンス再検証アクションが不必要に表示される
無効になったアプリケーションのライセンスを再検証するダッシュボードアクションは、ライセンス検証またはアクティベーションシステムがないアプリケーションでは不要に表示されます。さらに、ユーザーが再検証できないライセンスを再検証しようとしても、アクションを完了できない理由を示すフィードバックが表示されません。
- 回避策
- なし。
RHOAIENG-2305 (以前は RHODS-2650 として記録されていた問題) - Pachyderm のデプロイ中にエラーが発生することがある
Pachyderm Operator のインスタンスを作成すると、Webhook エラーが断続的に表示され、作成プロセスを正常に開始できなくなります。Webhook エラーは、Pachyderm Operator がヘルスチェックに失敗して再起動したか、Operator プロセスがコンテナーに割り当てられたメモリー制限を超えてメモリー不足 (OOM) キルをトリガーしたことを示しています。
- 回避策
- エラーが表示されなくなるまで、Pachyderm インスタンスの作成プロセスを繰り返します。
RHODS-2096 - IBM Watson Studio は OpenShift AI で利用できない
IBM Watson Studio は、OpenShift AI が OpenShift Dedicated 4.9 以降にインストールされている場合は使用できません。これは、OpenShift Dedicated のこれらのバージョンと互換性がないためです。
- 回避策
- OpenShift Dedicated 4.9 以降で Watson Studio を手動で設定する方法は、Marketplace サポート にお問い合わせください。
第8章 製品機能 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift AI は、データサイエンティストやクラスター管理者向けに豊富な機能を提供します。詳細は、Red Hat OpenShift AI の概要 を参照してください。