リリースノート
このリリースに関連する機能、機能拡張、解決された問題、および既知の問題
概要
第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. 新機能 リンクのコピーリンクがクリップボードにコピーされました!
- TrustyAI に KServe InferenceLogger 統合のサポートが追加される
TrustyAI は、InferenceLogger 自動設定を通じて KServe 推論のデプロイメントをサポートするようになりました。
KServe Raw と Serverless の両方がサポートされており、デプロイメントモードは
InferenceServiceアノテーションを使用して自動的に検出されます。
- Kueue によるワークロードスケジューリングの強化
OpenShift AI は Red Hat build of Kueue により、ワークロードスケジューリング機能が強化されました。Kueue は、ワークロードのリソースを考慮したスケジューリングを提供し、GPU 使用率を向上させ、AI ワークロード全体でインテリジェントなクォータベースのスケジューリングによって、リソース共有の公平性を確保するジョブキューイングシステムです。
この機能により、OpenShift AI での Kueue のワークロードサポートが拡張され、これまでサポートされていた分散トレーニングジョブ (
RayJob、RayCluster、PyTorchJob) に加えて、ワークベンチ (Notebook) とモデルサービング (InferenceService) が含まれるようになります。検証 webhook がキュー (ポリシー) の適用を処理するようになりました。この webhook により、Kueue 管理が有効になっているプロジェクト (
kueue.openshift.io/managed=trueラベル付き) では、サポートされているすべてのワークロードでターゲットのLocalQueue(kueue.x-k8s.io/queue-nameラベル付き) を指定する必要があります。これは、以前のバージョンで使用されていた Validating Admission Policy に代わるものです。詳細は、Kueue を使用したワークロードの管理 を参照してください。
- イメージ内の git commit ハッシュを表示するためのサポートが追加される
- git commit ハッシュをイメージで表示できるようになりました。この機能を使用すると、バージョン番号が同じであっても、イメージが変更されたかどうかを判断できます。必要に応じて、イメージをソースコードまで追跡できます。
- Elyra によるデータサイエンスパイプラインのサポートが追加される
- Elyra でデータサイエンスパイプラインを使用する場合、ルートベースの URL ではなくサービスベースの URL を使用するオプションが追加されました。ポート番号を含めることで、データサイエンスパイプラインをサービスから直接使用できるようになります。
- ワークベンチイメージはデフォルトでミラーリングされる
イメージをプライベートレジストリーにミラーリングして非接続インストールを行う場合に、ワークベンチイメージの最新バージョンがデフォルトでミラーリングされます。管理者は、Disconnected Helper 設定の
additionalImagesフィールドを通じて、ワークベンチイメージの古いバージョンをミラーリングできます。重要バグ修正とセキュリティー更新が適用された最新バージョンのワークベンチイメージのみがサポートされます。古いバージョンのワークベンチイメージも利用可能ですが、バグ修正やセキュリティー更新は受けられません。
2.2. 機能拡張 リンクのコピーリンクがクリップボードにコピーされました!
- 永続ボリューム要求 (PVC) からのモデルのサービングをサポートするように
- Red Hat OpenShift AI は、既存のクラスターストレージから直接モデルをサービングできるようになりました。この機能を使用すると、既存の永続ボリューム要求 (PVC) の場所からモデルをサービングし、インターフェイス内でモデルストレージ用の新しい PVC を作成できます。
- プロジェクト内の全パイプラインのキャッシングを無効にする新しいオプション
パイプラインサーバー内のすべてのデータサイエンスパイプラインのキャッシュを無効にできるようになりました。これにより、すべてのパイプラインおよびタスクレベルのキャッシュ設定がオーバーライドされます。このグローバル設定は、デバッグ、開発、確定的な再実行が必要な場合などに役立ちます。
このオプションは、パイプラインサーバーを作成または編集するときに Allow caching to be configured per pipeline and task チェックボックスで設定できます。クラスター管理者は、この
spec.apiServer.cacheEnabledオプションを設定することもできます。デフォルトでは、このフィールドは true に設定されています。クラスター全体でキャッシュを無効にするには、このフィールドを false に設定します。詳細は、データサイエンスパイプラインのキャッシングの概要 を参照してください。
- Quay から Red Hat Registry への実稼働環境イメージの移行
- 現在のサポートモデルである RHOAI 実稼働イメージは、Quay から Red Hat Registry に移行されました。これらのイメージは、リリースチャネルで定義された更新を引き続き受信します。過去にリリースされたイメージは Quay に残ります。
- JupyterLab のバージョンが更新された
- JupyterLab がバージョン 4.2 から 4.4 に更新されました。この更新には、フォルダーを右クリックしたときに表示される Move to Trash ドロップダウンオプションのほか、その他のバグ修正と機能強化が含まれています。
- vLLM コンポーネントのバージョンの更新
OpenShift AI は、記載されている各コンポーネントに対して次の vLLM バージョンをサポートしています。
- vLLM CUDA: v0.10.0.2
- vLLM ROCm: v0.10.0.2
- vLLM Gaudi: v0.10.0.2
- vLLM Power/Z: v0.10.0.2
- Openvino Model Server: v2025.2.1
詳細は、GitHub の vllm を参照してください。
第3章 テクノロジープレビュー機能 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、Red Hat OpenShift AI のテクノロジープレビュー機能を説明します。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat では、実稼働環境での使用を推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
- OpenShift AI 上の Llama Stack を使用して生成 AI アプリケーションをビルドする
このリリースでは、OpenShift AI の Llama Stack テクノロジープレビュー機能により、次世代の生成 AI アプリケーションを構築するための Retrieval-Augmented Generation (RAG) とエージェントワークフローが可能になります。この機能は、リモート推論、組み込みのエンベディング、ベクトルデータベース操作をサポートしています。また、安全性を担当する TrustyAI のプロバイダーや、評価を担当する Trusty AI の LM-Eval プロバイダーなどのプロバイダーと統合します。
このプレビューには、Llama Stack Operator を有効にし、RAG ツールを操作し、PDF の取り込みとキーワード検索機能を自動化してドキュメントの検出を強化するためのツール、コンポーネント、ガイダンスが含まれています。
- 集中型プラットフォームメトリクスとトレース
- 集中型プラットフォームメトリクスとトレースが、OpenShift AI のテクノロジープレビュー機能として提供されるようになりました。この機能により、Cluster Observability Operator (COO)、Red Hat build of OpenTelemetry、および Tempo Operator との統合が可能になり、OpenShift AI にオプションですぐに使用できる観測可能性設定が追加されます。また、専用の可観測性スタックも導入されています。今後のリリースでは、専用の可観測性スタックで、インフラストラクチャーのシグナルと顧客のワークロードのシグナルが収集されます。
- Llama Stack Distribution バージョン 0.2.17 のサポート
Llama Stack Distribution には、テクノロジープレビューとして Llama-stack バージョン 0.2.17 が含まれるようになりました。この機能により、次のようなさまざまな機能が実現します。
- モデルプロバイダー: vLLM などのセルフホストプロバイダーが自動的に登録されるようになったため、INFERENCE_MODEL 変数を手動で設定する必要がなくなりました。
- インフラストラクチャーとバックエンド: OpenAI 推論が改善され、Vector Store API のサポートが追加されました。
- エラー処理: エラーが標準化され、ライブラリークライアントの初期化が改善されました。
- アクセス制御: Vector Store および File API でアクセス制御が強制的に適用され、テレメトリー読み取り API はユーザーロールで制御されるようになりました。
- バグの修正。
- IBM Power アクセラレーション Triton 推論サーバーのサポート
Python と ONNX バックエンドを使用して、Triton 推論サーバー (CPU のみ) の Power アーキテクチャーサポートを有効にできるようになりました。Triton 推論サーバーを、Red Hat OpenShift AI のテクノロジープレビューとして IBM Power アーキテクチャー上のカスタムモデルサービングランタイムとしてデプロイできます。
詳細は、Triton Inference Server image を参照してください。
- Kubernetes Event-driven Autoscaling (KEDA) のサポート
OpenShift AI は、標準のデプロイメントモードで Kubernetes Event-driven Autoscaling (KEDA) をサポートするようになりました。このテクノロジープレビュー機能により、推論サービスのメトリクススベースの自動スケーリングが可能になり、アクセラレーターリソースの管理の効率化、運用コストの削減、推論サービスのパフォーマンス向上を実現します。
標準デプロイメントで推論サービスの自動スケーリングを設定するには、KEDA に基づく OpenShift Custom Metrics Autoscaler (CMA) をインストールして設定する必要があります。
この機能の詳細は、メトリクスベースの自動スケーリングの設定 を参照してください。
- LM-Eval モデル評価 UI 機能
- TrustyAI は、使いやすい LM-Eval モデル評価の UI を、テクノロジープレビューとして提供するようになりました。この機能を使用すると、特定のモデルの評価パラメーターを入力し、評価結果ページを返すことすべてを UI から行うことができます。
- LlamaStack で Guardrails Orchestrator を使用する
組み込みの検出コンポーネントを使用して、テクノロジープレビュー機能として Llama Stack を備えた TrustyAI の Guardrails Orchestrator ツールを使用して検出を実行できるようになりました。この機能を使用するには、TrustyAI が有効になっていること、FMS Orchestrator とディテクターが設定されていること、および必要に応じて完全な互換性を確保するために KServe RawDeployment モードが使用されていることを確認してください。手動でのセットアップは必要ありません。
その後、Red Hat OpenShift AI Operator の
DataScienceClusterカスタムリソースで、spec.llamastackoperator.managementStateフィールドをManagedに設定します。詳細は、GitHub の次のリソースを参照してください。
- Kubernetes API を使用したパイプラインの定義および管理
Kubernetes API を使用してデータサイエンスパイプラインとパイプラインバージョンを定義および管理できるようになりました。この方法では、パイプラインとパイプラインバージョンが、内部データベースではなくクラスター内のカスタムリソースとして保存されます。このテクノロジープレビュー機能により、OpenShift GitOps (Argo CD) または同様のツールを使用してパイプラインを管理しやすくなります。同時に、引き続き OpenShift AI ユーザーインターフェイス、API、
kfpSDK を使用してパイプラインを管理することもできます。このオプションはデフォルトで有効になっており、パイプラインサーバーを作成または編集するときに Store pipeline definitions in Kubernetes チェックボックスで設定できます。クラスター管理者は、
DataSciencePipelinesApplication(DSPA) カスタムリソースでspec.apiServer.pipelineStoreフィールドをkubernetesまたはdatabaseに指定し、このオプションを設定することもできます。詳細は、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 を使用して、有効なプロファイルを選択できます。
- 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 開発者プレビュー機能のサポート範囲の詳細は、開発者プレビューのサポート範囲 を参照してください。
- LLM 向け Distributed Inference Server
- Distributed Inference Server (分散ルーティングを備えた vLLM) が開発者プレビュー機能として利用できるようになりました。Distributed Inference Server は、マルチモデルサービング、インテリジェントな推論スケジューリング、分散サービングをサポートし、GenAI モデルでの GPU 使用率を向上させます。
詳細は、Deploying a model by using the LLM Inference Service (LLM-D) を参照してください。
- LM-Eval を使用して TrustyAI-Llama Stack の評価を実行する
組み込みの LM-Eval コンポーネントと高度なコンテンツモデレーションツールを使用して、開発者プレビュー機能として TrustyAI を搭載した Llama Stack で LM-Eval を使用して評価を実行できるようになりました。この機能を使用するには、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. LAB-tuning で今後予定されている非推奨機能 リンクのコピーリンクがクリップボードにコピーされました!
現在テクノロジープレビューとして利用可能な LAB-tuning 機能は、今後のリリースで非推奨になる予定です。大規模言語モデルのカスタマイズに LAB-tuning を使用している場合は、代替の微調整またはモデルカスタマイズ方法が利用可能になったときに、そのような手法に移行することを計画してください。
5.2. 非推奨 リンクのコピーリンクがクリップボードにコピーされました!
5.2.1. 非推奨の CodeFlare Operator リンクのコピーリンクがクリップボードにコピーされました!
OpenShift AI 2.24 以降、CodeFlare Operator は非推奨となり、OpenShift AI の今後のリリースでは削除される予定です。
5.2.2. 非推奨の埋め込み Kueue コンポーネント リンクのコピーリンクがクリップボードにコピーされました!
OpenShift AI 2.24 以降、分散ワークロードを管理するための組み込み Kueue コンポーネントは非推奨になりました。OpenShift AI は、Red Hat Build of Kueue Operator を使用して、分散トレーニング、ワークベンチ、モデルサービングワークロード全体でワークロードスケジューリング機能が強化されました。非推奨の埋め込み Kueue コンポーネントは、どの Extended Update Support (EUS) リリースでもサポートされません。ワークロードがキュー管理を引き続き使用するようにするには、組み込み Kueue コンポーネントから Red Hat Build of Kueue Operator に移行する必要があります。これには OpenShift Container Platform 4.18 以降が必要です。移行するには、次の手順を実行します。
- OperatorHub から Red Hat Build of Kueue Operator をインストールします。
-
DataScienceClusterカスタムリソースを編集して、spec.components.kueue.managementStateフィールドをUnmanagedに設定します。 -
移行後も既存の Kueue 設定 (
ClusterQueueおよびLocalQueue) が保持されることを確認します。
詳細な手順は、Red Hat Build of Kueue Operator への移行 を参照してください。
この非推奨機能は Red Hat OpenShift AI API tiers には影響はありません。
5.2.3. マルチモデルサービングプラットフォーム (ModelMesh) リンクのコピーリンクがクリップボードにコピーされました!
OpenShift AI バージョン 2.19 以降、ModelMesh をベースとしたマルチモデルサービングプラットフォームは非推奨になりました。引き続きモデルをマルチモデルサービングプラットフォームにデプロイできますが、シングルモデルサービングプラットフォームに移行することが推奨されます。
詳細情報やシングルモデルサービングプラットフォームの使用に関するヘルプは、アカウントマネージャーにお問い合わせください。
5.2.4. 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.2.5. アクセラレータープロファイルが非推奨に リンクのコピーリンクがクリップボードにコピーされました!
アクセラレータープロファイルは非推奨になりました。ワークベンチまたはモデルサービングワークロードの特定のワーカーノードをターゲットにするには、ハードウェアプロファイルを使用します。
5.2.6. 非推奨の OpenVINO Model Server (OVMS) プラグイン リンクのコピーリンクがクリップボードにコピーされました!
OpenVINO Model Server (OVMS) の CUDA プラグインは非推奨となり、OpenShift AI の今後のリリースでは使用できなくなります。
5.2.7. 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.2.8. 非推奨のクラスター設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
CodeFlare SDK を使用して Red Hat OpenShift AI で分散ワークロードを実行する場合、Ray クラスター設定の次のパラメーターは非推奨となり、示されているように新しいパラメーターに置き換える必要があります。
| 非推奨パラメーター | 後継パラメーター |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
必要に応じて、新しい extended_resource_mapping および overwrite_default_resource_mapping パラメーターを使用することもできます。これらの新しいパラメーターの詳細は、CodeFlare SDK のドキュメント (外部) を参照してください。
5.3. 削除された機能 リンクのコピーリンクがクリップボードにコピーされました!
5.3.1. Microsoft SQL Server コマンドラインツールの削除 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift AI 2.24 以降、Microsoft SQL Server コマンドラインツール (sqlcmd、bcp) がワークベンチから削除されました。プリインストールされたコマンドラインクライアントを使用して Microsoft SQL Server を管理できなくなりました。
5.3.2. モデルレジストリー ML Metadata (MLMD) サーバーの削除 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift AI 2.23 以降、ML Metadata (MLMD) サーバーはモデルレジストリーコンポーネントから削除されました。モデルレジストリーは、既存のモデルレジストリー API とデータベーススキーマを使用して、基盤となるデータベースと直接対話するようになりました。この変更により、アーキテクチャー全体が簡素化され、ml-metadata コンポーネントからモデルレジストリーから直接データベースアクセスに移行することで、モデルレジストリーの長期的な保守性と効率性が確保されます。
モデルレジストリーのデプロイメントで次のエラーが表示される場合は、データベーススキーマの移行が失敗しています。
error: error connecting to datastore: Dirty database version {version}. Fix and force version.
error: error connecting to datastore: Dirty database version {version}. Fix and force version.
この問題を解決するには、トラフィックを Pod にルーティングする前に、データベースを手動でダーティー状態から 0 に変更します。以下の手順を実行します。
次のようにして、モデルレジストリーデータベース Pod の名前を見つけます。
kubectl get pods -n <your-namespace> | grep model-registry-db<your-namespace>は、モデルレジストリーがデプロイされている namespace に置き換えます。次のように、
kubectl execを使用して、モデルレジストリーデータベース Pod でクエリーを実行します。kubectl exec -n <your-namespace> <your-db-pod-name> -c mysql -- mysql -u root -p"$MYSQL_ROOT_PASSWORD" -e "USE <your-db-name>; UPDATE schema_migrations SET dirty = 0;"<your-namespace>は、モデルレジストリーの namespace に、<your-db-pod-name>は、前の手順で確認した Pod 名に置き換えます。<your-db-name>は、モデルレジストリーデータベース名に置き換えます。これにより、データベース内のダーティー状態がリセットされ、モデルレジストリーが正しく起動できるようになります。
5.3.3. Anaconda の削除 リンクのコピーリンクがクリップボードにコピーされました!
Anaconda は、Python および R プログラミング言語のオープンソースディストリビューションです。OpenShift AI バージョン 2.18 以降、Anaconda は OpenShift AI に含まれなくなり、Anaconda リソースは OpenShift AI でサポートまたは管理されなくなりました。
以前に OpenShift AI から Anaconda をインストールした場合は、クラスター管理者は OpenShift コマンドラインインターフェイスから次の手順を実行して、Anaconda 関連のアーティファクトを削除する必要があります。
Anaconda パスワードを含むシークレットを削除します。
oc delete secret -n redhat-ods-applications anaconda-ce-accessAnaconda 検証 cronjob の
ConfigMapを削除します。oc delete configmap -n redhat-ods-applications anaconda-ce-validation-resultAnaconda イメージストリームを削除します。
oc delete imagestream -n redhat-ods-applications s2i-minimal-notebook-anacondaイメージのダウンロードを検証した Anaconda ジョブを削除します。
oc delete job -n redhat-ods-applications anaconda-ce-periodic-validator-job-custom-runAnaconda cronjob の実行に関連するすべての Pod を削除します。
oc get pods n redhat-ods-applications --no-headers=true | awk '/anaconda-ce-periodic-validator-job-custom-run*/'
5.3.4. データサイエンスパイプライン 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.3.5. Elyra パイプラインで実行される Python スクリプトのパイプラインログは S3 に保存されない リンクのコピーリンクがクリップボードにコピーされました!
Elyra パイプラインで実行されている Python スクリプトのログは、S3 互換ストレージに保存されなくなりました。OpenShift AI バージョン 2.11 以降では、OpenShift AI ダッシュボードのパイプラインログビューアーでこれらのログを表示できます。
この変更を有効にするには、バージョン 2024.1 以降のワークベンチイメージで提供される Elyra ランタイムイメージを使用する必要があります。
古いバージョンのワークベンチイメージがある場合は、プロジェクトワークベンチの更新 の説明に従って、Version selection フィールドを互換性のあるワークベンチイメージバージョン (例: 2024.1) に更新します。
ワークベンチイメージバージョンを更新すると、パイプラインの既存のランタイムイメージの選択がすべて消去されます。ワークベンチのバージョンを更新したら、ワークベンチ IDE を開き、パイプラインのプロパティーを更新してランタイムイメージを選択します。
5.3.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.3.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.3.8. HabanaAI ワークベンチイメージの削除 リンクのコピーリンクがクリップボードにコピーされました!
HabanaAI 1.10 ワークベンチイメージのサポートが削除されました。OpenShift AI バージョン 2.14 以降の新規インストールには、HabanaAI ワークベンチイメージは含まれません。ただし、OpenShift AI を以前のバージョンからアップグレードする場合は、HabanaAI ワークベンチイメージは使用可能なままとなるため、既存の HabanaAI ワークベンチイメージは引き続き機能します。
第6章 解決された問題 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift AI では、次の重要な問題が解決されました。
OCPBUGS-44432 - ImageStream は OpenShift 非接続環境でイメージタグをインポートできない
この更新前は、OpenShift の非接続環境で ImageTagMirrorSet (ITMS) または ImageDigestMirrorSet (IDMS) を使用した場合、ImageStream リソースによってミラーがイメージをインポートできず、RHOAI ワークベンチインスタンスを作成できませんでした。この問題は、OpenShift Container Platform 4.19.13 以降で解決されました。この問題を回避するには、OpenShift インスタンスを 4.19.13 以降に更新してください。
RHOAIENG-29729 - アップグレード後の再起動ループでモデルレジストリー Operator が実行される
モデルレジストリーコンポーネントが有効になっている OpenShift AI 2.22 以前からアップグレードすると、モデルレジストリー Operator が再起動ループに入る可能性があります。これは model-registry-operator-controller-manager Pod 内のマネージャーコンテナーのメモリー制限が不十分なために発生しました。この問題は解決されています。
RHOAIENG-31248 - KServe http: TLS ハンドシェイクエラー
以前は、localmodelcache 検証 webhook 設定の OpenShift CA 自動インジェクションに必要なアノテーションが欠落しているため、TLS ハンドシェイクエラーが繰り返し発生していました。この問題は解決されています。
RHOAIENG-31376 - vLLM ランタイムを使用した推論サービスの作成が IBM Power クラスターで失敗する
以前は、IBM Power クラスターで vLLM ランタイムを使用して推論サービスを作成しようとすると、OpNamespace' '_C_utils' object has no attribute 'init_cpu_threads_env エラーが発生して失敗しました。この問題は解決されています。
RHOAIENG-31377 - IBM Power クラスターで推論サービスの作成が失敗する
以前は、IBM Power クラスターで vLLM ランタイムを使用して推論サービスを作成しようとすると、ValueError: 'aimv2' is already used by a Transformers config, pick another name エラーが発生して失敗しました。この問題は解決されています。
RHOAIENG-31498 - LlamaStack LMEval プロバイダーの推論 URL が正しくない
この更新前は、LMEval プロバイダーを使用して Llama Stack で評価を実行すると、評価ジョブはモデルサーバーのエンドポイントを誤って v1/openai/v1/completions として使用していました。正しいモデルサーバーのエンドポイントが v1/completions であったため、ジョブは失敗しました。この問題は解決されています。
RHOAIENG-31536 - Prometheus の設定が適切に調整されていない
この更新前は、監視リソースは適切に調整されず、2.23 へのアップグレードまたはインストール時に "Not Ready" とのステータスが表示されていました。この問題は、DSCInitialization リソースに新しい監視またはトレース設定が追加されていない場合でも、リソースに OpenTelemetry および Cluster Observability Operator をインストールする必要があったために発生しました。その結果、Prometheus の設定が調整されず、アラート設定が空になったり、古くなったりしました。この問題は解決されています。
RHOAIENG-4148 - 文字数制限によりスタンドアロンノートブックの起動に失敗する
以前は、ノートブックコントローラーロジックは、リソースの作成を試みる前にユーザー名の長さを事前にチェックしませんでした。ノートブックコントローラーは、ユーザー名を直接使用して OpenShift リソースを作成します。その結果、OpenShift Route と名前空間を組み合わせた名前が DNS サブドメインの 63 文字の制限を超えると、OpenShift Route の作成が spec.host: ... must be no more than 63 characters の検証エラーで失敗しました。ルートがないと、依存する OAuthClient を設定できず、ワークベンチを起動できません。
このリリースでは、ノートブックコントローラーのロジックが更新され、リソースを作成する前に名前の文字の長さを事前にチェックするようになりました。ルートの場合、ノートブック名と namespace の合計の長さが 63 文字の制限を超えてしまう場合、コントローラーは接頭辞が nb- の generateName フィールドを使用してルートを作成します。StatefulSets の場合、ノートブック名が 52 文字を超える場合、コントローラーは名前の競合を防ぐために generateName: "nb-" も使用します。
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 の値が表示されました。この問題は解決されています。
RHOAIENG-29352 - Documentation および Support メニュー項目がない
以前は、OpenShift AI のトップナビゲーションバーでヘルプアイコン (
) をクリックすると、メニューには About メニューのみが表示され、Documentation と Support のメニュー項目はありませんでした。この問題は解決されています。
RHAIENG-496 - 管理者以外のユーザーとして LlamaStackDistribution を作成中にエラーが発生する
以前は、デプロイされたロール定義が現在の Llama Stack リソース (LlamaStackDistribution CRD など) に対して古くなっているか不完全であることが原因でロールベースのアクセス制御 (RBAC) が不十分となり、管理者以外のリクエストは失敗していました。この問題は解決されています。
RHOAIENG-27676 - 削除されたケースではアクセラレータープロファイルが正しく動作しない
ワークベンチ、デプロイメント、またはモデルサーバーを作成した後にアクセラレータープロファイルを削除すると、Edit ページでは既存の設定が使用されず、間違ったアクセラレータープロファイルが表示されていました。この問題は解決されています。
RHOAIENG-25733 - アクセラレータープロファイルは重複した名前では正しく動作しない
ワークベンチ、デプロイメント、またはモデルを作成し、プロジェクトスコープの Accelerator プロファイルにグローバルスコープの Accelerator プロファイルと同じ名前を使用すると、Edit ページとサーバーフォームのそれぞれのテーブルとフォームに誤ったラベルが表示されていました。
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-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-35623 - ハードウェアプロファイルを使用するとモデルのデプロイメントが失敗します
Red Hat OpenShift AI Operator は、手動での InferenceService リソース作成時に、ハードウェアプロファイルから tolerations、nodeSelector、または identifiers を基礎となる InferenceService に注入しません。そのため、ハードウェアプロファイルを使用するモデルのデプロイメントは失敗します。その結果、モデルデプロイメント Pod を適切なノードにスケジュールすることができず、デプロイメントが準備完了状態になりません。同じハードウェアプロファイルを使用するワークベンチは、引き続き正常にデプロイされます。
- 回避策
-
ナレッジベースソリューション Workaround for model deployment failure when using hardware profiles で説明されているように、スクリプトを実行して、
tolerations、nodeSelector、またはidentifiersをハードウェアプロファイルから基礎となるInferenceServiceに注入します。
RHOAIENG-33995 - Phi および Mistral モデルの推論サービスのデプロイメントが失敗する
{openshift-platform-url} 4.19 を搭載した IBM Power クラスターで vLLM ランタイムを使用して Phi および Mistral モデルの推論サービスを作成すると、CPU バックエンドに関連するエラーが原因で失敗します。その結果、これらのモデルのデプロイメントが影響を受け、推論サービスの作成が失敗します。
- 回避策
-
この問題を解決するには、CPU および Phi モデルに対して有効になっている場合は、サービスランタイムで
sliding_windowメカニズムを無効にします。スライディングウィンドウは現在 V1 ではサポートされていません。
RHOAIENG-33914 - LM-Eval Tier2 タスクテストに失敗する
古いバージョンの trustyai-service-operator を使用している場合、Massive Multitask Language Understanding Symbol Replacement (MMLUSR) タスクが壊れているため、LM-Eval Tier2 タスクテストで失敗する可能性があります。
- 回避策
-
trustyai-service-operatorの最新バージョンがインストールされていることを確認します。
RHOAIENG-33795 - IBM Z 上の Triton Inference Server の gRPC エンドポイント検証には手動 Route 作成が必要である
gRPC エンドポイントを使用して Triton Inference Server を検証する場合、Route が自動的に作成されません。これは、Operator が現在、デフォルトで REST のみのエッジ終了ルートを作成するために発生します。
- 回避策
この問題を解決するには、IBM Z 上の Triton Inference Server の gRPC エンドポイント検証用に手動でルートを作成する必要があります。
モデルデプロイメント Pod が起動して実行されている場合、次の内容を含む YAML ファイルでエッジ終了
Routeオブジェクトを定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Routeオブジェクトを作成します。oc apply -f <route-file-name>.yaml
oc apply -f <route-file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 推論要求を送信するには、次のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <ca_cert_file> は、クラスタールーターの CA 証明書へのパスです (例: router-ca.crt)。
<triton_protoset_file> は protobuf 記述子ファイルとしてコンパイルされます。protoc -I. --descriptor_set_out=triton_desc.pb --include_imports grpc_service.proto として生成できます。
triton-inference-service GitHub ページから grpc_service.proto および model_config.proto ファイルをダウンロードします。
RHOAIENG-33697 - ステータスが "Started" でない限り、モデルを編集または削除できない
NVIDIA NIM または単一モデルサービングプラットフォームにモデルをデプロイする場合、Starting または Pending 状態のモデルではアクションメニューの Edit および Delete オプションは使用できません。これらのオプションは、モデルが正常にデプロイされた後にのみ使用可能になります。
- 回避策
- モデルを変更したり削除したりするには、モデルが Started 状態になるまで待機します。
RHOAIENG-33645 - LM-Eval Tier1 テストに失敗する
古いバージョンの trustyai-service-operator を使用している場合、ジョブの実行時に confirm_run_unsafe_code が引数として渡されないため、LM-Eval Tier1 テストが失敗する可能性があります。
- 回避策
-
最新バージョンの
trustyai-service-operatorを使用しており、AllowCodeExecutionが有効になっていることを確認してください。
RHOAIENG-32942 - パイプラインストアが Kubernetes に設定されている場合、Elyra パイプラインが失敗する
パイプラインストアが Kubernetes を使用するように設定されている場合、Elyra では REST API でサポートされていない等価 (eq) フィルターが必要になります。このモードでは、サブ文字列フィルターのみがサポートされます。その結果、ワークベンチから Elyra を介して作成および送信されたパイプラインは正常に実行されません。次のエラーが発生し、送信が失敗します。
Invalid input error: Filter eq is not implemented for Kubernetes pipeline store.
Invalid input error: Filter eq is not implemented for Kubernetes pipeline store.
- 回避策
パイプラインを保存するために Kubernetes ではなくデータベースを使用するようにパイプラインサーバーを設定します。
-
パイプラインサーバーを作成するときは、パイプラインストアを
databaseに設定します。 -
サーバーがすでに作成されている場合は、
.spec.pipelineStoreをdatabaseに設定して、DataSciencePipelinesApplicationカスタムリソースを更新します。これにより、dspaPod が再作成されます。
-
パイプラインサーバーを作成するときは、パイプラインストアを
パイプラインストアを database に切り替えると、Elyra パイプラインをワークベンチから正常に送信できるようになります。
RHOAIENG-32897 - Kubernetes API で定義されたパイプラインと無効な platformSpec が UI に表示されないか実行されない
Kubernetes API で定義されたパイプラインバージョンに、空または無効な spec.platformSpec フィールド (たとえば、{} または kubernetes キーなし) が含まれている場合、システムはそのフィールドをパイプライン仕様として誤って識別します。その結果、REST API は pipelineSpec を省略するため、パイプラインのバージョンが UI に表示されなくなり、実行されなくなります。
- 回避策
-
PipelineVersionオブジェクトからspec.platformSpecフィールドを削除します。フィールドを削除すると、パイプラインバージョンが UI に正しく表示され、REST API は期待どおりにpipelineSpecを返します。
RHOAIENG-31386 - authenticationRef を使用した推論サービスのデプロイ中にエラーが発生する
外部メトリクスで authenticationRef を使用して InferenceService をデプロイすると、最初の oc の適用後に authenticationRef フィールドが削除されます。
- 回避策
- フィールドを保持するには、リソースを再適用します。
RHOAIENG-30493 - Kueue 対応プロジェクトでワークベンチを作成するときにエラーが発生する
ダッシュボードを使用して Kueue 対応プロジェクトでワークベンチを作成する場合、クラスターで Kueue が無効になっているか、選択したハードウェアプロファイルが LocalQueue に関連付けられていない場合は、作成に失敗します。この場合、必要な LocalQueue を参照できず、アドミッション Webhook の検証が失敗し、次のエラーメッセージが表示されます。
Error creating workbench admission webhook "kubeflow-kueuelabels-validator.opendatahub.io" denied the request: Kueue label validation failed: missing required label "kueue.x-k8s.io/queue-name"
Error creating workbench
admission webhook "kubeflow-kueuelabels-validator.opendatahub.io" denied the request: Kueue label validation failed: missing required label "kueue.x-k8s.io/queue-name"
- 回避策
cluster-admin 権限を持つユーザーとして、クラスター上で Kueue とハードウェアプロファイルを有効にします。
- oc クライアントを使用して、クラスターにログインします。
-
次のコマンドを実行して、
redhat-ods-applicationsnamespace のOdhDashboardConfigカスタムリソースにパッチを適用します。
oc patch OdhDashboardConfig odh-dashboard-config -n redhat-ods-applications --type=merge -p '{"spec": {"dashboardConfig": {"disableKueue": false, "disableHardwareProfiles": false}}}'
oc patch OdhDashboardConfig odh-dashboard-config -n redhat-ods-applications --type=merge -p '{"spec": {"dashboardConfig": {"disableKueue": false, "disableHardwareProfiles": false}}}'
RHOAIENG-31238 - DSCInitialization の作成時に新しい監視スタックが有効になった
DSCInitialization リソースを削除し、OpenShift AI コンソールフォームビューを使用して新しいリソースを作成すると、テクノロジープレビューの可観測性スタックが有効になります。その結果、DSCInitialization リソースを再作成するときに、不要な可観測性スタックがデプロイメントされることになります。
- 回避策
この問題を解決するには、フォームビューを使用して DSCInitiliazation リソースを再作成するときに、"metrics" と "traces" フィールドを手動で削除します。
テクノロジープレビューの監視スタックを使用する場合、これは必要ありません。
RHOAIENG-32145 - OpenShift バージョン 4.17 より前のバージョンで Llama Stack Operator のデプロイメントに失敗する
4.17 より前のバージョンを実行している OpenShift クラスターに OpenShift AI をインストールすると、統合された Llama Stack Operator (llamastackoperator) のデプロイに失敗する可能性があります。
Llama Stack Operator には Kubernetes バージョン 1.32 以降が必要ですが、OpenShift 4.15 では Kubernetes 1.28 が使用されます。このバージョンの違いにより、Kubernetes 1.32 で導入され、未対応の選択肢付きフィールドが原因で、LlamaStackDistribution カスタムリソース定義 (CRD) を適用するときにスキーマ検証が失敗する可能性があります。
- 回避策
- バージョン 4.17 以降を実行している OpenShift クラスターに OpenShift AI をインストールします。
RHOAIENG-32242 - OpenShift バージョン 4.15 および 4.16 の NetworkPolicies の作成に失敗する
バージョン 4.15 または 4.16 を実行している OpenShift クラスターに OpenShift AI をインストールすると、特定の NetworkPolicy リソースのデプロイメントが失敗する可能性があります。これは、llamastackoperator または関連コンポーネントが redhat-ods-applications などの保護された namespace に NetworkPolicy を作成しようとしたときに発生する可能性があります。このリクエストは、アドミッション webhook networkpolicies-validation.managed.openshift.io によってブロックされる可能性があります。これにより、cluster-admin ユーザーであっても、特定の namespace とリソースへの変更が制限されます。この制限は、self-managed 環境と Red Hat 管理の OpenShift 環境の両方に適用されます。
- 回避策
- バージョン 4.17 以降を実行している OpenShift クラスターに OpenShift AI をデプロイします。webhook の制限が適用されているクラスターの場合は、OpenShift 管理者または Red Hat サポートに連絡して、代わりのデプロイメントパターン、または影響を受ける namespace に対して承認されている変更が何かを判断してください。
RHOAIENG-32599 - IBM Z クラスターで推論サービスの作成が失敗する
IBM Z クラスターで vLLM ランタイムを使用して推論サービスを作成しようとすると、ValueError: 'aimv2' is already used by a Transformers config, pick another name エラーが発生して失敗します。
- 回避策
- なし。
RHOAIENG-29731 - OpenShift 4.19 を使用した IBM Power クラスターで推論サービスの作成が失敗する
OpenShift Container Platform バージョン 4.19 上の IBM Power クラスターで vLLM ランタイムを使用して推論サービスを作成しようとすると、Non-Uniform Memory Access (NUMA) に関連するエラーが原因で失敗します。
- 回避策
-
推論サービスを作成するときに、環境変数
VLLM_CPU_OMP_THREADS_BINDをallに設定します。
RHOAIENG-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 にすでにアップグレード済みの場合は、次のいずれかの操作を実行してください。
-
既存のバックアップがある場合は、
FeatureTrackerCR への所有者参照なしで削除されたリソースを手動で再作成します。 既存のバックアップがない場合は、Operator を使用して、削除されたリソースを再作成できます。
- 再作成済みのリソースをバックアップします。
DSC で、
spec.components.kserve.serving.managementStateをManagedに設定し、変更を保存して、Operator がリソースを再作成できるようにします。Operator がリソースを再作成するまで待機します。
-
DSC で、
spec.components.kserve.serving.managementStateをUnmanagedに戻し、変更を保存します。 -
再作成された
KnativeServing、ServiceMeshMember、およびGatewayCR リソースに以前のカスタムの変更を再適用します。
まだアップグレードしていない場合は、この問題を防ぐために、アップグレードする前に次の操作を実行してください。
-
DSC で、
spec.components.kserve.serving.managementStateをUnmanagedに設定します。 -
上記の表にリストされている影響を受ける
KnativeServing、ServiceMeshMember、およびGatewayリソースごとに、FeatureTrackerの所有者参照を削除して CR を編集します。この編集により、FeatureTrackerに対するリソースの依存関係が削除され、アップグレードプロセス中にリソースが削除されなくなります。
-
既存のバックアップがある場合は、
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-20209 - 要求されたリソースがしきい値を超えても警告メッセージが表示されない
Distributed workloads → Project metrics をクリックし、Requested resources セクションを表示すると、チャートには要求されたリソースの値と各リソースの合計共有クォータ値 (CPU および メモリー) が表示されます。ただし、Requested by all projects の値が、そのリソースの Warning threshold の値を超えると、予想される警告メッセージは表示されません。
- 回避策
- なし。
SRVKS-1301 (以前は RHOAIENG-18590 として文書化されていました) - KServe を無効化にしてから有効化すると、KnativeServing リソースが失敗する
DataScienceCluster で kserve コンポーネントを無効にしてから有効にすると、KnativeServing リソースが失敗する可能性があります。
- 回避策
Knative に関連するすべての
ValidatingWebhookConfigurationおよびMutatingWebhookConfigurationWebhook を削除します。Webhook を取得します。
oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knativeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - KServe が無効になっていることを確認します。
Webhook を取得します。
oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knativeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Webhook を削除します。
- KServe を有効にします。
-
KServe Pod が正常に生成され、
knative-servingnamespace 内の Pod がアクティブで動作していることを確認します。
RHOAIENG-16247 - OpenShift AI ダッシュボードから実行を開始すると、Elyra パイプラインの実行出力が上書きされる
Elyra からパイプラインを作成して実行すると、パイプラインの実行によって生成された出力が、オブジェクトストレージのフォルダー bucket-name/pipeline-name-timestamp に保存されます。
Elyra からパイプラインを作成し、OpenShift AI ダッシュボードからパイプラインの実行を開始すると、タイムスタンプ値が更新されません。これにより、パイプラインの実行によって、同じパイプラインの以前のパイプライン実行によって作成されたファイルが上書きされる可能性があります。
この問題は、OpenShift AI ダッシュボードを使用してコンパイルおよびインポートされたパイプラインには影響しません。これは、オブジェクトストレージで使用されるフォルダーに runid が常に追加されるためです。データサイエンスパイプラインで使用されるストレージの場所の詳細は、データサイエンスパイプラインのデータの保存 を参照してください。
- 回避策
- Elyra パイプラインにファイルを保存する場合は、パイプライン実行ごとに異なるサブフォルダー名を使用します。
RHOAIENG-8294 - OpenShift AI 2.8 をバージョン 2.10 以降にアップグレードするときに CodeFlare エラーが発生する
OpenShift AI 2.8 をバージョン 2.10 以降にアップグレードしようとすると、AppWrapper カスタムリソース定義 (CRD) バージョンとの不一致により、CodeFlare コンポーネントに関する次のエラーメッセージが表示されます。
ReconcileCompletedWithComponentErrors DataScienceCluster resource reconciled with component errors: 1 error occurred: * CustomResourceDefinition.apiextensions.k8s.io "appwrappers.workload.codeflare.dev" is invalid: status.storedVersions[0]: Invalid value: "v1beta1": must appear in spec.versions
ReconcileCompletedWithComponentErrors DataScienceCluster resource reconciled with component errors: 1 error occurred: * CustomResourceDefinition.apiextensions.k8s.io "appwrappers.workload.codeflare.dev" is invalid: status.storedVersions[0]: Invalid value: "v1beta1": must appear in spec.versions
- 回避策
既存の
AppWrapperCRD を削除します。oc delete crd appwrappers.workload.codeflare.dev
$ oc delete crd appwrappers.workload.codeflare.devCopy to Clipboard Copied! Toggle word wrap Toggle overflow 約 20 秒待ってから、次の例に示すように、新しい
AppWrapperCRD が自動的に適用されることを確認します。oc get crd appwrappers.workload.codeflare.dev NAME CREATED AT appwrappers.workload.codeflare.dev 2024-11-22T18:35:04Z
$ oc get crd appwrappers.workload.codeflare.dev NAME CREATED AT appwrappers.workload.codeflare.dev 2024-11-22T18:35:04ZCopy to Clipboard Copied! Toggle word wrap Toggle overflow
RHOAIENG-7716 - パイプライン条件グループのステータスが更新されない
ループ (dsl.ParallelFor) または条件グループ (dsl.lf) を含むパイプラインを実行すると、パイプラインの実行が完了した後でも、UI にループとグループの実行ステータスが表示されます。
- 回避策
アクティブな子タスクがないことを確認することで、パイプラインがまだ実行中かどうかを確認できます。
- OpenShift AI ダッシュボードから、Data Science Pipelines → Runs をクリックします。
- Project リストから、データサイエンスプロジェクトをクリックします。
- Runs タブから、ステータスを確認する必要があるパイプライン実行をクリックします。
条件グループを展開し、子タスクをクリックします。
子タスクに関する情報を含むパネルが表示されます。
パネルで、Task 詳細タブをクリックします。
Status フィールドに、子タスクの正しいステータスが表示されます。
RHOAIENG-6409 - 実行が成功しても、パイプラインログに Cannot save parameter というエラーが表示される
Data Science Pipelines 2.0 を使用してパイプラインを複数回実行すると、パイプラインの実行が成功してもパイプラインログに Cannot save parameter エラーが表示されます。これらのエラーは無視しても問題ありません。
- 回避策
- なし。
RHOAIENG-12294 (以前は RHOAIENG-4812 として文書化されていました) - 分散ワークロードメトリクスから GPU メトリクスが除外される
この OpenShift AI リリースでは、分散ワークロードメトリクスから GPU メトリクスが除外されます。
- 回避策
- なし。
RHOAIENG-4570 - 既存の Argo Workflows インストールがインストールまたはアップグレードと競合する
Data Science Pipelines 2.0 には、Argo Workflows のインストールが含まれています。Red Hat では、Argo Workflows に含まれるこのインスタンスを直接使用することはサポートしていません。Data Science Pipelines 2.0 を備えた OpenShift AI をインストールまたはアップグレードするには、クラスターに Argo Workflows がインストールされていないことを確認してください。詳細は、Data Science Pipelines 2.0 への移行 を参照してください。
- 回避策
-
既存の Argo Workflows インストールを削除するか、
datasciencepipelinesをRemovedに設定してから、インストールまたはアップグレードを続行します。
RHOAIENG-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-2228 - 間隔が 15 秒に設定されている場合、パフォーマンスメトリクスグラフが絶えず変化する
モデルメトリクス画面の Endpoint performance タブで、Refresh interval を 15 秒に、Time range を 1 時間に設定すると、グラフの結果は連続的に変化します。
- 回避策
- なし。
RHOAIENG-2183 - エンドポイントのパフォーマンスグラフに間違ったラベルが表示される場合がある
モデルメトリクス画面の Endpoint performance タブで、グラフツールチップに誤ったラベルが表示される場合があります。
- 回避策
- なし。
RHOAIENG-131 - InferenceService が Loaded と報告した後、gRPC エンドポイントが適切に応答しない
多数の InferenceService インスタンスが生成され、リクエストがダイレクトされると、Service Mesh Control Plane (SMCP) が応答しなくなります。InferenceService インスタンスのステータスは Loaded ですが、gRPC エンドポイントへの呼び出しはエラーとともに返されます。
- 回避策
-
ServiceMeshControlPlaneカスタムリソース (CR) を編集して、Istio Egress Pod と Ingress Pod のメモリー制限を増やします。
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-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 プロキシー設定によりヘッダーからベアラートークンが削除されるため、アプリケーションは適切に動作できなくなります。
- 回避策
- なし。
KUBEFLOW-157: OpenShift AI ダッシュボードからすでにログアウトしている場合、JupyterLab からのログアウトが機能しない
JupyterLab からログアウトする前に OpenShift AI ダッシュボードからログアウトすると、JupyterLab から正常にログアウトされません。たとえば、Jupyter ノートブックの URL がわかっている場合は、これをブラウザーで再度開くことができます。
- 回避策
- OpenShift AI ダッシュボードからログアウトする前に、JupyterLab からログアウトします。
RHODS-7718 - ダッシュボード権限のないユーザーが実行中のワークベンチを無期限に使い続けることができる
Red Hat OpenShift AI 管理者がユーザーの権限を取り消しても、引き続きユーザーは実行中のワークベンチを無期限で使用できます。
- 回避策
- OpenShift AI 管理者がユーザーの権限を取り消す場合、管理者はそのユーザーに対して実行中のワークベンチも停止する必要があります。
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 ドライバーがデプロイされるまで、これらのノードを準備ができていないと見なします。
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 アナリティクスツールキットクイックスタートでは、手順の一部としてサンプルノートブックをロードする必要がありますが、関連するリポジトリーに存在しないノートブックを参照しています。
- 回避策
- なし。
RHODS-3984: ノートブックの選択時に誤ったパッケージバージョンが表示される
OpenShift AI インターフェイスで、Start a notebook server ページに、oneAPI AI Analytics Toolkit ノートブックイメージに含まれる JupyterLab パッケージおよび Notebook パッケージの誤ったバージョン番号が表示されます。このページには、このイメージが使用する Python バージョンの誤った値が表示される場合もあります。
- 回避策
-
oneAPI AI Analytics Toolkit ノートブックサーバーを起動するときに、ノートブックセルで
!pip listコマンドを実行すると、ノートブックサーバーにインストールされている Python パッケージと、所有しているパッケージのバージョンを確認できます。
RHOAING-1147 (以前は RHODS-2881 として記録されていた問題) - ダッシュボード上のアクションが明確に表示されない
無効になったアプリケーションのライセンスを再検証し、無効になったアプリケーションのタイルを削除するダッシュボードアクションは、ユーザーには明確に表示されません。これらのアクションは、ユーザーがアプリケーションタイルの Disabled ラベルをクリックすると表示されます。その結果、意図したワークフローがユーザーにとって明確でない場合があります。
- 回避策
- なし。
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 の概要 を参照してください。