リリースノート
このリリースに関連する機能、機能拡張、解決された問題、および既知の問題
概要
第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 が管理するクラウド環境にインストールできます。
接続環境または非接続環境における OpenShift クラスター上のセルフマネージドソフトウェアとしての OpenShift AI に関する詳細は、Red Hat OpenShift AI Self-Managed の製品ドキュメント を参照してください。
- Red Hat OpenShift Dedicated (AWS または GCP の Customer Cloud Subscription を使用) または Red Hat OpenShift Service on Amazon Web Services (ROSA classic) にアドオンとしてインストールされる マネージドクラウドサービス。
OpenShift AI でサポートされているソフトウェアプラットフォーム、コンポーネント、依存関係の詳細は、ナレッジベースの記事 Red Hat OpenShift AI: サポートされる構成 を参照してください。
完全なサポートフェーズ期間を含むリリースライフサイクルの詳細は、Red Hat OpenShift AI Cloud Service Life Cycle ナレッジベースの記事を参照してください。
第2章 新機能および機能拡張 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、Red Hat OpenShift AI の新機能と機能拡張について説明します。
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 プロキシーを使用します。古い
v1alpha1
API と Istio 設定を使用して作成された新しいインスタンスは、OAuth プロキシーを使用するように自動的に更新されます。Kubernetes RBAC リソースなど、古いモデルレジストリーインスタンスの既存の認可設定は、引き続き期待どおりに機能します。
第3章 テクノロジープレビュー機能 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、Red Hat OpenShift AI のテクノロジープレビュー機能を説明します。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat では、実稼働環境での使用を推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
- Kubernetes API を使用したパイプラインの定義および管理
-
Kubernetes API を使用してデータサイエンスパイプラインとパイプラインバージョンを定義および管理できるようになりました。この方法では、パイプラインとパイプラインバージョンが、内部データベースではなくクラスター内のカスタムリソースとして保存されます。このテクノロジープレビュー機能により、OpenShift GitOps (Argo CD) または同様のツールを使用してパイプラインを管理しやすくなります。同時に、引き続き OpenShift AI ユーザーインターフェイス、API、
kfp
SDK を使用してパイプラインを管理することもできます。この機能を有効にするには、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 の設定 を参照してください。
- ノードセレクターを使用して、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 の開発者プレビュー機能を説明します。
開発者プレビュー機能は、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. InstructLab のスタンドアロンスクリプトを削除 リンクのコピーリンクがクリップボードにコピーされました!
Distributed InstructLab トレーニングを実行するためのスタンドアロンスクリプトが削除されました。InstructLab トレーニングフローを実行するには、LAB-tuning テクノロジープレビュー機能を使用します。詳細は、LAB-tuning の有効化 および LAB-tuning を使用したモデルのカスタマイズ を参照してください。
LAB-tuning 機能は現在、非接続環境ではサポートされていません。
5.2.2. 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-access
Anaconda 検証 cronjob の
ConfigMap
を削除します。oc delete configmap -n redhat-ods-applications anaconda-ce-validation-result
Anaconda イメージストリームを削除します。
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-run
Anaconda cronjob の実行に関連するすべての Pod を削除します。
oc get pods n redhat-ods-applications --no-headers=true | awk '/anaconda-ce-periodic-validator-job-custom-run*/'
5.2.3. データサイエンスパイプライン v1 のサポートの削除 リンクのコピーリンクがクリップボードにコピーされました!
これまで、OpenShift AI のデータサイエンスパイプラインは KubeFlow Pipelines v1 をベースにしていました。データサイエンスパイプラインは現在、異なるワークフローエンジンを使用する KubeFlow Pipelines v2 をベースにしています。OpenShift AI では、デフォルトで Data Science Pipelines 2.0 が有効化され、デプロイされます。
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 をアップグレードした後、既存のパイプラインとワークベンチを Data Science Pipelines 2.0 で使用する場合は、2024.1 以降のワークベンチイメージバージョンを使用するようにワークベンチを更新してから、パイプラインを Data Science Pipelines 1.0 から 2.0 に手動で移行する必要があります。詳細は、Data Science Pipelines 2.0 への移行 を参照してください。
Data Science Pipelines 2.0 には、Argo Workflows のインストールが含まれています。Red Hat は、この Argo Workflows インストールの、お客様による直接使用をサポートしていません。Data Science Pipelines 2.0 を備えた OpenShift AI へインストールまたはアップグレードするには、クラスターに Argo Workflows がインストールされていないことを確認してください。
5.2.4. Elyra パイプラインで実行される Python スクリプトのパイプラインログは S3 に保存されない リンクのコピーリンクがクリップボードにコピーされました!
Elyra パイプラインで実行されている Python スクリプトのログは、S3 互換ストレージに保存されなくなりました。OpenShift AI バージョン 2.11 以降では、OpenShift AI ダッシュボードのパイプラインログビューアーでこれらのログを表示できます。
この変更を有効にするには、バージョン 2024.1 以降のワークベンチイメージで提供される Elyra ランタイムイメージを使用する必要があります。
古いバージョンのワークベンチイメージがある場合は、プロジェクトワークベンチの更新 の説明に従って、Version selection フィールドを互換性のあるワークベンチイメージバージョン (例: 2024.1) に更新します。
ワークベンチイメージバージョンを更新すると、パイプラインの既存のランタイムイメージの選択がすべて消去されます。ワークベンチのバージョンを更新したら、ワークベンチ IDE を開き、パイプラインのプロパティーを更新してランタイムイメージを選択します。
5.2.5. ワークベンチのバージョン 1.2 コンテナーイメージのサポートを終了 リンクのコピーリンクがクリップボードにコピーされました!
ワークベンチを作成するときは、ワークベンチで使用するコンテナーイメージを指定します。OpenShift AI 2.5 以降では、新しいワークベンチを作成するときに、バージョン 1.2 のコンテナーイメージを選択できません。バージョン 1.2 イメージですでに実行されているワークベンチは、引き続き正常に動作します。ただし、Red Hat では、最新のコンテナーイメージを使用するようにワークベンチを更新することを推奨します。
5.2.6. NVIDIA GPU Operator が NVIDIA GPU アドオンを置き換える リンクのコピーリンクがクリップボードにコピーされました!
以前は、計算負荷の高いワークロードを支援するグラフィックスプロセッシングユニット (GPU) を有効にするために、ユーザーは NVIDIA GPU アドオンをインストールしていました。OpenShift AI はこのアドオンをサポートしなくなりました。
GPU サポートを有効にするには、NVIDIA GPU Operator をインストールする必要があります。GPU Operator のインストール方法の詳細は、NVIDIA GPU Operator on Red Hat OpenShift Container Platform (外部) を参照してください。
5.2.7. Kubeflow Notebook Controller が JupyterHub を置き換える リンクのコピーリンクがクリップボードにコピーされました!
OpenShift AI 1.15 以前では、基本ワークベンチの作成と起動に JupyterHub が使用されていました。OpenShift AI 1.16 以降では、JupyterHub は含まれなくなり、その機能は Kubeflow Notebook Controller に置き換えられます。
この変更により、次の利点が得られます。
- ユーザーは、最初のリクエストがタイムアウトするまで 5 分以上待つのではなく、すぐにリクエストをキャンセルし、変更を加えて、リクエストを再試行できるようになりました。これは、たとえば、基本ワークベンチが正しく起動しない場合など、要求が失敗したときに、ユーザーがそれほど長く待機しないことを意味します。
- このアーキテクチャーにより、1 ユーザーが複数の基本ワークベンチセッションを使用できなくなるため、今後の機能の可能性が広がります。
- PostgreSQL データベース要件が削除されたことで、OpenShift AI での将来的な拡張環境サポートが可能になります。
ただし、この更新により、次の動作の変更も作成されます。
- クラスター管理者の場合、基本ワークベンチの管理インターフェイスで現在、データサイエンティストユーザーのワークベンチにログインアクセスできません。これは、今後のリリースで追加される予定です。
- データサイエンティストの場合、JupyterHub インターフェイスの URL は無効になりました。OpenShift AI ダッシュボードを指すようにブックマークを更新します。
JupyterLab インターフェイスは変更されておらず、データサイエンティストは引き続き JupyterLab を使用して、通常どおり Jupyter ノートブックファイルを操作できます。
5.2.8. HabanaAI ワークベンチイメージの削除 リンクのコピーリンクがクリップボードにコピーされました!
HabanaAI 1.10 ワークベンチイメージのサポートが削除されました。OpenShift AI バージョン 2.14 以降の新規インストールには、HabanaAI ワークベンチイメージは含まれません。ただし、OpenShift AI を以前のバージョンからアップグレードする場合は、HabanaAI ワークベンチイメージは使用可能なままとなるため、既存の HabanaAI ワークベンチイメージは引き続き機能します。
第6章 解決された問題 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift AI では、次の重要な問題が解決されました。
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 を超える長いプロンプトを推論サービスに送信すると、推論サービスが応答しませんでした。この問題は発生しなくなりました。
RHOAIENG-24886 - モデル URI フィールドに接頭辞が含まれている場合、OCI モデルをデプロイできない
以前は、OCI モデルをデプロイするときに、Model URI フィールドに完全な URI を貼り付けてからカーソルを別のフィールドに移動すると、URL 接頭辞 (例: http://
) は Model URI フィールドから削除されましたが、InferenceService
リソースの storageUri
値には含まれていました。その結果、OCI モデルをデプロイできませんでした。この問題は解決されています。
RHOAIENG-24104 - KServe reconciler は、Authorino がインストールされている場合にのみ、特定のリソースをデプロイする必要があります。
以前は、Authorino がインストールされていない場合、Red Hat OpenShift AI は AuthorizationPolicy
および EnvoyFilter
リソースを KServe サーバーレスデプロイメントモードに適用していました。これにより、一部の推論要求がブロックされる可能性があります。この問題は解決されています。
RHOAIENG-23562 - FIPS クラスターにおける TrustyAIService TLS ハンドシェイクエラー
以前は、外部ルートを使用して TrustyAIService にリクエストを送信する FIPS クラスターを使用すると、ログに TLS ハンドシェイクエラーが表示され、リクエストは処理されませんでした。この問題は解決されています。
RHOAIENG-23169 - StorageInitializer がモデルを Hugging Face リポジトリーからダウンロードできない
以前は、クラスターにこのプロトコルのサポートが組み込まれていない場合、hf://
プロトコルを使用して KServe 環境で Hugging Face からモデルをデプロイしようとすると失敗しました。さらに、KServe のストレージイニシャライザー InitContainer
では、デフォルトのキャッシュディレクトリー (/.cache)
への書き込み権限が不足しているために、PermissionError
エラーが発生する可能性がありました。この問題は解決されています。
RHOAIENG-22965 - オプションの入力パラメーターが設定されていない場合にデータサイエンスパイプラインタスクが失敗する
以前は、パイプラインにオプションの入力パラメーターがある場合、パラメーターが設定されていないパイプライン実行とタスクを作成すると、次のエラーで失敗しました。
failed: failed to resolve inputs: resolving input parameter optional_input with spec component_input_parameter:"parameter_name": parent DAG does not have input parameter
failed: failed to resolve inputs: resolving input parameter optional_input with spec component_input_parameter:"parameter_name": parent DAG does not have input parameter
この問題は InstructLab パイプラインにも影響しました。この問題は解決されています。
RHOAIENG-22439 - cuda-rstudio-rhel9 をビルドできない
以前は、RStudio Server ワークベンチイメージのビルド時に、次のエラーで cuda-rstudio-rhel9
のビルドが失敗していました。
この問題は解決されています。
RHOAIENG-21274 - OCI 接続タイプでモデルをデプロイすると、接続タイプが S3 または URI に戻る
以前は、一致する接続がないプロジェクトで S3 または URI 接続タイプを使用しているモデルをデプロイすると、S3 または URI ストレージの場所のモデルの場所のデータを使用して、Create new connection セクションが事前に入力されました。接続タイプを OCI に変更し、Model URI フィールドに値を入力すると、接続タイプは S3 または URI に戻ります。この問題は解決されています。
RHOAIENG-6486 - TensorFlow 2024.1 ノートブックイメージで Elyra JupyterLab エクステンションを使用している場合、Pod ラベル、アノテーション、許容値を設定できない
以前は、TensorFlow ベースのワークベンチイメージを使用すると、ユーザーは Elyra JupyterLab エクステンションを使用するときに Pod ラベル、アノテーション、および toleration を使用できませんでした。2025.1 イメージでは、TensorFlow ベースのワークベンチが Kubeflow パイプライン SDK (kfp) でアップグレードされます。アップグレードされた SDK では、Elyra エクステンションを使用してデータサイエンスパイプラインをスケジュールするときに、Pod ラベル、アノテーション、toleration を設定できます。
RHOAIENG-21197 - FIPS 対応クラスターの AMD GPU アクセラレーターで vLLM ランタイムを使用する場合、デプロイメントに失敗する
以前は、FIPS 対応クラスターの AMD GPU アクセラレーターで vLLM ランタイムを使用してモデルをデプロイすると、デプロイメントが失敗する可能性がありました。この問題は解決されています。
RHOAIENG-20245 - 一部のモデルレジストリー操作により、登録されたモデルおよびバージョンからカスタムプロパティーが削除されます。
以前は、モデルバージョンの説明、ラベル、またはプロパティーを編集すると、関連付けられたモデルからラベルとカスタムプロパティーが削除されました。モデルバージョンをデプロイするか、そのモデルソース形式を編集すると、そのバージョンおよび関連モデルからラベルとカスタムプロパティーが削除されました。この問題は解決されています。
RHOAIENG-19954 - Kueue アラートが OpenShift で監視されない
以前は、OpenShift コンソールでは Kueue アラートは監視されていませんでした。新しい ServiceMonitor
リソースは BearerTokenFile
フィールドの使用を拒否しました。これは、Prometheus にターゲットをスクレープするために必要なパーミッションがないことを意味します。その結果、Kueue アラートは Observe → Alerting ページに表示されず、Kueue ターゲットは Observe → Targets ページに表示されませんでした。この問題は解決されています。
RHOAIENG-19716 - system-authenticated
ユーザーグループはダッシュボードを使用して削除できない
以前は、Red Hat OpenShift AI をインストールまたはアップグレードすると、system-authenticated
ユーザーグループが Data science user groups の下の Settings > User management に表示されました。このユーザーグループを Data science user groups から削除して変更を保存すると、グループが誤って再度追加されます。この問題は解決されています。
RHOAIENG-18238 - Authorino Operator をアップグレードした後、デプロイされたモデルの推論エンドポイントが 403 エラーを返す
以前は、Authorino Operator をアップグレードした後、自動 Istio サイドカーインジェクションが再適用されていない可能性がありました。サイドカーがないと、Authorino はサービスメッシュに正しく統合されず、推論エンドポイントリクエストが HTTP 403 エラーで失敗していました。この問題は解決されています。
RHOAIENG-11371 - ExitHandler を使用した実行で誤った実行ステータスが報告される
以前は、パイプライン終了ハンドラー (dsl.ExitHandler
) を使用する場合、ハンドル内のタスクが失敗しても終了タスクが成功すると、パイプライン全体の実行ステータスが Failed
ではなく Succeeded
と不正確に報告されました。この問題は解決されています。
RHOAIENG-16146 - モデルレジストリーからモデルをデプロイするときに接続が事前に選択されないことがある
以前は、モデルレジストリーからモデルをデプロイする場合、オブジェクトストレージ 接続 (以前は データ接続 と呼ばれていました) が事前に選択されないことがありました。この問題は解決されています。
RHOAIENG-21068 - パラメーター sdg_repo_pr が空のままの場合、InstructLab パイプライン実行を作成できない
以前は、InstructLab パイプラインのパイプライン実行を作成する場合に、パラメーター sdg_repo_pr
が空のままになると、パイプライン実行は作成できず、エラーメッセージが表示されました。この問題は解決されています。
RHOAIENG-19711 - Kueue-controller-manager は 2.16.0 から 2.17.0 にアップグレードした後、古いメトリクスポートが使用される
以前は、アップグレード後に、Kueue Operator はメトリクスに新しいポート (8443) の代わりに古いポート (8080) を引き続き使用していました。その結果、OpenShift コンソールの Observe > Targets ページには、Kueue Operator のステータスが Down
と表示されていました。この問題は解決されています。
RHOAIENG-19261 - カスタムリソース定義 (CRD) が不足しているため、TrustyAI のインストールが失敗する可能性がある
以前は、OpenShift AI をインストールまたはアップグレードするときに、InferenceService
および ServingRuntime
CRD がないために、TrustyAI のインストールが失敗する可能性がありました。その結果、Trusty AI コントローラーは CrashLoopBackOff
状態になりました。この問題は解決されています。
RHOAIENG-18933 - ワークベンチのイメージサイズが大きくなると、ワークベンチの起動が遅れることがある
以前は、2024.2 ワークベンチイメージに kubeflow-training
Python SDK が存在したため、ワークベンチイメージのサイズが大きくなり、ワークベンチの起動時に遅延が生じる可能性がありました。この問題は解決されています。
RHOAIENG-18884 - NIM アカウントの有効化設定が完了しない
以前は、NVIDIA NIM モデルサービングプラットフォームを有効にしようとすると、NIM アカウントのセットアップが完了する前に odh-model-controller
デプロイメントが開始されていました。その結果、NIM アカウントのセットアップが不完全で、プラットフォームが有効になりませんでした。この問題は解決されています。
RHOAIENG-18675 - アップグレード後にワークベンチコンポーネントが失敗する
以前は、OpenShift AI 1 にアップグレードすると、ワークベンチコンポーネントが正しくアップグレードされませんでした。具体的には、これに続く BuildConfigs
およびリソース (例: RStudio BuildConfigs
や ROCm imagestreams
) は更新されず、これにより DataScienceCluster
でのワークベンチコンポーネントの調整に失敗していました。この問題は解決されています。
RHOAIENG-15123 (RHOAIENG-10790 および RHOAIENG-14265) - アップグレード後にパイプラインのスケジュールが失敗する場合がある
以前は、OpenShift AI 1 にアップグレードすると、アップグレード前に存在していたデータサイエンスパイプラインのスケジュールされた実行が失敗し、タスク Pod にエラーメッセージが表示される場合がありました。この問題は解決されています。
RHOAIENG-16900 - サービングランタイム引数のスペース区切り形式により、デプロイメントが失敗することがある
以前は、モデルをデプロイするときに、スペース区切り形式を使用して追加のサービングランタイム引数を指定すると、認識されない引数
エラーが発生する可能性がありました。この問題は解決されています。
RHOAIENG-16073 - クラスターオブジェクトのジョブクライアントを取得するときに属性エラーが発生する
以前は、get_cluster
メソッドを使用してクラスターを初期化するときに、client = cluster.job_client
を割り当てると、AttributeError: 'Cluster' object has no attribute '_job_submission_client'
エラーが発生することがありました。この問題は解決されています。
RHOAIENG-15773 - 新しいモデルレジストリーユーザーを追加できない
以前は、モデルレジストリーの権限を管理するときに、モデルレジストリーの権限の管理 で説明されているように、新しいユーザー、グループ、またはプロジェクトを追加できませんでした。HTTP request failed
エラーが表示されます。この問題は解決されています。
RHOAIENG-14197 - CPU およびメモリーグラフのツールチップテキストが切り取られ、判読できない
以前は、Distributed Workloads Metrics ページの Project metrics タブにある Top resource-consuming distributed workloads セクションの CPU および Memory グラフにカーソルを合わせると、ツールチップテキストが切り取られ、判読できませんでした。この問題は解決されています。
RHOAIENG-11024 - リソースエントリーが、opendatahub.io/managed アノテーションの削除後に消去される
以前は、コンポーネントデプロイメント YAML ファイルから opendatahub.io/managed
アノテーションを手動で削除すると、ファイル内の リソース
エントリー値が消去される可能性がありました。この問題は解決されています。
RHOAIENG-8102 - クラスターに複数のクラスターキューがある場合、要求されたリソースの報告が不正確になる
以前は、クラスターに複数のクラスターキューがある場合、すべてのプロジェクトによって要求されたリソースが、実際の値ではなく、誤ってゼロとして報告されていました。この問題は解決されています。
RHOAIENG-16484 - Gaudi アクセラレーターの vLLM サーバーエンジンが一定期間非アクティブになると失敗する
以前は、Gaudi ハードウェアを備えたクラスターで vLLM ServingRuntime with Gaudi accelerators support for KServe を使用する場合、vLLM サーバーで継続的な推論リクエストが処理されない非アクティブな期間が続くと、サーバーが失敗して TimeoutError
メッセージが表示されることがありました。この問題は発生しなくなりました。
RHOAIENG-15033 - OpenShift AI のアップグレード後にモデルレジストリーインスタンスが再起動または更新されない
以前は、OpenShift AI をアップグレードしても、モデルレジストリーコンポーネントの既存のインスタンスが更新されませんでした。これにより、インスタンス Pod が Operator Pod によって参照されるイメージよりも古いイメージを使用していました。この問題は解決されています。
RHOAIENG-15008 - リクエスト名なしで CLI からバイアスメトリクスを作成するとエラーが発生する
以前は、requestName
パラメーターが設定されていない場合、バイアスメトリクスを表示すると、ユーザーインターフェイスにエラーメッセージが表示されることがありました。バイアスメトリクスの表示にはユーザーインターフェイスを使用し、その設定は CLI 経由で行う場合は、ペイロード内で requestName
パラメーターを指定する必要がありました。この問題は解決されています。
RHOAIENG-14986 - パッケージパスが正しくないため copy_demo_nbs
が失敗する
以前は、SDK パッケージへのパスが正しくなかったため、CodeFlare SDK の copy_demo_nbs()
関数が失敗していました。この関数を実行すると、FileNotFound
エラーが発生していました。この問題は解決されています。
RHOAIENG-14552 - OpenShift Container Platform 4.16 でワークベンチまたはノートブックの OAuth プロキシーが FIPS で失敗する
以前は、FIPS 対応クラスターで OpenShift 4.16 以降を使用すると、実行中のワークベンチへの接続が失敗していました。これは、内部コンポーネント oauth-proxy
と OpenShift Ingress 間の接続が TLS ハンドシェイクエラーで失敗するために発生していました。ワークベンチを開くと、ブラウザーに "Application is not available" という画面が表示され、それ以外の診断情報が表示されませんでした。この問題は解決されています。
RHOAIENG-14095 - OpenShift AI Operator のインストール後、ダッシュボードが一時的に利用できなくなる
以前は、OpenShift AI Operator をインストールした後、OpenShift AI ダッシュボードを約 3 分間使用できませんでした。その結果、Cannot read properties of undefined というメッセージが表示されることがありました。この問題は解決されています。
RHOAIENG-13633 - モデルレジストリーの外部からモデルを最初にデプロイしないと、プロジェクトのサービングプラットフォームを設定できない
以前は、モデルレジストリーの外部からモデルを最初にデプロイしないと、プロジェクトのサービングプラットフォームを設定できませんでした。プロジェクトでシングルモデルサービングまたはマルチモデルサービングがすでに選択されていない限り、モデルレジストリーからプロジェクトにモデルをデプロイできませんでした。OpenShift AI UI からシングルモデルサービングまたはマルチモデルサービングを選択するには、先にレジストリーの外部からモデルまたはモデルサーバーをデプロイする必要がありました。この問題は解決されています。
RHOAIENG-545 - JupyterLab パイプラインエディターで汎用のデフォルトノードランタイムイメージを指定できない
以前は、JupyterLab IDE パイプラインエディターで Elyra パイプラインを編集し、PIPELINE PROPERTIES タブをクリックして、Generic Node Defaults セクションまでスクロールし、Runtime Image フィールドを編集しても、変更内容が保存されませんでした。この問題は解決されています。
RHOAIENG-14571 - マネージド IBM Cloud OpenShift AI インストールで Data Science Pipelines API Server にアクセスできない
以前は、データサイエンスパイプラインサーバーの設定時に、パイプラインサーバーとの正常なやり取りを妨げる通信エラーが発生しました。この問題は解決されています。
RHOAIENG-14195 - 非推奨の head_memory パラメーターを使用すると、Ray クラスターの作成が失敗する
以前は、Ray クラスター設定に非推奨の head_memory
パラメーターを含めると、Ray クラスターの作成に失敗しました。この問題は解決されています。
RHOAIENG-11895 - |-
を使用してカスタム CA バンドルを設定すると、JupyterLab で GitHub リポジトリーをクローンできない
以前は、|-
を使用して DSCInitialization
(DSCI) オブジェクトでカスタム認証局 (CA) バンドルを設定すると、JupyterLab からのリポジトリーのクローン作成に失敗しました。この問題は解決されています。
RHOAIENG-1132 (以前は RHODS-6383 として記録されていた問題) - ワークベンチの作成プロセス中に必要なときに ImagePullBackOff
エラーメッセージが表示されない
以前は、コンテナーレジストリーからコンテナーイメージをプルする際に Pod で問題が発生しました。エラーが発生すると、関連する Pod は ImagePullBackOff
状態になりました。ワークベンチの作成プロセス中に ImagePullBackOff
エラーが発生しても、適切なメッセージが表示されませんでした。この問題は解決されています。
RHOAIENG-13327 - インポーターコンポーネント (dsl.importer) によりパイプラインの実行が妨げられる
データサイエンスパイプラインのインポーターコンポーネント (dsl.importer
) 使用時にパイプラインを実行できませんでした。この問題は解決されています。
RHOAIENG-14652 - OpenShift Container Platform 4.16 以降では、kfp-client
がパイプラインサーバーに接続できない
OpenShift 4.16 以降の FIPS クラスターでは、OpenShift AI ダッシュボードからデータサイエンスパイプラインにアクセスできました。しかし、TLS ハンドシェイクエラーが原因で、KFP SDK からパイプライン API サーバーへの接続は失敗しました。この問題は解決されています。
RHOAIENG-10129 - 名前が一致する Notebook と Ray クラスターにより、シークレット解決が失敗する
以前は、同じ namespace に一致する名前を持つノートブックと Ray クラスターを作成した場合、シークレットにすでに所有者が存在していたため、1 つのコントローラーがそのシークレットを解決できませんでした。この問題は解決されています。
RHOAIENG-7887 - Kueue が RayCluster または PyTorchJob リソースの監視に失敗する
以前は、すべてのコンポーネントを有効にして DataScienceCluster
CR を作成すると、Ray コンポーネントと Training Operator コンポーネントの前に Kueue コンポーネントがインストールされていました。その結果、Kueue コンポーネントは RayCluster
または PyTorchJob
リソースを監視しませんでした。ユーザーが RayCluster
または PyTorchJob
リソースを作成した場合、Kueue はそれらのリソースの受付を制御しませんでした。この問題は解決されています。
RHOAIENG-583 (以前は RHODS-8921 および RHODS-6373 として記録されていた問題) - 累積文字数上限を超えると、パイプラインサーバーの作成やワークベンチの起動ができない
データサイエンスプロジェクト名とパイプラインサーバー名の合計文字数制限が 62 文字を超えると、パイプラインサーバーを正常に作成できませんでした。同様に、データサイエンスプロジェクト名とワークベンチ名の合計文字数制限が 62 文字を超えると、ワークベンチの起動に失敗しました。この問題は解決されています。
アップグレード後のダッシュボードのロゴが間違っている
以前は、OpenShift AI 2.11 から OpenShift AI 2.12 にアップグレードした後、ダッシュボードに Red Hat OpenShift AI ロゴではなく Open Data Hub ロゴが誤って表示されることがありました。この問題は解決されています。
RHOAIENG-11297 - パイプライン実行後の認証失敗
以前は、パイプライン実行中に、証明書認証の失敗により接続エラーが発生する可能性がありました。この証明書認証の失敗は、データサイエンスパイプラインでサポートされていない、default-dsci
オブジェクトの customCABundle
に複数行の文字列区切り文字を使用したことが原因で発生する可能性があります。この問題は解決されています。
RHOAIENG-11232 - 分散ワークロード: Kueue アラートが runbook リンクを提供しない
Kueue アラートの実行後に、クラスター管理者は Observe → Alerting → Alerts の順にクリックし、アラートの名前をクリックして Alert details ページを開くことができます。Alert details ページの Runbook セクションに、アラートをトリガーした問題を診断して解決する際に役立つ適切な runbook へのリンクを提供する必要があります。以前は、runbook リンクがありませんでした。
RHOAIENG-10665 - 投機的デコーディングを使用した granite モデル用のドラフトモデルをクエリーできない
以前は、granite-7b
モデルおよび granite-7b-accelerator
ドラフトモデルでは投機的デコードを使用できませんでした。これらのモデルをクエリーすると、内部エラーが発生してクエリーが失敗しました。この問題は解決されています。
RHOAIENG-9481 - アクションメニューをクリックするとパイプライン実行メニューに不具合が発生する
以前は、Experiments > Experiments and runs ページでパイプライン実行の横にあるアクションメニュー (⋮) をクリックしても、表示されるメニューが完全には表示されず、すべてのメニュー項目を表示するにはスクロールする必要がありました。この問題は解決されています。
RHOAIENG-8553 - カスタムイメージで作成したワークベンチに !Deleted
フラグが表示される
以前は、OpenShift クラスターで内部イメージレジストリーを無効にし、イメージタグ (例: quay.io/my-wb-images/my-image:tag
) を使用してインポートしたカスタムイメージでワークベンチを作成すると、Data science projects ページの Workbenches タブの Notebook image 列に !Deleted
フラグが表示されていました。ワークベンチを停止すると、再起動できなくなっていました。この問題は解決されています。
RHOAIENG-6376 - パイプラインコンポーネントの pip_index_urls
をポート番号とパスを含む URL に設定するとパイプライン実行の作成が失敗する
以前は、パイプラインを作成し、コンポーネントの pip_index_urls
値をポート番号とパスを含む URL に設定すると、パイプラインコードをコンパイルしてパイプライン実行を作成するとエラーが発生する可能性がありました。この問題は解決されています。
RHOAIENG-4240 - 保護されていない環境でジョブを Ray クラスターに送信できない
以前は、保護されていない OpenShift クラスター内の Jupyter ノートブックから分散データサイエンスワークロードを実行すると、ConnectionError: Failed to connect to Ray
エラーメッセージが表示されることがありました。この問題は解決されています。
RHOAIENG-9670 - リクエストの処理中に vLLM コンテナーが断続的にクラッシュする
以前は、シングルモデルサービングプラットフォームで vLLM ServingRuntime for KServe ランタイムを使用してモデルをデプロイし、tensor-parallel-size
も設定した場合、使用したハードウェアプラットフォームによっては、リクエストの処理中に kserve-container
コンテナーが断続的にクラッシュしていました。この問題は解決されています。
RHOAIENG-8043 - mixtral-8x7b で生成中に vLLM エラーが発生する
以前は、Mixtral-8x7b などの一部のモデルでは、FileNotFoundError:No such file or directory
など、triton の問題が原因でスポラディックエラーが発生していた可能性があります。この問題は解決されています。
RHOAIENG-2974 - データサイエンスクラスターは、関連する初期化オブジェクトなしで削除できない
以前は、関連付けられた DSCInitialization
(DSCI) オブジェクトが存在しない場合、DataScienceCluster
(DSC) オブジェクトを削除できませんでした。この問題は解決されています。
RHOAIENG-1205 (以前は RHODS-11791 として記録されていた問題) - アップグレード後に使用状況データの収集が有効になる
以前は、Allow collection of usage data
オプションは、OpenShift AI をアップグレードするたびにアクティブ化されていました。今後は、アップグレード時に Allow collection of usage data
オプションを手動で選択解除する必要がなくなりました。
RHOAIENG-1204 (以前は ODH-DASHBOARD-1771 として記録されていた問題) - パイプラインステップの初期化中の JavaScript エラー
以前は、実行が開始されると、パイプラインの Run details ページが機能停止していました。この問題は解決されています。
RHOAIENG-582 (以前は ODH-DASHBOARD-1335 として記録されていた問題) - Edit 権限の名前を Contributor に変更する
プロジェクトの Permissions タブでは、この権限によって付与されるアクションをより正確に説明するために、Edit という用語が Contributor に置き換えられました。
更新の完全なリストは、エラータアドバイザリー を参照してください。
RHOAIENG-8819 - ibm-granite/granite-3b-code-instruct
モデルをシングルモデルサービングプラットフォームにデプロイできない
以前は、vLLM ServingRuntime for KServe
を使用して、シングルモデルサービングプラットフォームに ibm-granite/granite-3b-code-instruct
モデルをデプロイしようとすると、モデルのデプロイがエラーで失敗していました。この問題は解決されています。
RHOAIENG-8218 - OpenShift Container Platform 内部イメージレジストリーなしで OpenShift 4.15 クラスター上に作成されたワークベンチにログインできない
OpenShift Container Platform 内部イメージレジストリーが有効になっていない OpenShift クラスターでワークベンチを作成すると、ワークベンチは正常に起動しますが、ログインすることはできません。
これは、4.15.15 より前の OpenShift 4.15.x バージョンにおける既知の問題です。この問題を解決するには、OpenShift 4.15.15 以降にアップグレードしてください。
RHOAIENG-7346 - アップグレード後、分散ワークロードが既存のパイプラインから実行されなくなる
以前は、OpenShift AI 2.10 にアップグレードしようとすると、クラスターがパイプライン内でのみ作成された場合、分散ワークロードは既存のパイプラインから実行されなくなりました。この問題は解決されています。
RHOAIENG-7209 - デフォルトのパイプラインルートを設定するときにエラーが表示される
以前は、データサイエンスパイプライン SDK または OpenShift AI ユーザーインターフェイスを使用してデフォルトのパイプラインルートを設定しようとすると、エラーが表示されていました。この問題は解決されています。
RHOAIENG-6711 - ODH-model-controller が ServiceMeshMemberRoll
オブジェクトの spec.memberSelectors
フィールドを上書きする
以前は、ServiceMeshMemberRoll
リソースの spec.memberSelectors
フィールドを使用してプロジェクトまたは namespace を ServiceMeshMemberRoll
リソースに追加しようとすると、ODH-model-controller によってフィールドが上書きされていました。この問題は解決されています。
RHOAIENG-6649 - 外部ルートが定義されていないモデルサーバー上のモデルを表示するとエラーが表示される
以前は、ダッシュボードを使用して、外部ルートが有効になっていないモデルサーバーにモデルをデプロイしようとすると、モデルの作成中に t.components is undefined
というエラーメッセージが表示されていました。この問題は解決されています。
RHOAIENG-3981 - 保護されていない環境で、Ray クラスターの準備が完了するまで待機する機能が停止する
以前は、セキュリティー保護されていない OpenShift クラスター内の Jupyter ノートブックから分散データサイエンスワークロードを実行すると、続行前に Ray クラスターの準備が完了するまで待機する機能 (cluster.wait_ready()
) が、Ray クラスターの準備が完了していてもスタックしていました。この問題は解決されています。
RHOAIENG-2312 - code-server
ワークベンチで numpy のインポートが失敗する
以前は、numpy をインポートしようとすると、code-server ワークベンチが失敗していました。この問題は解決されています。
RHOAIENG-1197 - Linux で Firefox を使用する場合、パイプライン実行作成ページの終了日ピッカーがデフォルトで NaN 値に設定されるため、パイプラインを作成できない
以前は、Linux 上の Firefox を使用して、スケジュールされた定期実行を含むパイプラインを作成しようとすると、End Date パラメーターを有効にすると、日付と時刻の両方に Not a number (Nan) 値が生成されました。この問題は解決されています。
RHOAIENG-1196 (以前は ODH-DASHBOARD-2140 として記録されていた問題) - ダッシュボードに表示されるパッケージバージョンがインストールされたバージョンと一致しない
以前は、ダッシュボードには JupterLab や Notebook などのパッケージのバージョン番号が不正確に表示されていました。この問題は解決されています。
RHOAIENG-880 - デフォルトのパイプラインサービスアカウントが Ray クラスターを作成できない
以前は、デフォルトのパイプラインサービスアカウントを使用して Ray クラスターを作成できませんでした。この問題は解決されています。
RHOAIENG-52 - 自己署名証明書を使用したクラスターでトークン認証が失敗する
以前は、自己署名証明書を使用し、ノートブック内またはパイプラインの一部として Python スクリプト内で Python codeflare-sdk
を使用した場合、トークン認証は失敗していました。この問題は解決されています。
RHOAIENG-7312 - KServe でのトークン認証によるクエリー中にモデルの提供が失敗する
以前は、DataScienceCluster
オブジェクトで ModelMesh コンポーネントと KServe コンポーネントの両方を有効にし、Authorino を認可プロバイダーとして追加すると、競合状態が発生し、odh-model-controller
Pod が ModelMesh には適しているが KServe と Authorino には適していない状態でロールアウトされる可能性がありました。このような状況では、KServe を使用してデプロイされた実行中のモデルに推論リクエストを行うと、404 - Not Found
エラーが表示されました。さらに、odh-model-controller
デプロイメントオブジェクトのログに、Reconciler
エラーメッセージが表示されました。この問題は解決されています。
RHOAIENG-7181 (以前は RHOAIENG-6343 として記録されていた問題) - OpenShift AI をインストールした後、一部のコンポーネントが Removed
に設定される
以前は、OpenShift AI をインストールすると、codeflare
、kueue
、および ray
コンポーネントの managementState
フィールドは、DataScienceCluster
カスタムリソースの Managed
ではなく Removed
に誤って設定されまていました。この問題は解決されています。
RHOAIENG-7079 (以前は RHOAIENG-6317 として記録されていた問題) - パイプラインタスクのステータスとログが OpenShift AI ダッシュボードに表示されないことがある
以前は、Elyra を使用してパイプラインを実行すると、関連する Pod がまだプルーニングされておらず、情報が OpenShift コンソールで引き続き利用できる場合でも、OpenShift AI ダッシュボードにパイプラインタスクのステータスとログが表示されないことがありました。この問題は解決されています。
RHOAIENG-7070 (以前は RHOAIENG-6709 として記録されていた問題) - 異なる環境変数を指定すると、Jupyter ノートブックの作成が失敗する場合がある
以前は、Jupyter ノートブックを起動して停止し、OpenShift AI ワークベンチで環境変数を編集すると、ノートブックの再起動に失敗していました。この問題は解決されています。
RHOAIENG-6853 - Elyra パイプライン Pod で Pod 許容を設定できない
以前は、Elyra パイプライン Pod に Pod 許容を設定しても、許容が有効になりませんでした。この問題は解決されています。
RHOAIENG-5314 - ネットワークポリシーが原因で、新しいクラスターでデータサイエンスパイプラインサーバーのデプロイに失敗する
以前は、新しいクラスター上にデータサイエンスパイプラインサーバーを作成すると、ユーザーインターフェイスがロード中のままになり、パイプラインサーバーが起動しませんでした。この問題は解決されています。
RHOAIENG-4252 - データサイエンスパイプラインサーバーの削除プロセスで ScheduledWorkFlow
リソースの削除に失敗する
以前は、パイプラインサーバーの削除プロセスで、ScheduledWorkFlow
リソースが削除されませんでした。その結果、新しい DataSciencePipelinesApplications
(DSPA) が、冗長な ScheduledWorkFlow
リソースを認識しませんでした。この問題は解決されています。
RHOAIENG-3411 (以前は RHOAIENG-3378 として記録されていた問題) - 内部イメージレジストリーが、Jupyter ノートブック生成プロセスの未宣言の強い依存関係である
以前は、OpenShift AI ノートブックおよびワークベンチを起動する前に、OpenShift の内部の統合コンテナーイメージレジストリーを有効にしておく必要がありました。イメージレジストリーを有効にせずにノートブックまたはワークベンチを起動しようとすると、"InvalidImageName" エラーが発生して失敗しました。内部 OpenShift イメージレジストリーを有効にせずに、OpenShift AI でワークベンチを作成して使用できるようになりました。クラスターを更新して内部イメージレジストリーを有効または無効にする場合は、レジストリーの変更を反映するために既存のワークベンチを再作成する必要があります。
RHOAIENG-2541 - クラスター内のシークレットが多すぎるため、KServe コントローラー Pod で OOM が発生する
以前は、OpenShift クラスターにシークレットが多数ある場合、メモリー不足 (OOM) エラーにより KServe コントローラー Pod が継続的にクラッシュするころがありました。この問題は解決されています。
RHOAIENG-1452 - Red Hat OpenShift AI アドオンがスタックする
以前は、OCM API 経由でインストールがトリガーされた場合、Red Hat OpenShift AI アドオンのアンインストール時に OpenShift AI コンポーネントが削除されませんでした。この問題は解決されています。
RHOAIENG-307 - DataScienceCluster を削除すると、すべての OpenShift Serverless CR が削除される
以前は、DataScienceCluster カスタムリソース (CR) を削除すると、すべての OpenShift Serverless CR (knative-serving、デプロイメント、ゲートウェイ、Pod を含む) も削除されていました。この問題は解決されています。
RHOAIENG-6709 - 異なる環境変数が指定されると、Jupyter ノートブックの作成が失敗する場合がある
以前は、Jupyter ノートブックを起動して停止し、OpenShift AI ワークベンチで環境変数を編集すると、ノートブックの再起動に失敗していました。この問題は解決されています。
RHOAIENG-6701 - クラスター管理者権限を持たないユーザーは Ray ダッシュボードのジョブ送信エンドポイントにアクセスできない
以前は、OpenShift のクラスター管理者権限を持たない分散ワークロード機能のユーザーは、Ray ダッシュボードのジョブ送信エンドポイントにアクセスしたり使用したりできなかった可能性があります。この問題は解決されています。
RHOAIENG-6578 - 保護された推論ポイントへのトークンなしのリクエストがデフォルトで機能しない
以前は、Authorino をシングルモデルサービングプラットフォームの認可プロバイダーとして追加し、デプロイしたモデルのトークン認可を有効にした場合でも、トークンを指定せずにモデルをクエリーすることが可能でした。この問題は解決されています。
RHOAIENG-6343 - OpenShift AI のインストール後に一部のコンポーネントが Removed
に設定される
以前は、OpenShift AI をインストールすると、codeflare
、kueue
、および ray
コンポーネントの managementState
フィールドは、DataScienceCluster
カスタムリソースの Managed
ではなく Removed
に誤って設定されまていました。この問題は解決されています。
RHOAIENG-5067 - ModelMesh コンポーネントをベースとするモデルサーバーのモデルサーバーメトリクスページがロードされない
以前は、データサイエンスプロジェクト名に大文字またはスペースが含まれていると、ModelMesh コンポーネントをベースとするモデルサーバーのモデルサーバーメトリクスページで問題が発生することがありました。メトリクスページがデータを正常に受信しなかったために 400 Bad Request
エラーが発生し、ページがロードされない場合がありました。この問題は解決されています。
RHOAIENG-4966 - カスタム CA バンドル内の自己署名証明書が odh-trusted-ca-bundle
設定マップから欠落している可能性がある
以前は、自己署名証明書を使用するためにカスタム認証局 (CA) バンドルを追加すると、カスタム証明書が odh-trusted-ca-bundle
ConfigMap にないことや、ConfigMap が managed
に設定されている場合に予約されていない namespace に odh-trusted-ca-bundle
ConfigMap が含まれていないことがありました。この問題は解決されています。
RHOAIENG-4938 (以前は RHOAIENG-4327) - ワークベンチが一元的に設定されたバンドルからの自己署名証明書を自動的に使用しない
OpenShift AI に自己署名証明書を追加するためのバンドルの選択肢には、ca-bundle.crt
と odh-ca-bundle.crt
の 2 つがあります。以前は、ワークベンチは一元的に設定されたバンドルからの自己署名証明書を自動的に使用しなかったため、証明書パスを指す環境変数を定義する必要がありました。この問題は解決されています。
RHOAIENG-4572 - 特定の状況でインストールおよびアップグレードするとデータサイエンスパイプラインを実行できない
以前は、次の状況で OpenShift AI をインストールまたはアップグレードすると、データサイエンスパイプラインを実行できませんでした。
-
OpenShift AI をインストール済みで、有効な CA 証明書を持っている。default-dsci オブジェクト内で、
trustedCABundle
フィールドのmanagementState
フィールドをインストール後にRemoved
に変更した。 - OpenShift AI をバージョン 2.6 からバージョン 2.8 にアップグレード済みで、有効な CA 証明書を持っている。
- OpenShift AI をバージョン 2.7 からバージョン 2.8 にアップグレード済みで、有効な CA 証明書を持っている。
この問題は解決されています。
RHOAIENG-4524 - RStudio イメージの BuildConfig 定義に間違ったブランチが含まれている
以前は、RStudio および CUDA - RStudio ワークベンチイメージの BuildConfig
定義は、OpenShift AI の間違ったブランチを指していました。この問題は解決されています。
RHOAIENG-3963 - 管理対象リソースに関する不必要な警告
以前は、redhat-ods-applications
プロジェクトの OdhDashboardConfig
カスタムリソースを編集して保存すると、システムにより Managed resource
警告メッセージが誤表示されました。この問題は解決されています。
RHOAIENG-2542 - 推論サービス Pod が Istio サイドカーを取得しないことがある
以前は、シングルモデルサービングプラットフォーム (KServe を使用) を使用してモデルをデプロイすると、推論サービスに sidecar.istio.io/inject=true
アノテーションがあっても、作成される Pod に istio-proxy
コンテナーが欠落していることがありました。この問題は解決されています。
RHOAIENG-1666 - Import Pipeline ボタンが早期にアクセス可能になる
以前は、データサイエンスプロジェクトに属するワークベンチにパイプラインをインポートすると、パイプラインサーバーが完全に使用可能になる前に Import Pipeline ボタンがアクセス可能になりました。この問題は解決されています。
RHOAIENG-673 (以前は RHODS-12946 として記録されていた問題) - 非接続環境またはプライベート証明書を使用している場合、PyPI ミラーからインストールできない
非接続環境では、Red Hat OpenShift AI は公開されている PyPI リポジトリーに接続できないため、ネットワーク内にリポジトリーを指定する必要があります。以前は、プライベート TLS 証明書を使用していて、データサイエンスパイプラインが Python パッケージをインストールするように設定されている場合、パイプラインの実行は失敗していました。この問題は解決されています。
RHOAIENG-3355 - KServe 上の OVMS がアクセラレーターを正しく使用しない
以前は、シングルモデルサービングプラットフォームを使用してモデルをデプロイし、OpenVINO Model Server サービスランタイムを選択した場合、アクセラレーターをモデルサーバーに割り当てるように要求すると、アクセラレーターハードウェアが検出されるものの、そのハードウェアがクエリーへの応答時にモデルによって使用されませんでした。この問題は解決されています。
RHOAIENG-2869 - マルチモデルプロジェクトで既存のモデルフレームワークとモデルパスを編集できない
以前は、Deploy model ダイアログを使用してマルチモデルプロジェクト内のモデルを編集しようとすると、Model framework と Path の値が更新されませんでした。この問題は解決されています。
RHOAIENG-2724 - ダイアログ内のフィールドが自動的にリセットされるため、モデルのデプロイメントが失敗する
以前は、モデルをデプロイするか、デプロイされたモデルを編集すると、"Deploy model" ダイアログの Model servers および Model framework フィールドがデフォルトの状態にリセットされる場合がありました。これらの必須フィールドに有効な値が含まれていなくても、Deploy ボタンが有効なままになっている場合がありました。この問題は解決されています。
RHOAIENG-2099 - 新規クラスターでデータサイエンスパイプラインサーバーのデプロイに失敗する
以前は、新しいクラスター上にデータサイエンスパイプラインサーバーを作成すると、ユーザーインターフェイスがロード中のままになり、パイプラインサーバーが起動しませんでした。この問題は解決されています。
RHOAIENG-1199 (以前は ODH-DASHBOARD-1928 として記録されていた問題) - カスタムサービスランタイム作成のエラーメッセージが有用でない
以前は、カスタムのモデルサービングランタイムを作成または編集しようとしてエラーが発生した場合、エラーメッセージにエラーの原因が示されませんでした。このエラーメッセージは改善されました。
RHOAIENG-556 - KServe モデルの ServingRuntime がエラーにもかかわらず作成される
以前は、KServe モデルをデプロイしようとしてエラーが発生した場合でも、InferenceService
カスタムリソース (CR) が作成され、モデルが Data science projects ページに表示されていました。その場合、ステータスが常に不明のままでした。KServe デプロイプロセスが更新され、エラーが発生した場合に ServingRuntime が作成されなくなりました。
RHOAIENG-548 (以前は ODH-DASHBOARD-1776 として記録されていた問題) - ユーザーにプロジェクト管理者権限がない場合のエラーメッセージ
以前は、プロジェクトに対する管理者権限がない場合、一部の機能にアクセスできず、エラーメッセージにその理由が説明されませんでした。たとえば、1 つの namespace にしかアクセスできない環境でモデルサーバーを作成すると、Error creating model server
というエラーメッセージが表示されていました。ただし、モデルサーバーはそのまま正常に作成されます。この問題は解決されています。
RHOAIENG-66 - CodeFlare SDK によってデプロイされた Ray ダッシュボードルートがクラスター証明書の代わりに自己署名証明書を公開する
以前は、openshift_oauth=True
オプションを指定して CodeFlare SDK を使用して Ray クラスターをデプロイすると、デプロイ時に作成される Ray クラスターのルートが passthrough
方式を使用して保護されていました。その結果、OAuth プロキシーで使用される自己署名証明書が公開されていました。この問題は解決されています。
RHOAIENG-12 - 一部のブラウザーから Ray ダッシュボードにアクセスできない
一部のブラウザーでは、ブラウザーがダッシュボード URL の接頭辞を http
から https
に自動的に変更するため、分散ワークロード機能を使用する場合に Ray ダッシュボードにアクセスできないことがありました。この問題は解決されています。
RHODS-6216: ModelMesh oauth-proxy コンテナーが断続的に不安定になる
以前は、ModelMesh oauth-proxy
コンテナーの障害により、ModelMesh Pod が正しくデプロイされませんでした。この問題は、ModelMesh ランタイム環境で認証が有効になっている場合にのみ、断続的に発生していました。この問題は解決されています。
RHOAIENG-535 - HTTP リクエストがない場合、デプロイされたモデルの HTTP リクエストを示すメトリクスグラフが正しくない
以前は、デプロイされたモデルが 2 つのデータタイプ (成功と失敗) それぞれの HTTP リクエストを 1 つ以上受信しなかった場合、(モデルサーバー上のすべてのモデルまたは特定のモデルの) HTTP リクエストのパフォーマンスメトリクスを示すグラフが正しく表示されず、失敗したリクエストの数が一定して増加していることを示す直線が表示されていました。この問題は解決されています。
RHOAIENG-1467 - Serverless net-istio コントローラー Pod が OOM に到達する可能性がある
以前は、Knative net-istio-controller
Pod (KServe の依存関係) が、メモリー不足 (OOM) エラーにより継続的にクラッシュすることがありました。この問題は解決されています。
RHOAIENG-1899 (以前は RHODS-6539 として記録されていた問題) - Anaconda Professional Edition を検証して有効にできない
以前は、ダッシュボードのキー検証が機能しなかったため、Anaconda Professional Edition を有効にすることができませんでした。この問題は解決されています。
RHOAIENG-2269 - (シングルモデル) ダッシュボードにモデルレプリカの正しい数が表示されない
以前は、シングルモデルサービングプラットフォームで、データサイエンスプロジェクトの Models and model servers セクションにモデルレプリカの正しい数が表示されませんでした。この問題は解決されています。
RHOAIENG-2270 - (シングルモデル) ユーザーがモデルのデプロイメント設定を更新できない
以前は、シングルモデルサービングプラットフォームでデプロイしたモデルのデプロイメント設定 (レプリカの数など) を編集できませんでした。この問題は解決されています。
RHODS-8865: Amazon Web Services (AWS) シンプルストレージサービス (S3) バケットリソースを指定しないとパイプラインサーバーの起動に失敗する
以前は、データサイエンスプロジェクトのデータ接続を作成するときに、AWS_S3_BUCKET
フィールドが必須フィールドとして指定されていませんでした。しかし、AWS_S3_BUCKET
フィールドが設定されていないデータ接続を使用してパイプラインサーバーを設定しようとすると、パイプラインサーバーを正常に起動できませんでした。この問題は解決されています。Configure pipeline server ダイアログが更新され、Bucket
フィールドが必須フィールドとして追加されました。
RHODS-12899 - OpenVINO ランタイムに NVIDIA GPU のアノテーションが欠落している
以前は、ユーザーがモデルサーバーのユーザーインターフェイスで OpenVINO model server (supports GPUs) ランタイムを選択し、NVIDIA GPU アクセラレーターを選択した場合、選択したアクセラレーターが選択したランタイムと互換性がないという不要な警告がシステムによって表示されることがありました。この警告は表示されなくなりました。
RHOAIENG-84 - KServe で自己署名証明書を使用できない
以前は、シングルモデルサービングプラットフォームが自己署名証明書をサポートしていませんでした。この問題は解決されています。KServe で自己署名証明書を使用するには、証明書の使用 で説明されている手順に従ってください。
RHOAIENG-164 - Kserve のモデルサーバーレプリカの数がダッシュボードから正しく適用されない
以前は、デフォルト (1) とは異なるモデルサーバーレプリカの数を設定しても、モデル (サーバー) は 1 つのレプリカでデプロイされました。この問題は解決されています。
RHOAIENG-288 - ワークベンチの推奨イメージバージョンラベルが 2 つのバージョンで表示される
OpenShift AI で使用できるワークベンチイメージのほとんどは、複数のバージョンで提供されます。推奨されるバージョンは最新バージョンのみです。Red Hat OpenShift AI 2.4 および 2.5 では、イメージの複数のバージョンに対して 推奨 タグが誤って表示されていました。この問題は解決されています。
RHOAIENG-293 - 非推奨の ModelMesh モニタリングスタックが 2.4 から 2.5 にアップグレードした後も削除されない
Red Hat OpenShift AI 2.5 では、以前の ModelMesh モニタリングスタックは、ユーザーワークロードモニタリングに置き換えられたため、デプロイされなくなりました。ただし、以前のモニタリングスタックは OpenShift AI 2.5 へのアップグレード中に削除されませんでした。一部のコンポーネントは残り、クラスターリソースを使用しました。この問題は解決されています。
RHOAIENG-343 - OpenShift Service Mesh および OpenShift Serverless の手動設定が KServe では機能しない
OpenShift Serverless および OpenShift Service Mesh をインストールしてから、KServe を有効にして Red Hat OpenShift AI をインストールした場合、KServe はデプロイされませんでした。この問題は解決されています。
RHOAIENG-517 - 編集権限を持つユーザーは作成されたモデルを表示できない
編集権限を持つユーザーは、プロジェクト所有者であるか、プロジェクトの管理者権限を持っていない限り、作成されたモデルを表示できませんでした。この問題は解決されています。
RHOAIENG-804 - FIPS 対応クラスター上で KServe を使用して大規模言語モデルをデプロイできない
以前は、Red Hat OpenShift AI はまだ FIPS 向けに完全には設計されていませんでした。FIPS 対応クラスターでは、KServe を使用して大規模言語モデル (LLM) をデプロイすることはできませんでした。この問題は解決されています。
RHOAIENG-908 - KServe が以前に有効化後に削除されているた場合、ModelMesh を使用できない
以前は、DataScienceCluster
オブジェクトで ModelMesh と KServe の両方が有効になっており、その後 KServe を削除すると、ModelMesh を使用して新しいモデルをデプロイできなくなりました。以前に ModelMesh でデプロイされたモデルを引き続き使用できます。この問題は解決されています。
RHOAIENG-2184 - Ray クラスターまたは分散ワークロードを作成できない
以前は、ユーザーは admin
権限または edit
権限を持つ namespace で Ray クラスターまたは分散ワークロードを作成できませんでした。この問題は解決されています。
ODH-DASHBOARD-1991 - ovms-gpu-ootb に推奨アクセラレーターのアノテーションがない
以前は、プロジェクトにモデルサーバーを追加すると、Serving runtime リストに NVIDIA GPU の Recommended serving runtime ラベルが表示されませんでした。この問題は解決されています。
RHOAIENG-807 - ワークベンチの再起動時にアクセラレータープロファイル toleration が削除される
以前は、toleration を含むアクセラレータープロファイルを使用するワークベンチを作成した場合、ワークベンチを再起動すると toleration 情報が削除され、再起動が完了できませんでした。新しく作成された GPU 対応ワークベンチは、最初は起動する可能性がありますが、生成された Pod が永久に保留されたままになるため、その後は正常に再起動されません。この問題は解決されています。
DATA-SCIENCE-PIPELINES-OPERATOR-294: データ受け渡しを使用するスケジュールされたパイプラインの実行で、ステップ間でのデータの受け渡しに失敗するか、ステップ全体が失敗する可能性がある
S3 オブジェクトストアを使用してパイプラインアーティファクトを保存するスケジュールされたパイプラインの実行は、次のようなエラーで失敗する場合があります。
Bad value for --endpoint-url "cp": scheme is missing. Must be of the form http://<hostname>/ or https://<hostname>/
Bad value for --endpoint-url "cp": scheme is missing. Must be of the form http://<hostname>/ or https://<hostname>/
この問題は、スケジュールされたパイプライン実行が原因で S3 オブジェクトストアエンドポイントが Pod に正常に渡されなかったために発生しました。この問題は解決されています。
RHODS-4769: サポートされていない taint が含まれるノード上の GPU をノートブックサーバーに割り当てできない
サポートされている nvidia.com/gpu taint 以外の taint でマークされたノード上の GPU は、ノートブックサーバーの作成時に選択できませんでした。この問題は解決されています。
RHODS-6346: 無効な文字を使用してデータサイエンスプロジェクトを作成すると、不明確なエラーメッセージが表示される
無効な特殊文字を使用してデータサイエンスプロジェクトのデータ接続、ワークベンチ、またはストレージ接続を作成すると、次のエラーメッセージが表示されました。
the object provided is unrecognized (must be of type Secret): couldn't get version/kind; json parse error: unexpected end of JSON input ({"apiVersion":"v1","kind":"Sec ...)
the object provided is unrecognized (must be of type Secret): couldn't get version/kind; json parse error: unexpected end of JSON input ({"apiVersion":"v1","kind":"Sec ...)
このエラーメッセージは、問題を明確に示していませんでした。現在は、エラーメッセージで無効な文字が入力されたことが示されるようになりました。
RHODS-6950: クラスター内のすべての GPU が使用されている場合はワークベンチの GPU をスケールダウンできない
以前のリリースでは、クラスター内のすべての GPU が使用されている場合、ワークベンチ GPU をスケールダウンできませんでした。この問題は、1 つのワークベンチで使用されている GPU と、複数のワークベンチで使用されている GPU に当てはまります。Accelerators リストから None を選択して、GPU をスケールダウンできるようになりました。
RHODS-8939 - 以前のリリースで作成された Jupyter ノートブックのデフォルトの共有メモリーによりランタイムエラーが発生する
リリース 1.31 以降、この問題は解決され、新しいノートブックの共有メモリーはノードのサイズに設定されます。
1.31 より前のリリースで作成された Jupyter ノートブックの場合に、Jupyter ノートブックのデフォルトの共有メモリーは 64 MB に設定されており、ノートブック設定でこのデフォルト値を変更できません。
この問題を修正するには、ナレッジベースの記事 How to change the shared memory for a Jupyter notebook in Red Hat OpenShift AI に記載のプロセスに従う必要があります。
RHODS-9030 - kfdefs
リソースの削除時に OpenShift AI のアンインストールプロセスが停止することがある
OpenShift AI マネージドサービスをアンインストールする手順が、OpenShift AI のアンインストール で説明されています。
しかし、このガイドに従っても、アンインストールプロセスが正常に完了しない場合がありました。代わりに、プロセスは、Kubeflow Operator により使用される kfdefs
リソースを削除するステップで停止したままになっていました。次の例に示すように、kfdefs
リソースは、redhat-ods-applications
、redhat-ods-monitoring
、および rhods-notebooks
namespace に存在する場合があります。
kfdefs
リソースの削除に失敗すると、その後の OpenShift AI の新しいバージョンをインストールできない可能性がありました。この問題は発生しなくなりました。
RHODS-9764: ワークベンチを編集するとデータ接続の詳細がリセットされる
既存のデータ接続があるワークベンチを編集し、Create new data connection オプションを選択すると、新しい接続の詳細の指定が完了する前に、編集ページが Use existing data connection オプションに戻る場合があります。この問題は解決されています。
RHODS-9583: データサイエンスダッシュボードが既存の OpenShift Pipelines インストールを検出しない
OpenShift Pipelines Operator がクラスターにグローバル Operator としてインストールされている場合、OpenShift AI ダッシュボードはそれを検出しませんでした。現在は、OpenShift Pipelines Operator が正常に検出されます。
ODH-DASHBOARD-1639 - ダッシュボードルートの TLS 値が間違っている
以前は、OpenShift で OpenShift AI ダッシュボードのルートが作成されると、tls.termination
フィールドに無効なデフォルト値 Reencrypt
が含まれていました。この問題は解決されています。新しい値は reencrypt
です。
ODH-DASHBOARD-1638: トリガーされた実行タブの名前プレースホルダーにスケジュールされた実行名が表示される
以前は、Pipelines > Runs をクリックし、Triggered タブを選択してトリガーされた実行を設定すると、Name フィールドに表示される値の例は Scheduled run name
でした。この問題は解決されています。
ODH-DASHBOARD-1547: パイプライン Operator がバックグラウンドでインストールされているときに、ダッシュボードに "We can’t find that page" というメッセージが表示される
以前は、ダッシュボードの Data Science Pipelines ページを使用して OpenShift Pipelines Operator をインストールすると、Operator のインストールが完了するとページが更新され、We can't find that page
というメッセージが表示されていました。この問題は解決されています。Operator のインストールが完了すると、ダッシュボードは Pipelines ページにリダイレクトされ、そこでパイプラインサーバーを作成できます。
ODH-DASHBOARD-1545 - モデルタブを展開するとダッシュボードがプロジェクトの一番下までスクロールし続ける
以前は、ダッシュボードの Data science projects ページで、Deployed models タブをクリックして展開し、そのページで他のアクションを実行しようとすると、ページが自動的に Deployed models セクションにスクロールして戻りました。これは、他のアクションを実行する能力に影響を与えました。この問題は解決されています。
NOTEBOOKS-156 - Elyra には Test というサンプルランタイムが含まれている
以前の Elyra には、Test
という名前のランタイム設定の例が含まれていました。データサイエンスパイプラインの実行時にこの設定を選択すると、エラーが発生する可能性があります。Test
設定は削除されました。
RHODS-9622 - スケジュールされたパイプライン実行を複製しても、既存の期間とパイプライン入力パラメーター値がコピーされない
以前は、定期的なトリガーを持つスケジュールされたパイプライン実行を複製した場合、この複製プロセスでは、定期的な実行に設定された頻度や、指定されたパイプラン入力パラメーターはコピーされませんでした。この問題は解決されています。
RHODS-8932 - 定期的なパイプライン実行をスケジュールすると、デフォルトで間違った cron 形式が表示される
cron ジョブを設定して定期的なパイプライン実行をスケジュールすると、OpenShift AI インターフェイスは、デフォルトで間違った形式を表示しました。正しい形式で表示されるようになりました。
RHODS-9374 - 一意でない名前のパイプラインがデータサイエンスプロジェクトのユーザーインターフェイスに表示されない
Elyra をサポートする Jupyter アプリケーションからノートブックを起動する場合、またはワークベンチを使用する場合、実行するパイプラインを送信するときに一意でない名前のパイプラインは、関連するデータサイエンスプロジェクトページの Pipelines セクション、またはデータサイエンスパイプラインページの Pipelines 見出しに表示されませんでした。この問題は解決されています。
RHODS-9329 - カスタムのモデルサービングランタイムをデプロイすると、エラーメッセージが表示されることがある
以前は、OpenShift AI ダッシュボードを使用してカスタムのモデルサービングランタイムをデプロイすると、デプロイプロセスが失敗し、Error retrieving Serving Runtime
というメッセージが表示されることがありました。この問題は解決されています。
RHODS-9064 - アップグレード後、OpenShift AI ダッシュボードで Data Science Pipelines タブが有効化されない
OpenShift AI 1.26 から OpenShift AI 1.28 にアップグレードした場合、OpenShift AI ダッシュボードで Data Science Pipelines タブが有効化されませんでした。この問題は OpenShift AI 1.29 で解決されています。
RHODS-9443 - Elyra パイプラインをエクスポートすると、S3 ストレージ認証情報がプレーンテキストで公開される
OpenShift AI 1.28.0 では、Elyra パイプラインを Python DSL 形式または YAML 形式で JupyterLab からエクスポートすると、生成された出力には、プレーンテキストの S3 ストレージ認証情報が含まれていました。この問題は OpenShift AI 1.28.1 で解決されました。ただし、OpenShift AI 1.28.1 にアップグレードした後、デプロイメントにパイプラインサーバーとデータ接続を備えたデータサイエンスプロジェクトが含まれている場合、修正を有効にするために次の追加アクションを実行する必要があります。
- ブラウザーページを更新します。
- デプロイメントで実行中のワークベンチをすべて停止し、再起動します。
さらに、Elyra ランタイム設定に修正が含まれていることを確認するには、以下のアクションを実行します。
-
JupyterLab の左側のサイドバーで、Runtimes (
) をクリックします。
表示するランタイム設定の上にカーソルを置き、Edit ボタン (
) をクリックします。
Data Science Pipelines runtime configuration ページが開きます。
-
KUBERNETES_SECRET
が Cloud Object Storage Authentication Type フィールドの値として定義されていることを確認します。 - 変更せずにランタイム設定を閉じます。
RHODS-8460 - 共有プロジェクトの詳細を編集すると、ユーザーインターフェイスがエラーを報告せずに読み込み状態のままになる
プロジェクトを編集する権限を持つユーザーがその詳細を編集しようとすると、ユーザーインターフェイスは読み込み中の状態のままになり、適切なエラーメッセージが表示されません。プロジェクトを編集する権限を持つユーザーは、説明など、プロジェクト内のフィールドを編集できません。これらのユーザーは、ワークベンチ、データ接続、ストレージなど、プロジェクトに属するコンポーネントのみを編集できます。
ユーザーインターフェイスには適切なエラーメッセージが表示され、プロジェクトの説明は更新されなくなりました。
RHODS-8482 - データサイエンスパイプライングラフに、実行中のパイプラインのノードエッジが表示されない
YAML コードで Tekton 形式の Parameters
または when
式が含まれていないパイプラインを実行すると、OpenShift AI ユーザーインターフェイスにグラフノードとの間の接続エッジが表示されませんでした。たとえば、runAfter
プロパティーまたは Workspaces
を含むパイプラインを使用する場合、ユーザーインターフェイスには、エッジ接続なしで実行されたパイプラインのグラフが表示されます。OpenShift AI ユーザーインターフェイスには、グラフノードとの間の接続エッジが表示されるようになりました。
RHODS-8923 - パイプラインサーバーを作成しようとしたときに、新しく作成されたデータ接続が検出されない
データサイエンスプロジェクト内からデータ接続を作成し、パイプラインサーバーを作成しようとすると、Configure a pipeline server では作成したデータ接続が検出されませんでした。この問題は解決されています。
RHODS-8461 - プロジェクトを別のユーザーと共有する場合、OpenShift AI ユーザーインターフェイスのテキストが誤解を招く
データサイエンスプロジェクトを別のユーザーと共有しようとすると、ユーザーインターフェイスのテキストは、ユーザーがその説明などの詳細をすべて編集できるという誤解を招くような意味を与えます。ただし、ユーザーが編集できるのは、ワークベンチ、データ接続、ストレージなど、プロジェクトに属するコンポーネントのみです。この問題は解決され、ユーザーインターフェイスのテキストは、ユーザーが詳細をすべて編集できるという誤解を招くような意味を持たなくなりました。
RHODS-8462 - "編集" 権限を持つユーザーが Model Server を作成できない
"編集" 権限を持つユーザーは、トークン認証なしで Model Server を作成できるようになりました。トークン認証を使用して Model Server を作成するには、ユーザーは "管理者" 権限を持っている必要があります。
RHODS-8796 - OpenVINO Model Server ランタイムに、GPU の使用を強制するために必要なフラグがない
OpenShift AI には、OpenVINO Model Server (OVMS) モデルサービングランタイムがデフォルトで含まれています。新しいモデルサーバーを設定してこのランタイムを選択すると、Configure model server ダイアログでモデルサーバーで使用する GPU の数を指定できます。ただし、モデルサーバーの設定を完了し、そこからモデルをデプロイすると、モデルサーバーは実際には GPU を使用しませんでした。この問題は現在解決されており、モデルサーバーは GPU を使用します。
RHODS-8861 - パイプライン実行の作成時にホストプロジェクトを変更すると、使用可能なパイプラインのリストが不正確になる
パイプライン実行の作成中にホストプロジェクトを変更すると、インターフェイスは新しいホストプロジェクトのパイプラインを使用可能にすることができません。代わりに、インターフェイスには、最初に Data Science Pipelines → Runs ページで選択したプロジェクトに属するパイプラインが表示されます。この問題は解決されています。Create run ページからパイプラインを選択する必要はなくなりました。Create run ボタンをクリックすると、現在のプロジェクトとそのパイプラインに基づいて、パイプラインの選択が自動的に更新されます。
RHODS-8249 - ConfigMap としてアップロードされた環境変数が、代わりに Secret に保存される
以前の OpenShift AI インターフェイスでは、ConfigMap
設定をアップロードして環境変数をワークベンチに追加すると、変数は代わりに Secret
オブジェクトに保存されていました。この問題は解決されています。
RHODS-7975 - ワークベンチに複数のデータ接続がある可能性がある
以前は、ワークベンチのデータ接続を変更すると、既存のデータ接続は解放されませんでした。その結果、ワークベンチが複数のデータソースに接続したままになる可能性がありました。この問題は解決されています。
RHODS-7948 - 環境変数を含むシークレットファイルをアップロードすると、値が二重にエンコードされる
以前は、データサイエンスプロジェクトでワークベンチを作成するときに、環境変数を含む YAML ベースのシークレットファイルをアップロードすると、環境変数の値がデコードされませんでした。次に、このプロセスによって作成される結果となる OpenShift シークレットでは、エンコードされた値が再度エンコードされました。この問題は解決されています。
RHODS-6429 - Intel OpenVINO または Anaconda Professional Edition イメージを使用してワークベンチを作成すると、エラーが表示される
以前は、Intel OpenVINO または Anaconda Professional Edition イメージでワークベンチを作成すると、作成プロセス中にエラーが表示されていました。ただし、ワークベンチは正常に作成されています。この問題は解決されています。
RHODS-6372 - アイドル状態のノートブックの選別では、アクティブな端末が考慮されない
以前のバージョンでは、ノートブックイメージに実行中の端末があり、アクティブな実行中のカーネルがない場合、idle notebook culler はノートブックを非アクティブとして検出し、ターミナルを停止していました。この問題は解決されています。
RHODS-5700 - ワークベンチの作成時にデータ接続を作成または接続できない
ワークベンチの作成時に、ユーザーは新しいデータ接続を作成したり、既存のデータ接続に接続したりできませんでした。
RHODS-6281 - 管理者グループがクラスターから削除された場合、OpenShift AI 管理者は設定ページにアクセスできない
以前は、Red Hat OpenShift AI 管理者グループがクラスターから削除された場合、OpenShift AI 管理者ユーザーは OpenShift AI ダッシュボードの Settings ページにアクセスできなくなりました。特に、以下の動作が見られました。
- OpenShift AI 管理者ユーザーが Settings → User management ページにアクセスしようとすると、"Page Not Found" エラーが表示されました。
-
クラスター管理者は、OpenShift AI ダッシュボードの Settings ページへのアクセスを 失うことはありませんでした。クラスター管理者が、Settings → User management ページにアクセスすると、削除された OpenShift AI 管理者グループが OpenShift に存在しないことを示す警告メッセージが表示されました。その後、削除された管理者グループは
OdhDashboardConfig
から削除され、管理者アクセスが復元されました。
この問題は解決されています。
RHODS-1968 - 削除されたユーザーはダッシュボードが更新されるまでログインしたままになる
以前は、Red Hat OpenShift AI ダッシュボードに対するユーザーの権限が取り消された場合、この変更について、ユーザーはダッシュボードページの更新後に初めて気づきました。
この問題は解決されています。ユーザーの権限が取り消されると、更新する必要なしに、OpenShift AI ダッシュボードは 30 秒以内にユーザーをロックアウトします。
RHODS-6384 - 重複したデータ接続を作成するときに、ワークベンチのデータ接続が誤って更新される
既存のデータ接続と同じ名前を含むデータ接続を作成すると、データ接続の作成は失敗していましたが、関連付けられたワークベンチが再起動し、間違ったデータ接続に接続していました。この問題は解決されています。ワークベンチが正しいデータ接続に接続するようになりました。
RHODS-6370 - ワークベンチが最新の toleration の受信に失敗する
以前は、最新の toleration を取得するために、ユーザーは関連するワークベンチを編集し、変更を加えず、ワークベンチを再度保存する必要がありました。ユーザーは、データサイエンスプロジェクトのワークベンチを停止してから再起動すると、最新の toleration の変更を適用できるようになりました。
RHODS-6779 - OpenShift AI 1.20 から OpenShift AI 1.21 にアップグレードした後、モデルのサービングに失敗する
OpenShift AI 1.20 から OpenShift AI 1.21 にアップグレードするときに、modelmesh-serving
Pod が存在しないイメージをプルしようとしたため、イメージプルエラーが発生しました。その結果、OpenShift AI のモデル提供機能を使用してモデルを提供できませんでした。odh-openvino-servingruntime-container-v1.21.0-15
イメージが正常にデプロイされるようになりました。
RHODS-5945 - OpenShift AI で Anaconda Professional Edition を有効化できない
Anaconda Professional Edition を OpenShift AI で使用できるようにすることができませんでした。代わりに、関連する Pod の Events ページに InvalidImageName
エラーが表示されました。Anaconda Professional Edition を有効にできるようになりました。
RHODS-5822 - データサイエンスプロジェクトによって作成された PVC の使用率が 90% および 100% を超えた際に、管理者ユーザーに警告が表示されない
PVC が 90% を超え、容量の 100% を超えたことを示す警告が、データサイエンスプロジェクトによって作成された PVC の管理者ユーザーに表示されませんでした。管理者ユーザーは、PVC が容量の 90% および 100% を超えたときに、ダッシュボードから警告を表示できるようになりました。
RHODS-5889 - データサイエンスノートブックが "保留中" ステータスのままになっている場合に、エラーメッセージが表示されない
ノートブック Pod を作成できなかった場合、OpenShift AI インターフェイスにはエラーメッセージが表示されませんでした。データサイエンスノートブックを生成できない場合は、エラーメッセージが表示されるようになりました。
RHODS-5886 - データサイエンスワークベンチから Hub Control Panel d ダッシュボードに戻ると失敗する
File → Log Out をクリックして、ワークベンチ Jupyter ノートブックからダッシュボードに戻ろうとすると、ダッシュボードにリダイレクトされ、"Logging out" ページが表示されたままになります。同様に、File → Hub Control Panel をクリックしてダッシュボードに戻ろうとすると、誤って Start a notebook server ページにリダイレクトされます。データサイエンスワークベンチから Hub コントロールパネルダッシュボードに戻ると、想定どおりに動作するようになりました。
RHODS-6101 - 管理者はすべてのノートブックサーバーを停止できない
OpenShift AI 管理者は、すべてのノートブックサーバーを同時に停止できませんでした。管理者は、Stop all servers ボタンを使用してすべてのノートブックサーバーを停止し、関連するユーザーの横にあるアクションメニューから Stop server を選択して、1 つのノートブックを停止できるようになりました。
RHODS-5891 - ワークベンチのイベントログが明確に表示されない
ワークベンチを作成するとき、ユーザーは OpenShift AI インターフェイスでイベントログウィンドウを簡単に見つけることができませんでした。Status 列の下の Starting ラベルにカーソルを合わせると、下線が引かれるようになりました。これは、クリックしてノートブックのステータスとイベントログを表示できることを示しています。
RHODS-6296 - Google Chrome 以外のブラウザーを使用すると ISV アイコンがレンダリングされない
Google Chrome 以外のブラウザーを使用すると、Explore および Resources ページの下にあるすべての ISV アイコンがレンダリングされませんでした。サポートされているすべてのブラウザーで ISV アイコンが正しく表示されるようになりました。
RHODS-3182 - Jupyter で使用可能な GPU の誤った数が表示される
ユーザーが Jupyter でノートブックインスタンスを作成しようとしても、GPU が割り当てられているため、スケジューリングに使用できる GPU の最大数は更新されませんでした。Jupyter で、使用可能な GPU の正しい数が表示されるようになりました。
RHODS-5890 - 複数の永続ボリュームが同じディレクトリーにマウントされている場合、ワークベンチの起動に失敗する
同じワークベンチ内の同じマウントフォルダーに複数の永続ボリューム (PV) をマウントすると、ノートブック Pod の作成が失敗し、問題があることを示すエラーが表示されませんでした。
RHODS-5768 - データサイエンスプロジェクトが Red Hat OpenShift AI のユーザーに表示されない
プロジェクトの Display Name プロパティーの末尾にある [DSP]
接尾辞を削除すると、関連するデータサイエンスプロジェクトが表示されなくなりました。ユーザーがこの接尾辞を削除することはできなくなりました。
RHODS-5701 - データ接続設定の詳細が上書きされる
データ接続がワークベンチに追加されると、そのデータ接続の設定の詳細が環境変数に保存されていました。2 番目のデータ接続が追加されると、設定の詳細は同じ環境変数を使用して保存されました。つまり、最初のデータ接続の設定が上書きされました。現時点では、ユーザーは各ワークベンチに最大 1 つのデータ接続を追加できます。
RHODS-5252 - ノートブック Administration ページでは、ユーザーのノートブックサーバーへの管理者アクセスが提供されない
OpenShift AI ダッシュボードからアクセスされるノートブック Administration ページには、管理者がユーザーのノートブックサーバーにアクセスする手段が提供されていませんでした。管理者は、ユーザーのノートブックサーバーの起動または停止のみに制限されていました。
RHODS-2438 - アップグレード時に PyTorch および TensorFlow イメージを利用できない
OpenShift AI 1.3 からそれより後のバージョンにアップグレードする場合、ユーザーは PyTorch および TensorFlow イメージを約 30 分間利用できませんでした。その結果、ユーザーはアップグレードプロセス中に Jupyter で PyTorch および TensorFlow ノートブックを起動できなくなりました。この問題は解決されています。
RHODS-5354 - ノートブックサーバーの起動時に環境変数名が検証されない
環境変数名は、Start a notebook server ページで検証されませんでした。無効な環境変数が追加された場合、ユーザーはノートブックを正常に起動できませんでした。環境変数名がリアルタイムでチェックされるようになりました。無効な環境変数名を入力した場合は、有効な環境変数名はアルファベット、数字、_、-、または . で構成され、数字で始まってはいけないことを示すエラーメッセージが表示されます。
RHODS-4617 - 利用可能な GPU がある場合にのみ、Number of GPUs ドロップダウンが表示される
以前は、GPU ノードが使用可能な場合、Number of GPUs は Start a notebook server ページにのみ表示されていました。クラスターで自動スケーリングマシンプールが定義されている場合は、Number of GPUs のドロップダウンも正しく表示されるようになりました。現在 GPU ノードを使用できない場合でも、クラスターで新しい GPU ノードがプロビジョニングされる可能性があります。
RHODS-5420 - クラスター管理者がクラスター内に存在する唯一のユーザーの場合、管理者アクセス権を取得しない
以前は、クラスター管理者がクラスター内に存在する唯一のユーザーである場合、Red Hat OpenShift 管理者アクセスは自動的に取得されませんでした。管理者アクセスがクラスター管理者ユーザーに正しく適用されるようになりました。
RHODS-4321 - ノートブックの選択中に間違ったパッケージバージョンが表示される
Start a notebook server ページに、CUDA ノートブックイメージの誤ったバージョン番号 (11.7 ではなく 11.4) が表示されました。インストールされている CUDA のバージョンは、このページでは指定されなくなりました。
RHODS-5001 - 管理者ユーザーが無効な toleration をノートブック Pod に追加できる可能性がある
管理者ユーザーは、エラーをトリガーすることなく、Cluster settings ページに無効な toleration を追加できました。無効な toleration が追加されると、ユーザーはノートブックを正常に起動できませんでした。toleration キーがリアルタイムでチェックされるようになりました。無効な toleration 名を入力すると、有効な容認名が英数字、-、_、または . で構成され、英数字で開始および終了する必要があることを示すエラーメッセージが表示されます。
RHODS-5100 - グループロールバインディングがクラスター管理者に適用されない
以前は、クラスター管理者権限を特定のユーザーではなくグループに割り当てると、ダッシュボードは管理グループ内のユーザーの管理者権限を認識できませんでした。グループロールバインディングが、期待どおりにクラスター管理者に正しく適用されるようになりました。
RHODS-4947 - 古い Minimal Python ノートブックイメージがアップグレード後も存続する
OpenShift AI 1.14 から 1.15 にアップグレードした後、Minimal Python ノートブックの古いバージョンが、関連するすべてのパッケージバージョンを含む形で永続します。最小限の Python ノートブックの古いバージョンは、アップグレード後に保持されなくなりました。
RHODS-4935 - ダッシュボードログに "missing x-forwarded-access-token header" というエラーメッセージが過剰に表示される
rhods-dashboard
Pod のログには、readiness プローブが /status
エンドポイントにヒットしたため、"missing x-forwarded-access-token header" ヘッダーエラーメッセージが大量に含まれていました。この問題は解決されています。
RHODS-2653 - サンプル Pachyderm ノートブックで生成されたイメージをフェッチ中にエラーが発生する
ユーザーが Jupyter のサンプル Pachyderm ノートブックを使用してイメージを取得しようとしたときに、エラーが発生しました。エラーには、イメージが見つからなかったと表示されていました。Pachyderm はこの問題を修正しました。
RHODS-4584 - Jupyter が OpenVINO ノートブックイメージを使用したノートブックサーバーの起動に失敗する
Jupyter の Start a notebook server ページは、OpenVINO ノートブックイメージを使用してノートブックサーバーの起動に失敗します。Intel 社は、この問題を修正するために OpenVINO Operator への更新を提供しました。
RHODS-4923 - 使用状況データの収集を無効にした後に非標準のチェックボックスが表示される
Cluster settings ページで使用状況データの収集を無効にした後、ユーザーが OpenShift AI ダッシュボードの別の領域にアクセスしてから Cluster settings ページに戻ると、Allow collection of usage data チェックボックスに非標準のスタイルが適用されていたため、オンまたはオフにすると、他のチェックボックスと同じように表示されませんでした。
RHODS-4938 - Notebook Images ページに間違った見出しが表示される
OpenShift AI ダッシュボードの Settings ページからアクセスできる Notebook Images ページには、ユーザーインターフェイスに間違った見出しが表示されていました。Notebook image settings の見出しは BYON image settings として表示され、Import Notebook images の見出しは Import BYON images として表示されます。正しい見出しが予想通りに表示されるようになりました。
RHODS-4818 - NVIDIA GPU アドオンがインストールされている場合、Jupyter はイメージを表示できない
Start a notebook server ページには、NVIDIA GPU アドオンのインストール後にノートブックイメージが表示されませんでした。イメージが正しく表示され、Start a notebook server ページから起動できるようになりました。
RHODS-4797 - 使用率が 90% および 100% を超えた場合、PVC 使用量制限アラートが送信されない
PVC が 90% を超え、容量の 100% を超えて送信できなかったかどうかを示すアラート。これらのアラートはトリガーされ、予想通りに送信されるようになりました。
RHODS-4366 - Operator の再起動時にクラスター設定がリセットされる
OpenShift AI Operator Pod が再起動されると、クラスター設定がデフォルト値にリセットされ、カスタム設定が削除されることがありました。OpenShift AI Operator は、OpenShift AI の新しいバージョンがリリースされたとき、および Operator を実行するノードに障害が発生したときに再起動されました。この問題は、Operator が ConfigMap を誤ってデプロイするために生じました。Operator デプロイメントの手順が更新され、これが実行されなくなりました。
RHODS-4318 - OpenVINO ノートブックイメージが正常にビルドされない
OpenVINO ノートブックイメージは正常にビルドに失敗し、エラーメッセージを表示していました。この問題は解決されています。
RHODS-3743 - Starburst Galaxy クイックスタートの手順にダウンロードリンクが提供されていない
ダッシュボードの Resources ページにある Starburst Galaxy クイックスタートでは、ユーザーが explore-data.ipynb notebook
を開く必要がありましたが、手順でリンクを提供されませんでした。代わりに、リンクはクイックスタートの導入時に提供されていました。
RHODS-1974 - アラート通知メールを変更するには Pod の再起動が必要
Red Hat OpenShift AI Add-On の通知メールアドレスのリストへの変更は、rhods-operator
Pod と prometheus-*
Pod が再起動されるまで適用されませんでした。
RHODS-2738 - Red Hat OpenShift API Management 1.15.2 アドオンのインストールが正常に完了しない
Red Hat OpenShift API Management 1.15.2 アドオンと統合された OpenShift AI インストールの場合、Red Hat OpenShift API Management インストールプロセスは SMTP 認証情報のシークレットを正常に取得できませんでした。そのため、インストールが完了しませんでした。
RHODS-3237 - GPU チュートリアルがダッシュボードに表示されない
Gtc2018-numba にある "GPU コンピューティングチュートリアル" は、ダッシュボードの Resources ページに表示されませんでした。
RHODS-3069 - GPU ノードが利用できないときに GPU の選択が持続する
ユーザーが GPU をサポートするノートブックサーバーをプロビジョニングし、その後、使用されている GPU ノードがクラスターから削除された場合、ユーザーはノートブックサーバーを作成できませんでした。これは、接続されている GPU の数に最近使用された設定がデフォルトで使用されていたために発生しました。
RHODS-3181 - Pachyderm が OpenShift Dedicated 4.10 クラスターと互換性を持つようになる
Pachyderm は当初、OpenShift Dedicated 4.10 と互換性がなかったため、OpenShift Dedicated 4.10 クラスター上で実行される OpenShift AI では使用できませんでした。Pachyderm は、OpenShift Dedicated 4.10 で利用可能になり、互換性があります。
RHODS-2160 - OpenShift AI と OpenShift API Management の両方がインストールされている場合、アンインストールプロセスが完了しない
OpenShift AI と OpenShift API Management を同じクラスターに共にインストールすると、両方とも同じ Virtual Private Cluster (VPC) を使用します。これらのアドオンのアンインストールプロセスでは、VPC の削除が試行されます。以前は、両方のアドオンがインストールされている場合、一方のサービスのアンインストールプロセスがブロックされていました。これは、VPC 内にもう一方のサービスのリソースがまだ残っているためです。この競合が発生しないように、クリーンアッププロセスが更新されました。
RHODS-2747 - OpenShift AI のアップグレード後にイメージが誤って更新される
OpenShift AI をアップグレードするプロセスが完了した後、Jupyter はノートブックイメージを更新できませんでした。これは、イメージキャッシュメカニズムの問題が原因です。アップグレード後、イメージが正しく更新されるようになりました。
RHODS-2425 - ノートブックの選択中に誤った TensorFlow および TensorBoard が表示される
Start a notebook server ページに、TensorFlow ノートブックイメージの TensorFlow と TensorBoard のバージョン番号 (2.4.0) が正しく表示されませんでした。これらのバージョンは、TensorFlow 2.7.0 および TensorBoard 2.6.0 に修正されています。
RHODS-24339 - 有効なアプリケーションのクイックスタートリンクが表示されない
一部のアプリケーションでは、Enabled ページのアプリケーションタイルに Open quick start リンクが表示されませんでした。その結果、ユーザーは関連するアプリケーションのクイックスタートツアーに直接アクセスできませんでした。
RHODS-2215 - ノートブックの選択中に間違った Python バージョンが表示される
Start a notebook server ページに、TensorFlow および PyTorch ノートブックイメージに対して誤ったバージョンの Python が表示されました。さらに、パッケージバージョン番号の 3 番目の整数が表示されなくなりました。
RHODS-1977 - ノートブックサーバーの起動に失敗した後、10 分間待機する
ノートブックサーバーの起動中に Jupyter リーダー Pod に障害が発生した場合、ユーザーは Pod が再起動するまでノートブックサーバーにアクセスできませんでした。これには約 10 分かかりました。このプロセスは改善され、新しいリーダー Pod が選出されたときにユーザーがサーバーにリダイレクトされるようになりました。このプロセスがタイムアウトになると、ユーザーには 504 Gateway Timeout エラーが表示され、サーバーにアクセスするために更新できます。
第7章 既知の問題 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、Red Hat OpenShift AI の既知の問題と、これらの問題を回避する既知の方法を説明します。
RHOAIENG-29731 - FIPS 対応の IBM Power クラスターで推論サービスの作成が失敗する
FIPS 対応の 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 から 1 へのアップグレード中に、関連する KServe 関連リソースから所有者参照が完全に削除される前に、FeatureTracker
カスタムリソース (CR) が削除されます。その結果、Red Hat OpenShift AI Operator によって最初に Managed
状態で作成され、その後 DataScienceCluster
(DSC) カスタムリソース (CR) で Unmanaged
に変更されたリソースが、意図せず削除される可能性があります。この問題により、リソースが手動で復元されるまでモデルサービング機能が停止する可能性があります。
次のリソースは、2.16 で Unmanaged
に変更された場合、1 で削除される可能性があります。
種類 | namespace | 名前 |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 回避策
OpenShift AI 2.16 から 1 にすでにアップグレード済みの場合は、次のいずれかの操作を実行してください。
-
既存のバックアップがある場合は、
FeatureTracker
CR への所有者参照なしで削除されたリソースを手動で再作成します。 既存のバックアップがない場合は、Operator を使用して、削除されたリソースを再作成できます。
- 再作成済みのリソースをバックアップします。
DSC で、
spec.components.kserve.serving.managementState
をManaged
に設定し、変更を保存して、Operator がリソースを再作成できるようにします。Operator がリソースを再作成するまで待機します。
-
DSC で、
spec.components.kserve.serving.managementState
をUnmanaged
に戻し、変更を保存します。 -
再作成された
KnativeServing
、ServiceMeshMember
、およびGateway
CR リソースに以前のカスタムの変更を再適用します。
まだアップグレードしていない場合は、この問題を防ぐために、アップグレードする前に次の操作を実行してください。
-
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-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
およびMutatingWebhookConfiguration
Webhook を削除します。Webhook を取得します。
oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - KServe が無効になっていることを確認します。
Webhook を取得します。
oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Webhook を削除します。
- KServe を有効にします。
-
KServe Pod が正常に生成され、
knative-serving
namespace 内の Pod がアクティブで動作していることを確認します。
RHOAIENG-16247 - OpenShift AI ダッシュボードから実行を開始すると、Elyra パイプラインの実行出力が上書きされる
Elyra からパイプラインを作成して実行すると、パイプラインの実行によって生成された出力が、オブジェクトストレージのフォルダー bucket-name/pipeline-name-timestamp
に保存されます。
Elyra からパイプラインを作成し、OpenShift AI ダッシュボードからパイプラインの実行を開始すると、タイムスタンプ値が更新されません。これにより、パイプラインの実行によって、同じパイプラインの以前のパイプライン実行によって作成されたファイルが上書きされる可能性があります。
この問題は、OpenShift AI ダッシュボードを使用してコンパイルおよびインポートされたパイプラインには影響しません。これは、オブジェクトストレージで使用されるフォルダーに runid
が常に追加されるためです。データサイエンスパイプラインで使用されるストレージの場所の詳細は、データサイエンスパイプラインのデータの保存 を参照してください。
- 回避策
- Elyra パイプラインにファイルを保存する場合は、パイプライン実行ごとに異なるサブフォルダー名を使用します。
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
- 回避策
既存の
AppWrapper
CRD を削除します。oc delete crd appwrappers.workload.codeflare.dev
$ oc delete crd appwrappers.workload.codeflare.dev
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 約 20 秒待ってから、次の例に示すように、新しい
AppWrapper
CRD が自動的に適用されることを確認します。oc get crd appwrappers.workload.codeflare.dev
$ oc get crd appwrappers.workload.codeflare.dev NAME CREATED AT appwrappers.workload.codeflare.dev 2024-11-22T18:35:04Z
Copy 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-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-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 サポート にお問い合わせください。
RHODS-1888 - アンインストール後も OpenShift AI ハイパーリンクが表示される
OpenShift AI アドオンが OpenShift Dedicated クラスターからアンインストールされても、OpenShift AI インターフェイスへのリンクはアプリケーション起動メニューに表示されたままになります。OpenShift AI は利用できなくなっているため、このリンクをクリックすると "Page Not Found" エラーが発生します。
- 回避策
- なし。
第8章 製品機能 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift AI は、データサイエンティストやクラスター管理者向けに豊富な機能を提供します。詳細は、Red Hat OpenShift AI の概要 を参照してください。