リリースノート


Red Hat OpenShift AI Self-Managed 2.22

このリリースに関連する機能、機能拡張、解決された問題、および既知の問題

概要

本リリースノートでは、Red Hat OpenShift AI のバージョン 2.22.3 の新機能、機能拡張、解決された問題、および既知の問題の概要を説明します。

第1章 OpenShift AI の概要

Red Hat OpenShift AI は、人工知能および機械学習 (AI/ML) アプリケーションのデータサイエンティストおよび開発者向けのプラットフォームです。

OpenShift AI は、オンプレミスまたはクラウドで AI/ML モデルとアプリケーションを開発、トレーニング、提供、テスト、監視するための環境を提供します。

OpenShift AI には、データサイエンティスト向けに、Jupyter のほか、モデル開発に必要なツールとライブラリーで最適化されたデフォルトのワークベンチイメージ群、そして TensorFlow および PyTorch フレームワークが含まれています。モデルのデプロイおよびホスト、モデルの外部アプリケーションへの統合、任意のハイブリッドクラウド環境でホストするためのモデルのエクスポートを行います。Docker コンテナーを使用して、データサイエンスパイプラインを備えたポータブル機械学習 (ML) ワークフローを構築することで、OpenShift AI でデータサイエンスプロジェクトを強化できます。グラフィックスプロセッシングユニット (GPU) と Intel Gaudi AI アクセラレーターを使用して、データサイエンスの実験を加速することもできます。

管理者向けに、OpenShift AI は、既存の Red Hat OpenShift または ROSA 環境で、データサイエンスワークロードを有効にします。既存の OpenShift アイデンティティープロバイダーを使用してユーザーを管理し、ワークベンチで利用可能なリソースを管理し、データサイエンティストがモデルの作成、トレーニング、ホストに必要なリソースを確実に入手できるようにします。アクセラレーターを使用するとコストを削減でき、データサイエンティストはグラフィックスプロセッシングユニット (GPU) と Intel Gaudi AI アクセラレーターを使用して、エンドツーエンドのデータサイエンスワークフローのパフォーマンスを向上できます。

OpenShift AI には、次の 2 つのデプロイ方法があります。

  • オンプレミスまたはクラウドにインストールできる セルフマネージド型ソフトウェア。OpenShift AI Self-Managed は、OpenShift Container Platform などのセルフマネージド環境、または Red Hat OpenShift Dedicated (AWS または GCP の Customer Cloud Subscription 付き)、Red Hat OpenShift Service on Amazon Web Services (ROSA classic または ROSA HCP)、Microsoft Azure Red Hat OpenShift などの Red Hat が管理するクラウド環境にインストールできます。
  • Red Hat OpenShift Dedicated (AWS または GCP の Customer Cloud Subscription を使用) または Red Hat OpenShift Service on Amazon Web Services (ROSA classic) にアドオンとしてインストールされる マネージドクラウドサービス

    OpenShift AI Cloud Service の詳細は、Red Hat OpenShift AI の製品ドキュメント を参照してください。

OpenShift AI でサポートされているソフトウェアプラットフォーム、コンポーネント、依存関係の詳細は、ナレッジベースの記事 Red Hat OpenShift AI: サポートされる構成 を参照してください。

2.22 リリースのライフサイクル (フルサポートフェーズ期間を含む) の詳細は、ナレッジベース記事 Red Hat OpenShift AI Self-Managed のライフサイクル を参照してください。

第2章 新機能および機能拡張

このセクションでは、Red Hat OpenShift AI 2.22 の新機能と機能拡張を説明します。

2.1. 新機能

モデルサービングランタイムのバージョン情報の表示

この更新により、各モデルサービングランタイムのバージョンを表示できるようになりました。ランタイムバージョンはダッシュボードの次の場所に表示されます。

  • Serving runtimes ページ
  • SettingsServing runtimes
  • Models and model servers ページの Serving runtimes
注記

カスタムランタイムのバージョンは自動的に表示されません。カスタムランタイムのランタイムバージョンを表示するには、ServingRuntime オブジェクトに opendatahub.io/runtime-version をアノテーションとして追加してください。

ストレージクラスのアクセスモードを選択する機能
データサイエンスプロジェクトまたはワークベンチにクラスターストレージを追加するときに、管理者の設定に基づいてストレージクラスのアクセスモードを選択できるようになりました。アクセスモードは、ノードがボリュームにアクセスする方法を定義する Kubernetes 設定です。この更新により、ワークベンチの共有データの管理における柔軟性と効率性が向上します。以前は、すべてのストレージクラスのデフォルトが ReadWriteOnce (RWO) に設定されていたため、複数のユーザーが共同作業のために同じストレージクラスを共有することができませんでした。

2.2. 機能拡張

vLLM コンポーネントのバージョンの更新

OpenShift AI は、記載されている各コンポーネントに対して次の vLLM バージョンをサポートしています。

  • vLLM CUDA v0.9.0.1 (FIPS 向けに設計)
  • vLLM ROCm v0.8.4.3 (FIPS 向けに設計)
  • vLLM Power v0.9.1
  • vLLM Z v0.9.1 (FIPS 向けに設計)
  • vLLM Gaudi v0.7.2.post1

    詳細は、GitHub の vllm を参照してください。

LLM-as-a-Judge メトリクスのサポートの追加

TrustyAI の LM-Eval で LLM-as-a-Judge メトリクスを使用できるようになりました。大規模言語モデル (LLM) を人間のような評価者として使用し、創造的な文章の評価など、簡単に定量化できない別の LLM の出力品質を評価できます。これは、LLM-as-a-Judge (LLMaaJ) と呼ばれています。

評価例は、LM-Eval の設定例 を参照してください。

分散ワークロード: 追加のトレーニングイメージがテストおよび検証済み

次の追加のトレーニングイメージは、テスト済みおよび検証済みです。

  • CUDA 互換の Ray クラスターイメージ

    新しい Ray ベースのトレーニングイメージ quay.io/modh/ray:2.46.0-py311-cu121 がテストおよび検証されました。このイメージは、CUDA 12.1 でサポートされている AMD アクセラレーターと互換性があります。

  • ROCm 互換の Ray クラスターイメージ

    ROCm 互換の Ray クラスターイメージ quay.io/modh/ray:2.46.0-py311-rocm62 がテストおよび検証されました。このイメージは、ROCm 6.2 でサポートされている AMD アクセラレーターと互換性があります。

注記

これらのイメージは AMD64 イメージであり、他のアーキテクチャーでは動作しない可能性があります。Red Hat OpenShift AI で利用可能な最新のトレーニングイメージの詳細は、Red Hat OpenShift AI でサポートされる構成 を参照してください。

OpenShift AI Operator の信頼性の向上
OpenShift AI Operator が、1 つのインスタンスではなく 3 つのレプリカで実行されるようになり、実稼働ワークロードの回復力と信頼性が向上しました。この機能拡張により、OpenShift AI サービスの中断が低減し、Webhook 操作が複数のインスタンスに分散されます。
データサイエンスパイプラインにおける Kubeflow Pipelines 2.5.0 のサポート
データサイエンスパイプラインが Kubeflow Pipelines (KFP) バージョン 2.5.0 にアップグレードされました。詳細は、Kubeflow Pipelines のリリースドキュメント を参照してください。
ノートブックコントローラーによる Elyra リソースの自動作成

以前は、elyra-pipelines-<notebook-name> RoleBinding および ds-pipeline-config Secret リソースがダッシュボードコンポーネントによってプロビジョニングされていました。しかし、このコンポーネントにはコントローラーのライフサイクル管理との統合が欠けていました。また、このような依存関係により、パイプライン機能のみが必要な場合でも、OpenShift AI ダッシュボードをデプロイする必要がありました。

このリリースでは、ノートブックコントローラーによってこれらのリソースが自動的に作成されます。そのため、ダッシュボードコンポーネントに依存せずにワークベンチとパイプラインを使用できます。この変更により、セットアップが簡素化され、ライフサイクル管理の一貫性が向上します。

Seldon MLServer バージョン 1.6.1 ランタイムがテストおよび検証済み

Red Hat は、Seldon MLServer バージョン 1.6.1 ランタイムをテストおよび検証し、一般的な予測 AI モデルとの互換性を向上させました。KServe (REST および gRPC) で次のモデルをテストしました。

  • Scikit-learn
  • XGBoost
  • LightGBM
  • CatBoost
  • MLflow
  • Hugging Face
モデルレジストリーの Operator 依存関係の削除

OpenShift AI のモデルレジストリーコンポーネントを使用するために、Red Hat Authorino、Red Hat OpenShift Serverless、および Red Hat OpenShift Service Mesh Operator が必要なくなりました。

既存のモデルレジストリーインスタンスは、OpenShift OAuth プロキシー認証を使用するように自動的に移行されます。OpenShift AI ダッシュボードから作成された新しいモデルレジストリーインスタンスは、デフォルトで OAuth プロキシーを使用します。古い v1alpha1 API と Istio 設定を使用して作成された新しいインスタンスは、OAuth プロキシーを使用するように自動的に更新されます。

Kubernetes RBAC リソースなど、古いモデルレジストリーインスタンスの既存の認可設定は、引き続き期待どおりに機能します。

第3章 テクノロジープレビュー機能

重要

このセクションでは、Red Hat OpenShift AI 2.22 のテクノロジープレビュー機能を説明します。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat では、実稼働環境での使用を推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

プロジェクト内の全パイプラインのキャッシングを無効にする新しいオプション
クラスター管理者は、パイプラインサーバー内の全データサイエンスパイプラインのキャッシングを無効にできるようになりました。このグローバル設定は、デバッグ、開発、確定的な再実行が必要な場合などに役立ちます。この設定を適用するには、DataSciencePipelinesApplication (DSPA) カスタムリソースで spec.apiServer.cacheEnabled フィールドを false に設定します。詳細は、データサイエンスパイプラインのキャッシングの概要 を参照してください。
Kubernetes API を使用したパイプラインの定義および管理
Kubernetes API を使用してデータサイエンスパイプラインとパイプラインバージョンを定義および管理できるようになりました。この方法では、パイプラインとパイプラインバージョンが、内部データベースではなくクラスター内のカスタムリソースとして保存されます。このテクノロジープレビュー機能により、OpenShift GitOps (Argo CD) または同様のツールを使用してパイプラインを管理しやすくなります。同時に、引き続き OpenShift AI ユーザーインターフェイス、API、kfp SDK を使用してパイプラインを管理することもできます。この機能を有効にするには、DataSciencePipelinesApplication (DSPA) カスタムリソースの spec.apiServer.pipelineStore フィールドを kubernetes に設定します。詳細は、Kubernetes API を使用したパイプラインの定義 を参照してください。
LAB-tuning によるモデルのカスタマイズ

LAB-tuning がテクノロジープレビュー機能として提供され、データサイエンティストは大規模言語モデル (LLM) をカスタマイズするためのエンドツーエンドのワークフローを実行できるようになりました。LAB (Large-scale Alignment for chatBots) メソッドは、タクソノミーガイドによる合成データ生成 (SDG) と多段階のトレーニングアプローチを活用して、従来のファインチューニングに代わるより効率的な方法を提供します。

データサイエンティストは、新しい事前設定済みの InstructLab パイプラインを使用して、OpenShift AI ダッシュボードから直接 LAB-tuning ワークフローを実行できるため、チューニングプロセスが簡素化されます。LAB-tuning の有効化と使用の詳細は、LAB-tuning の有効化 および LAB-tuning を使用したモデルのカスタマイズ を参照してください。

重要

LAB-tuning 機能は、現在、非接続環境ではサポートされていません。

Red Hat OpenShift AI モデルカタログ

Red Hat OpenShift AI モデルカタログがテクノロジープレビュー機能として利用可能になりました。この機能は、ユーザーを Granite ファミリーのモデル、および LAB-tuning で使用される教師モデルとジャッジモデルに接続するところから始まります。

注記

モデルカタログ機能は現在、非接続環境ではサポートされていません。

新しい Feature Store コンポーネント

Red Hat OpenShift AI Operator で、Feature Store を設定可能なコンポーネントとしてインストールおよび管理できるようになりました。オープンソースの Feast プロジェクトをベースにした Feature Store は、ML モデルとデータ間の橋渡しとして機能し、ML ライフサイクル全体にわたって一貫性のあるスケーラブルな機能管理を可能にします。

このテクノロジープレビューリリースでは、次の機能が導入されています。

  • 機能を一貫して再利用できるようにする集中型機能リポジトリー
  • ML モデルの特徴量を定義、管理、取得するためのプログラムおよびコマンドライン操作用の Python SDK および CLI
  • 機能の定義と管理
  • 幅広いデータソースのサポート
  • 特徴量の具体化によるデータ取り込み
  • オンラインモデル推論とオフラインモデルトレーニングの両方のための特徴量検索
  • ロールベースのアクセス制御 (RBAC) による機密機能の保護
  • サードパーティーのデータおよびコンピュートプロバイダーとの拡張性と統合
  • 企業の ML 要件を満たすスケーラビリティー
  • 検索可能な特徴量カタログ
  • 可観測性を高めるデータ系統追跡

    設定の詳細は、Feature Store の設定 を参照してください。

IBM Power および IBM Z アーキテクチャーのサポート
IBM Power (ppc64le) および IBM Z (s390x) アーキテクチャーがテクノロジープレビュー機能としてサポートされるようになりました。現在、これらのアーキテクチャーでは standard モードでのみモデルをデプロイできます。
IBM Power および IBM Z アーキテクチャーでの vLLM のサポート
vLLM ランタイムテンプレートは、テクノロジープレビューとして IBM Power および IBM Z アーキテクチャーで使用できます。
ノードセレクターを使用して、Red Hat OpenShift AI ダッシュボードの特定ワーカーノードに対するワークベンチのターゲットデプロイメントを有効にします。

ハードウェアプロファイルがテクノロジープレビューとして利用できるようになりました。ハードウェアプロファイル機能を使用すると、ユーザーはワークベンチまたはモデルサービングワークロードの特定のワーカーノードをターゲットにすることができます。これにより、ユーザーは特定のアクセラレータータイプまたは CPU のみのノードをターゲットにすることができます。

この機能は、現在のアクセラレータープロファイル機能とコンテナーサイズセレクターフィールドに代わるもので、さまざまなハードウェア設定を対象とするより幅広い機能セットを提供します。アクセラレータープロファイル、taint、および toleration は、ワークロードをハードウェアにマッチングする機能を提供しますが、特に一部のノードに適切な taint がない場合、ワークロードが特定のノードに配置されるかどうかは保証されません。

ハードウェアプロファイル機能は、アクセラレーターと CPU のみの設定の両方とノードセレクターをサポートします。これにより、特定のワーカーノードのターゲット設定機能が強化されます。管理者は設定メニューでハードウェアプロファイルを設定できます。該当する場合、ユーザーはワークベンチ、モデルサービング、およびデータサイエンスパイプラインの UI を使用して、有効なプロファイルを選択できます。

Ray クラスターと PyTorchJob 作成のための必須の Kueue ローカルキューラベル付けポリシー

クラスター管理者は、Validating Admission Policy 機能を使用して、Ray クラスターと PyTorchJob リソースに Kueue ローカルキュー識別子を強制的にラベル付けできます。このラベル付けにより、キュー管理ポリシーに基づいてワークロードが適切に分類およびルーティングされるようになり、リソースの競合が防止され、運用効率が向上します。

ローカルキューのラベル付けポリシーが適用されると、Ray クラスターと PyTorchJob はローカルキューを使用するように設定されている場合にのみ作成され、Ray クラスターと PyTorchJob リソースは Kueue によって管理されます。ローカルキューのラベル付けポリシーは、デフォルトではすべてのプロジェクトに適用されますが、一部またはすべてのプロジェクトに対して無効にできます。ローカルキューのラベル付けポリシーの詳細は、ローカルキューの使用の強制 を参照してください。

注記

これまで Kueue ローカルキューを使用して Ray クラスターおよび PyTorchJob リソースを管理していなかった場合は、この機能により、重大な変更が生じる可能性があります。

RStudio Server ワークベンチイメージ

RStudio Server ワークベンチイメージを使用すると、R の統合開発環境である RStudio IDE にアクセスできます。R プログラミング言語は、データ分析と予測をサポートする統計コンピューティングとグラフィックスに使用されます。

RStudio Server ノートブックイメージを使用するには、まずシークレットを作成し、BuildConfig をトリガーしてイメージをビルドします。次に、rstudio-rhel9 イメージストリームを編集して OpenShift AI UI でイメージを有効にする必要があります。詳細は、RStudio Server ワークベンチイメージのビルド を参照してください。

重要

免責事項: Red Hat は、OpenShift AI のワークベンチの管理をサポートしています。ただし、Red Hat は RStudio ソフトウェアのサポートを提供していません。RStudio Server は rstudio.org から入手できます。RStudio Server には RStudio のライセンス条項が適用されます。このサンプルワークベンチを使用する前に、ライセンス条項を確認してください。

CUDA - RStudio Server ワークベンチイメージ

CUDA - RStudio Server ワークベンチイメージを使用すると、RStudio IDE および NVIDIA CUDA Toolkit にアクセスできます。RStudio IDE は、統計コンピューティングおよびグラフィックス用の R プログラミング言語の統合開発環境です。NVIDIA CUDA Toolkit を使用すると、GPU により高速化されたライブラリーと最適化ツールを使用して作業を強化できます。

CUDA - RStudio Server ワークベンチイメージを使用するには、まずシークレットを作成し、BuildConfig をトリガーしてイメージをビルドします。次に、rstudio-rhel9 イメージストリームを編集して OpenShift AI UI でイメージを有効にする必要があります。詳細は、RStudio Server ワークベンチイメージのビルド を参照してください。

重要

免責事項: Red Hat は、OpenShift AI のワークベンチの管理をサポートしています。ただし、Red Hat は RStudio ソフトウェアのサポートを提供していません。RStudio Server は rstudio.org から入手できます。RStudio Server には RStudio のライセンス条項が適用されます。このサンプルワークベンチを使用する前に、ライセンス条項を確認してください。

CUDA - RStudio Server ワークベンチイメージには、NVIDIA CUDA テクノロジーが含まれています。CUDA のライセンス情報は、CUDA Toolkit のドキュメントで入手できます。このサンプルワークベンチを使用する前に、ライセンス条項を確認してください。

モデルレジストリー
OpenShift AI が Model Registry Operator をサポートするようになりました。Model Registry Operator は、テクノロジープレビューモードではデフォルトではインストールされていません。モデルレジストリーは、機械学習モデルの開始からデプロイメントまでに関するメタデータを格納する中央リポジトリーです。
非常に大規模なモデルのマルチノードデプロイメントのサポート
シングルモデルサービングランタイムの使用時に、複数のグラフィカルプロセッシングユニット (GPU) ノードを介してモデルを提供することが、テクノロジープレビュー機能として利用できるようになりました。大規模言語モデル (LLM) などの大規模なモデルをデプロイする際の効率を向上させるには、複数の GPU ノードにモデルをデプロイします。詳細は、複数の GPU ノードにわたるモデルのデプロイ を参照してください。

第4章 開発者プレビュー機能

重要

このセクションでは、Red Hat OpenShift AI 2.22 の開発者プレビュー機能を説明します。開発者プレビュー機能は、Red Hat ではいかなる形でもサポートされていません。また、機能的には完全ではなく、実稼働環境に対応していません。開発者プレビュー機能を実稼働ワークロードまたはビジネスクリティカルなワークロードには使用しないでください。開発者プレビュー機能は、Red Hat 製品に追加される可能性がある機能をいち早く提供することを目的としています。お客様はこの機能を使用してテストし、開発プロセス中にフィードバックを提供できます。開発者プレビュー機能は、ドキュメントが提供されていない場合があり、随時変更または削除される可能性があります。また、限定的なテストしか行われていません。Red Hat は、関連する SLA なしで、開発者プレビュー機能に関するフィードバックを送信する方法を提供する場合があります。

Red Hat 開発者プレビュー機能のサポート範囲の詳細は、開発者プレビューのサポート範囲 を参照してください。

Llama Stack 開発者プレビュー: OpenShift AI による生成 AI アプリケーションの構築

このリリースでは、OpenShift AI の Llama Stack 開発者プレビュー機能により、次世代の生成 AI アプリケーションを構築するための Retrieval-Augmented Generation (RAG) とエージェントワークフローが可能になります。この機能は、リモート推論、組み込みのエンベディング、ベクトルデータベース操作をサポートしています。また、安全性を担当する TrustyAI のプロバイダーや、評価を担当する Trusty AI の LM-Eval プロバイダーなどのプロバイダーと統合します。

このプレビューには、Llama Stack Operator を有効にし、RAG ツールを操作し、PDF の取り込みとキーワード検索機能を自動化してドキュメントの検出を強化するためのツール、コンポーネント、ガイダンスが含まれています。

TrustyAI-Llama Stack の安全性とガードレールの評価の実行

開発者プレビュー機能として、組み込みの LM-Eval コンポーネントと高度なコンテンツモデレーションツールを使用しながら、Llama Stack 上で TrustyAI を使用して評価を実行し、ガードレールを適用できるようになりました。この機能を使用するには、TrustyAI が有効になっていること、FMS Orchestrator とディテクターが設定されていること、および必要に応じて完全な互換性を確保するために KServe RawDeployment モードが使用されていることを確認してください。手動でのセットアップは必要ありません。

その後、Red Hat OpenShift AI Operator の DataScienceCluster カスタムリソースで、spec.llamastackoperator.managementState フィールドを Managed に設定します。

詳細は、GitHub の次のリソースを参照してください。

LLM Compressor の統合

LLM Compressor 機能が、開発者プレビュー機能として Red Hat OpenShift AI で利用できるようになりました。llm-compressor ライブラリーを含む新しいワークベンチイメージと対応するデータサイエンスパイプラインランタイムイメージにより、大規模言語モデル (LLM) の圧縮と最適化が容易になり、vLLM を使用した効率的なデプロイメントが可能になります。詳細は、GitHub の llm-compressor を参照してください。

LLM コンプレッサーの機能は次の 2 つの方法で使用できます。

Kueue での AppWrapper のサポート
Kueue での AppWrapper のサポートは、開発者プレビュー機能として利用できます。実験的な API により、分散ワークロード機能で AppWrapper ベースのワークロードを使用できます。

第5章 サポートの削除

このセクションでは、Red Hat OpenShift AI のユーザー向け機能のサポートにおける主な変更を説明します。OpenShift AI でサポートされているソフトウェアプラットフォーム、コンポーネント、依存関係の詳細は、ナレッジベースの記事 Red Hat OpenShift AI: サポートされる構成 を参照してください。

5.1. 非推奨の機能

5.1.1. マルチモデルサービングプラットフォーム (ModelMesh)

OpenShift AI バージョン 2.19 以降、ModelMesh をベースとしたマルチモデルサービングプラットフォームは非推奨になりました。引き続きモデルをマルチモデルサービングプラットフォームにデプロイできますが、シングルモデルサービングプラットフォームに移行することが推奨されます。

詳細情報やシングルモデルサービングプラットフォームの使用に関するヘルプは、アカウントマネージャーにお問い合わせください。

5.1.2. Text Generation Inference Server (TGIS) が非推奨に

OpenShift AI バージョン 2.19 以降、Text Generation Inference Server (TGIS) は非推奨になりました。TGIS は、OpenShift AI 2.16 EUS ライフサイクルで引き続きサポートされます。Caikit-TGIS および Caikit は影響を受けず、引き続きサポートされます。すぐに使用できるサービングランタイムテンプレートはデプロイされなくなりました。TGIS の代替ランタイムとして vLLM が推奨されます。

5.1.3. アクセラレータープロファイルが非推奨に

アクセラレータープロファイルは非推奨になりました。ワークベンチまたはモデルサービングワークロードの特定のワーカーノードをターゲットにするには、ハードウェアプロファイルを使用します。

5.1.4. 非推奨の OpenVINO Model Server (OVMS) プラグイン

OpenVINO Model Server (OVMS) の CUDA プラグインは非推奨となり、OpenShift AI の今後のリリースでは使用できなくなります。

以前は、クラスター管理者は、OdhDashboardConfig リソースの groupsConfig オプションを使用して、OpenShift AI ダッシュボードにアクセスできる OpenShift グループ (管理者と非管理者の両方) を管理していました。OpenShift AI 2.17 以降、この機能は Auth リソースに移動されました。OdhDashboardConfig と対話するワークフロー (GitOps ワークフローなど) がある場合は、代わりに Auth リソースを参照するように更新する必要があります。

Expand
表5.1 更新された設定
リソース2.16 以前2.17 以降のバージョン

apiVersion

opendatahub.io/v1alpha

services.platform.opendatahub.io/v1alpha1

kind

OdhDashboardConfig

Auth

name

odh-dashboard-config

auth

Admin groups

spec.groupsConfig.adminGroups

spec.adminGroups

User groups

spec.groupsConfig.allowedGroups

spec.allowedGroups

5.1.6. 非推奨のクラスター設定パラメーター

CodeFlare SDK を使用して Red Hat OpenShift AI で分散ワークロードを実行する場合、Ray クラスター設定の次のパラメーターは非推奨となり、示されているように新しいパラメーターに置き換える必要があります。

Expand
非推奨パラメーター後継パラメーター

head_cpus

head_cpu_requestshead_cpu_limits

head_memory

head_memory_requestshead_memory_limits

min_cpus

worker_cpu_requests

max_cpus

worker_cpu_limits

min_memory

worker_memory_requests

max_memory

worker_memory_limits

head_gpus

head_extended_resource_requests

num_gpus

worker_extended_resource_requests

必要に応じて、新しい extended_resource_mapping および overwrite_default_resource_mapping パラメーターを使用することもできます。これらの新しいパラメーターの詳細は、CodeFlare SDK のドキュメント (外部) を参照してください。

5.2. 削除された機能

5.2.1. Embedded サブスクリプションチャネルは一部のバージョンでは使用されない

OpenShift AI 2.8 から 2.20 および 2.22 の場合、embedded サブスクリプションチャネルは使用されません。これらのバージョンの Operator の新規インストールでは、embedded チャネルを選択できません。サブスクリプションチャネルの詳細は、Red Hat OpenShift AI Operator のインストール を参照してください。

5.2.2. InstructLab のスタンドアロンスクリプトを削除

Distributed InstructLab トレーニングを実行するためのスタンドアロンスクリプトが削除されました。InstructLab トレーニングフローを実行するには、LAB-tuning テクノロジープレビュー機能を使用します。詳細は、LAB-tuning の有効化 および LAB-tuning を使用したモデルのカスタマイズ を参照してください。

重要

LAB-tuning 機能は現在、非接続環境ではサポートされていません。

5.2.3. Anaconda の削除

Anaconda は、Python および R プログラミング言語のオープンソースディストリビューションです。OpenShift AI バージョン 2.18 以降、Anaconda は OpenShift AI に含まれなくなり、Anaconda リソースは OpenShift AI でサポートまたは管理されなくなりました。

以前に OpenShift AI から Anaconda をインストールした場合は、クラスター管理者は OpenShift コマンドラインインターフェイスから次の手順を実行して、Anaconda 関連のアーティファクトを削除する必要があります。

  1. Anaconda パスワードを含むシークレットを削除します。

    oc delete secret -n redhat-ods-applications anaconda-ce-access

  2. Anaconda 検証 cronjob の ConfigMap を削除します。

    oc delete configmap -n redhat-ods-applications anaconda-ce-validation-result

  3. Anaconda イメージストリームを削除します。

    oc delete imagestream -n redhat-ods-applications s2i-minimal-notebook-anaconda

  4. イメージのダウンロードを検証した Anaconda ジョブを削除します。

    oc delete job -n redhat-ods-applications anaconda-ce-periodic-validator-job-custom-run

  5. Anaconda cronjob の実行に関連するすべての Pod を削除します。

    oc get pods n redhat-ods-applications --no-headers=true | awk '/anaconda-ce-periodic-validator-job-custom-run*/'

5.2.4. データサイエンスパイプライン v1 のサポートの削除

これまで、OpenShift AI のデータサイエンスパイプラインは KubeFlow Pipelines v1 をベースにしていました。OpenShift AI 2.9 以降、データサイエンスパイプラインは、異なるワークフローエンジンを使用する KubeFlow Pipelines v2 をベースにしています。OpenShift AI では、デフォルトで Data Science Pipelines 2.0 が有効化され、デプロイされます。

OpenShift AI 2.16 以降、Data Science Pipelines 1.0 リソースは OpenShift AI によってサポートまたは管理されなくなりました。ダッシュボードまたは KFP API サーバーから、Data Science Pipelines 1.0 に基づくパイプラインの詳細をデプロイ、表示、または編集することはできなくなりました。

OpenShift AI は、既存の Data Science Pipelines 1.0 インスタンスを 2.0 に自動的に移行しません。OpenShift AI 2.16 以降にアップグレードする場合は、既存の Data Science Pipelines 1.0 インスタンスを手動で移行する必要があります。詳細は、Data Science Pipelines 2.0 への移行 を参照してください。

重要

Data Science Pipelines 2.0 には、Argo Workflows のインストールが含まれています。Red Hat は、この Argo Workflows インストールの、お客様による直接使用をサポートしていません。Data Science Pipelines 2.0 を備えた OpenShift AI 2.16 以降をインストールまたはアップグレードするには、クラスターに Argo Workflows がインストールされていないことを確認してください。

Elyra パイプラインで実行されている Python スクリプトのログは、S3 互換ストレージに保存されなくなりました。OpenShift AI バージョン 2.11 以降では、OpenShift AI ダッシュボードのパイプラインログビューアーでこれらのログを表示できます。

注記

この変更を有効にするには、バージョン 2024.1 以降のワークベンチイメージで提供される Elyra ランタイムイメージを使用する必要があります。

古いバージョンのワークベンチイメージがある場合は、プロジェクトワークベンチの更新 の説明に従って、Version selection フィールドを互換性のあるワークベンチイメージバージョン (例: 2024.1) に更新します。

ワークベンチイメージバージョンを更新すると、パイプラインの既存のランタイムイメージの選択がすべて消去されます。ワークベンチのバージョンを更新したら、ワークベンチ IDE を開き、パイプラインのプロパティーを更新してランタイムイメージを選択します。

5.2.6. ワークベンチのバージョン 1.2 コンテナーイメージのサポートを終了

ワークベンチを作成するときは、ワークベンチで使用するコンテナーイメージを指定します。OpenShift AI 2.5 以降では、新しいワークベンチを作成するときに、バージョン 1.2 のコンテナーイメージを選択できません。バージョン 1.2 イメージですでに実行されているワークベンチは、引き続き正常に動作します。ただし、Red Hat では、最新のコンテナーイメージを使用するようにワークベンチを更新することを推奨します。

5.2.7. beta サブスクリプションチャネルの使用を終了

OpenShift AI 2.5 以降では、beta サブスクリプションチャネルを使用しなくなりました。Operator の新規インストール用の beta チャネルを選択できなくなりました。サブスクリプションチャネルの詳細は、Red Hat OpenShift AI Operator のインストール を参照してください。

5.2.8. HabanaAI ワークベンチイメージの削除

HabanaAI 1.10 ワークベンチイメージのサポートが削除されました。OpenShift AI バージョン 2.14 以降の新規インストールには、HabanaAI ワークベンチイメージは含まれません。ただし、OpenShift AI を以前のバージョンからアップグレードする場合は、HabanaAI ワークベンチイメージは使用可能なままとなるため、既存の HabanaAI ワークベンチイメージは引き続き機能します。

第6章 解決された問題

以下の注目すべき問題は Red Hat OpenShift AI 2.22.3 で解決されています。Red Hat OpenShift AI 2.22 のセキュリティー更新、バグ修正、機能拡張は、非同期エラータとしてリリースされます。すべての OpenShift AI エラータアドバイザリーは Red Hat カスタマーポータル で公開されています。

6.1. Red Hat OpenShift AI 2.22.3 におけるセキュリティー更新(2025 年 12 月)

このリリースではセキュリティー更新が提供されます。更新の完全なリストについては、Red Hat カスタマーポータル の関連するエラータアドバイザリーを参照してください。

6.2. Red Hat OpenShift AI 2.22.1 におけるセキュリティー更新(2025 以上)

このリリースではセキュリティー更新が提供されます。更新の完全なリストについては、Red Hat カスタマーポータル の関連するエラータアドバイザリーを参照してください。

6.3. Red Hat OpenShift AI 2.22 で解決された問題

RHOAIENG-26537 - OpenShift AI 2.21 をインストールした後、ユーザーがダッシュボードにアクセスできない

OpenShift AI 2.21 をインストールし、新しいクラスターに DataScienceCluster を作成した後、Auth カスタムリソースがデフォルトのグループ設定なしで作成されるため、ダッシュボードにアクセスできませんでした。この問題は解決されています。

RHOAIENG-26464 - RHOAI 2.21 でデフォルト値を使用すると、メモリー不足のため InstructLab トレーニング phase1 Pod が再起動する

train_memory_per_worker 入力パラメーターのデフォルト値 (100 GiB) を使用して InstructLab パイプラインを実行すると、Pod メモリーが不足するため phase1 のトレーニングタスクが失敗していました。この問題は解決されています。

RHOAIENG-26263 - ワークベンチまたはモデルデプロイメントのハードウェアプロファイルを変更するときにノードセレクターが消去されない

既存のワークベンチまたはモデルのデプロイメントを編集して、ハードウェアプロファイルをノードセレクターを含むものから含まないものに変更すると、以前のノード配置設定を削除できないことがありました。このリリースにより、この問題は解決されました。

RHOAIENG-26099 - 環境変数 HTTP_PROXY と HTTPS_PROXY がノートブックに追加される

以前は、ノートブックコントローラーが、新しく作成され再起動されたすべてのワークベンチに、クラスター全体の OpenShift Proxy 設定を注入していました。このリリースでは、クラスター管理者が ConfigMap を通じてプロキシー設定を有効にしない限り、プロキシー設定は注入されません。

プロキシー設定を有効にするには、次のコマンドを実行します。

$ oc create configmap notebook-controller-setting-config --from-literal=INJECT_CLUSTER_PROXY_ENV=true -n redhat-ods-applications
Copy to Clipboard Toggle word wrap
重要

config map の INJECT_CLUSTER_PROXY_ENV キーへの変更は、odh-notebook-controller Pod が再作成された後にのみ伝播されます。動作を更新するには、該当する Pod を削除するか、デプロイメントのロールアウトを実行する必要があります。

Pod を削除するには、次のコマンドを実行します。

$ oc delete pod -l app=odh-notebook-controller -A
Copy to Clipboard Toggle word wrap

デプロイメントのロールアウトを実行するには、次のコマンドを実行します。

$ oc rollout restart -n redhat-ods-applications deployment/odh-notebook-controller-manager
Copy to Clipboard Toggle word wrap

RHOAIENG-23475 - 非接続環境での IBM Power への推論リクエストがタイムアウトエラーで失敗する

以前は、IBM Power アーキテクチャーを使用して、入力トークンが 100 を超える長いプロンプトを推論サービスに送信すると、推論サービスが応答しませんでした。このリリースにより、この問題は解決されました。

RHOAIENG-20595 - http_proxy 環境変数を定義するとパイプラインタスクの実行が失敗する

パイプラインタスクで http_proxy または https_proxy 環境変数を設定しようとすると、パイプラインタスクの実行が失敗していました。このリリースにより、この問題は解決されました。

RHOAIENG-16568 - JupyterLab ワークベンチからノートブックを PDF としてダウンロードできない

以前は、Jupyter でノートブックを PDF ファイルとしてダウンロードすることができませんでした。このリリースにより、この問題は解決されました。

RHOAIENG-14271 - Jupyter ノートブックを使用した Ray クラスターで異なる Python バージョンを使用すると互換性エラーが発生する

以前は、Jupyter ノートブックで Python バージョン 3.11 を使用して Ray クラスターを作成すると、そのクラスターで Ray バージョン 2.35 と Python バージョン 3.9 の両方を含むワークベンチイメージがデフォルトで使用されていました。これにより、互換性エラーが発生していました。このリリースにより、この問題は解決されました。

RHOAIENG-7947 - KServe でのクエリー中にモデルの提供が失敗する

以前は、ModelMesh コンポーネントをインストールしてマルチモデルサービングプラットフォームを有効にしてから、KServe コンポーネントをインストールしてシングルモデルサービングプラットフォームを有効にすると、シングルモデルサービングプラットフォームにデプロイされたモデルへの推論リクエストが失敗することがありました。この問題は発生しなくなりました。

RHOAIENG-580 (以前は RHODS-9412 として記録されていた問題) - 編集権限を持つユーザーがワークベンチを作成した場合、Elyra パイプラインが実行に失敗する

プロジェクトの編集権限が付与されている場合に、プロジェクトワークベンチを作成すると、次のような動作が見られました。

  • ワークベンチの作成プロセス中に、Kubernetes ロールバインディングの作成に関連する Error creating workbench メッセージが表示されていました。
  • 上記のエラーメッセージにもかかわらず、OpenShift AI はワークベンチを作成していました。しかし、このエラーメッセージは、そのワークベンチを使用して Elyra データサイエンスパイプラインを実行できないことを意味していました。
  • ワークベンチを使用して Elyra パイプラインを実行しようとすると、初期化に失敗したことを示す Error making request メッセージが Jupyter に表示されていました。

    このリリースでは、これらの問題は解決されています。

RHOAIENG-24682 - [vLLM-Cuda] FIPS 対応クラスターにモデルをデプロイできない

以前は、FIPS 対応クラスターの NVIDIA アクセラレーターで vLLM NVIDIA GPU ServingRuntime for KServe または vLLM ServingRuntime Multi-Node for KServe ランタイムを使用してモデルをデプロイすると、デプロイメントが失敗する可能性がありました。この問題は解決されています。

RHOAIENG-23596 - IBM Power における、推論サービスに対する長いプロンプトでの推論リクエストがタイムアウトエラーで失敗する

以前は、IBM Power アーキテクチャーを使用して、入力トークンが 100 を超える長いプロンプトを推論サービスに送信すると、推論サービスが応答しませんでした。この問題は発生しなくなりました。

第7章 既知の問題

このセクションでは、Red Hat OpenShift AI 2.22.3 の既知の問題と、これらの問題を回避する既知の方法を説明します。

RHOAIENG-34218 - TrustyAI は、認証されたすべてのユーザーに任意の namespace の Pod をリストするように指示

TrustyAI コンポーネントは、クラスター上の任意の namespace の Pod を get、list、および watch するためのすべてのサービスアカウントおよびユーザーに付与します。

回避策
OpenShift AI の TrustyAI コンポーネントを "Removed" に設定します。
oc edit dsc default-dsc
    trainingoperator:
      managementState: Managed
    trustyai:
      managementState: Removed
    workbenches:
      managementState: Managed
      workbenchNamespace: rhods-notebooks
Copy to Clipboard Toggle word wrap

または、影響を受ける ClusterRole にパッチを適用します。

oc patch clusterrole trustyai-service-operator-lmeval-user-role -p '{"metadata":{"annotations": {"opendatahub.io/managed":"false"}}}'
Copy to Clipboard Toggle word wrap

次に、ロール自体から以下を削除します。

oc  edit  clusterrole trustyai-service-operator-lmeval-user-role
- apiGroups:
  - ""
  resources:
  - pods
Copy to Clipboard Toggle word wrap

RHOAIENG-29731 - OpenShift 4.19 を使用した IBM Power クラスターで推論サービスの作成が失敗する

OpenShift Container Platform バージョン 4.19 上の IBM Power クラスターで vLLM ランタイムを使用して推論サービスを作成しようとすると、Non-Uniform Memory Access (NUMA) に関連するエラーが原因で失敗します。

回避策
推論サービスを作成するときに、環境変数 VLLM_CPU_OMP_THREADS_BINDall に設定します。

RHOAIENG-29352 - Documentation および Support メニュー項目がない

OpenShift AI の上部ナビゲーションバーで、ヘルプアイコン ( Help icon ) をクリックしても、メニューに About メニュー項目しか表示されません。Documentation および Support メニュー項目がありません。

回避策
なし。

RHOAIENG-29292 - IBM Z 上で、使用状況統計ディレクトリーへのアクセスが原因で、vLLM が権限エラーをログに記録する

IBM Z アーキテクチャーで vLLM を実行すると、推論サービスは正常に起動しますが、使用状況統計レポートに関連するバックグラウンドスレッドにエラーが記録されます。これは、サービスがアクセス権限のない制限された場所 (/.config) に使用状況データを書き込もうとするために発生します。

以下のエラーがログに記録されます。

Exception in thread Thread-2 (_report_usage_worker):
Traceback (most recent call last):
 ...
PermissionError: [Error 13] Permission denied: '/.config'
Copy to Clipboard Toggle word wrap
回避策
このエラーを防止し、使用状況統計のロギングを抑制するには、推論サービスのデプロイメントで VLLM_NO_USAGE_STATS=1 環境変数を設定します。これにより、使用状況の自動レポートが無効になり、システムディレクトリーへの書き込み時に権限の問題が発生するのを回避できます。

RHOAIENG-28910 - 2.16 から 2.19 以降にアップグレードすると、Unmanaged 状態の KServe リソースが削除される

OpenShift AI 2.16 から 2.22 へのアップグレード中に、関連する KServe 関連リソースから所有者参照が完全に削除される前に、FeatureTracker カスタムリソース (CR) が削除されます。その結果、Red Hat OpenShift AI Operator によって最初に Managed 状態で作成され、その後 DataScienceCluster (DSC) カスタムリソース (CR) で Unmanaged に変更されたリソースが、意図せず削除される可能性があります。この問題により、リソースが手動で復元されるまでモデルサービング機能が停止する可能性があります。

次のリソースは、2.16 で Unmanaged に変更された場合、2.22 で削除される可能性があります。

Expand
種類namespace名前

KnativeServing

knative-serving

knative-serving

ServiceMeshMember

knative-serving

default

Gateway

istio-system

kserve-local-gateway

Gateway

knative-serving

knative-ingress-gateway

Gateway

knative-serving

knative-local-gateway

回避策

OpenShift AI 2.16 から 2.22 にすでにアップグレードしている場合は、次のいずれかの操作を実行してください。

  • 既存のバックアップがある場合は、FeatureTracker CR への所有者参照なしで削除されたリソースを手動で再作成します。
  • 既存のバックアップがない場合は、Operator を使用して、削除されたリソースを再作成できます。

    1. 再作成済みのリソースをバックアップします。
    2. DSC で、spec.components.kserve.serving.managementStateManaged に設定し、変更を保存して、Operator がリソースを再作成できるようにします。

      Operator がリソースを再作成するまで待機します。

    3. DSC で、spec.components.kserve.serving.managementStateUnmanaged に戻し、変更を保存します。
    4. 再作成された KnativeServingServiceMeshMember、および Gateway CR リソースに以前のカスタムの変更を再適用します。

まだアップグレードしていない場合は、この問題を防ぐために、アップグレードする前に次の操作を実行してください。

  1. DSC で、spec.components.kserve.serving.managementStateUnmanaged に設定します。
  2. 上記の表にリストされている影響を受ける KnativeServingServiceMeshMember、および Gateway リソースごとに、FeatureTracker の所有者参照を削除して CR を編集します。この編集により、FeatureTracker に対するリソースの依存関係が削除され、アップグレードプロセス中にリソースが削除されなくなります。

NVPE-302NVPE-303 - NIM モデルのストレージクラスがない

新しくインストールされた OpenShift AI クラスターの NVIDIA Inference Microservice (NIM) モデルサービングプラットフォームに NVIDIA NIM モデルをデプロイしようとすると、Model deployment ページの Storage class ドロップダウンメニューが表示されないか、メニューが表示されないことがあります。これは、OpenShift AI の新規インストールでは、ストレージクラスがユーザーインターフェイスにロードまたはキャッシュされないためです。その結果、デプロイメント用のストレージを設定できなくなります。

回避策
  1. OpenShift AI ダッシュボードから、SettingsStorage classes をクリックします。変更を加えないでください。
  2. ModelsModel deployments をクリックして、NIM モデルデプロイメントを表示します。
  3. Deploy model をクリックします。
  4. Model deployment ページには、Storage class ドロップダウンメニューが表示され、使用可能なストレージクラスのオプションが追加されています。

RHOAIENG-27676 - 削除されたケースではアクセラレータープロファイルが正しく動作しない

ワークベンチ、デプロイメント、またはモデルサーバーを作成した後に accelerator プロファイルを削除すると、Edit ページでは既存の設定が使用されず、間違った Accelerator プロファイルが表示されます。

回避策
なし。

RHOAIENG-25734 - ノートブックイメージの名前が重複する問題

ワークベンチ、デプロイメント、またはモデルサーバーを作成した後にワークベンチを削除し、製品スコープとグローバルスコープの両方のイメージストリームに同じ名前を使用すると、ワークベンチの表と Edit workbench フォームにワークベンチの名前が正しく表示されません。

回避策
プロジェクトスコープとグローバルスコープの Accelerator プロファイルに同じ名前を使用しないでください。

RHOAIENG-25733 - アクセラレータープロファイルは重複した名前では正しく動作しない

ワークベンチ、デプロイメント、またはモデルを作成し、プロジェクトスコープの Accelerator プロファイルにグローバルスコープの Accelerator プロファイルと同じ名前を使用すると、Edit ページとサーバーフォームのそれぞれのテーブルとフォームに誤ったラベルが表示されます。

回避策
プロジェクトスコープとグローバルスコープの Accelerator プロファイルに同じ名前を使用しないでください。

RHOAIENG-24545 - 初回の起動後にランタイムイメージがワークベンチに存在しない

ランタイムイメージのリストには、namespace で最初に実行されているワークベンチインスタンスが適切に入力されないため、Elyra パイプラインエディターで選択できるイメージが表示されません。

回避策
ワークベンチを再起動します。ワークベンチを再起動すると、ランタイムイメージのリストがワークベンチと Elyra パイプラインエディターの選択ボックスの両方に表示されます。

RHOAIENG-25090 - モデル登録オプションが無効になっていると、InstructLab の prerequisites-check-op タスクが失敗する

Add model to <model registry name> チェックボックスを選択せずに LAB-tuning 実行を開始すると、InstructLab パイプラインは開始されますが、prerequisites-check-op タスクは失敗し、Pod ログに次のエラーが記録されます。

failed: failed to resolve inputs: the resolved input parameter is null: output_model_name
Copy to Clipboard Toggle word wrap
回避策
LAB-tuning 実行を設定するときに Add model to <model registry name> チェックボックスをオンにします。

RHOAIENG-25056 - ネストされたパイプラインで使用されるオプションの入力パラメーターが設定されていない場合、データサイエンスパイプラインタスクが失敗する

パイプラインにオプションの入力パラメーターがあり、その入力パラメーターの値が指定されておらず、ネストされたパイプラインで使用されると、それらを使用するタスクは次のエラーで失敗します。

failed: failed to resolve inputs: resolving input parameter with spec component_input_parameter:"optional_input": parent DAG does not have input parameter optional_input
Copy to Clipboard Toggle word wrap
回避策
ネストされたパイプラインタスクを使用する場合は、すべてのオプションパラメーターの値を指定します。

RHOAIENG-24786 - 非接続環境で Authorino Operator をテクニカルプレビューから Stable にアップグレードすると失敗する

非接続環境では、Red Hat Authorino Operator をテクニカルプレビューから Stable にアップグレードすると authconfig-migrator-qqttz Pod でエラーが発生して失敗します。

回避策
  1. Red Hat Authorino Operator を tech-preview-v1 更新チャネルの最新バージョン (v1.1.2) に更新します。
  2. 次のスクリプトを実行します。

    #!/bin/bash
    set -xe
    
    # delete the migrator job
    oc delete job -n openshift-operators authconfig-migrator || true
    
    # run the migrator script
    authconfigs=$(oc get authconfigs -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name' --no-headers)
    
    if [[ ! -z "${authconfigs}" ]]; then
        while IFS=" " read -r namespace name; do
            oc get authconfig "$name" -n "$namespace" -o yaml > "/tmp/${name}.${namespace}.authconfig.yaml"
            oc apply -f "/tmp/${name}.${namespace}.authconfig.yaml"
        done <<< "${authconfigs}"
    fi
    
    oc patch crds authconfigs.authorino.kuadrant.io --type=merge --subresource status --patch '{"status":{"storedVersions":["v1beta2"]}}'
    Copy to Clipboard Toggle word wrap
  3. Red Hat Authorino Operator サブスクリプションを更新して、stable 更新チャネルを使用します。
  4. Authorino 1.2.1 の更新オプションを選択します。

RHOAIENG-20209 - 要求されたリソースがしきい値を超えても警告メッセージが表示されない

Distributed workloadsProject metrics をクリックし、Requested resources セクションを表示すると、チャートには要求されたリソースの値と各リソースの合計共有クォータ値 (CPU および メモリー) が表示されます。ただし、Requested by all projects の値が、そのリソースの Warning threshold の値を超えると、予想される警告メッセージは表示されません。

回避策
なし。

SRVKS-1301 (以前は RHOAIENG-18590 として文書化されていました) - KServe を無効化にしてから有効化すると、KnativeServing リソースが失敗する

DataScienceCluster で kserve コンポーネントを無効にしてから有効にすると、KnativeServing リソースが失敗する可能性があります。

回避策

Knative に関連するすべての ValidatingWebhookConfiguration および MutatingWebhookConfiguration Webhook を削除します。

  1. Webhook を取得します。

    oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
    Copy to Clipboard Toggle word wrap
  2. KServe が無効になっていることを確認します。
  3. Webhook を取得します。

    oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
    Copy to Clipboard Toggle word wrap
  4. Webhook を削除します。
  5. KServe を有効にします。
  6. KServe Pod が正常に生成され、knative-serving namespace 内の Pod がアクティブで動作していることを確認します。

RHOAIENG-16247 - OpenShift AI ダッシュボードから実行を開始すると、Elyra パイプラインの実行出力が上書きされる

Elyra からパイプラインを作成して実行すると、パイプラインの実行によって生成された出力が、オブジェクトストレージのフォルダー bucket-name/pipeline-name-timestamp に保存されます。

Elyra からパイプラインを作成し、OpenShift AI ダッシュボードからパイプラインの実行を開始すると、タイムスタンプ値が更新されません。これにより、パイプラインの実行によって、同じパイプラインの以前のパイプライン実行によって作成されたファイルが上書きされる可能性があります。

この問題は、OpenShift AI ダッシュボードを使用してコンパイルおよびインポートされたパイプラインには影響しません。これは、オブジェクトストレージで使用されるフォルダーに runid が常に追加されるためです。データサイエンスパイプラインで使用されるストレージの場所の詳細は、データサイエンスパイプラインでのデータの保存 を参照してください。

回避策
Elyra パイプラインにファイルを保存する場合は、パイプライン実行ごとに異なるサブフォルダー名を使用します。

OCPBUGS-49422 - 非接続環境内の AMD GPU および AMD ROCm ワークベンチイメージがサポートされていない

この OpenShift AI リリースでは、非接続環境内の AMD GPU および AMD ROCm ワークベンチイメージはサポートされていません。AMD GPU Operator をインストールするには、GPU ドライバーのコンパイルに必要な依存関係を取得するのにインターネットアクセスが必要であるためです。

回避策
なし。

RHOAIENG-12516 - fast リリースが意図しないリリースチャネルで利用できる

ストリームイメージ配信プロセスに関する既知の問題により、現在、fast リリースは stablestable-x.y などの意図しないストリーミングチャネルで利用可能です。正確なリリースタイプ、チャネル、サポートライフサイクル情報は、Red Hat OpenShift AI Self-Managed ライフサイクル ページの ライフサイクル日付 表を参照してください。

回避策
なし。

RHOAIENG-8294 - OpenShift AI 2.8 をバージョン 2.10 以降にアップグレードするときに CodeFlare エラーが発生する

OpenShift AI 2.8 をバージョン 2.10 以降にアップグレードしようとすると、AppWrapper カスタムリソース定義 (CRD) バージョンとの不一致により、CodeFlare コンポーネントに関する次のエラーメッセージが表示されます。

ReconcileCompletedWithComponentErrors DataScienceCluster resource reconciled with component errors: 1 error occurred: * CustomResourceDefinition.apiextensions.k8s.io "appwrappers.workload.codeflare.dev" is invalid: status.storedVersions[0]: Invalid value: "v1beta1": must appear in spec.versions
Copy to Clipboard Toggle word wrap
回避策
  1. 既存の AppWrapper CRD を削除します。

    $ oc delete crd appwrappers.workload.codeflare.dev
    Copy to Clipboard Toggle word wrap
  2. 約 20 秒待ってから、次の例に示すように、新しい AppWrapper CRD が自動的に適用されることを確認します。

    $ oc get crd appwrappers.workload.codeflare.dev
    NAME                                 CREATED AT
    appwrappers.workload.codeflare.dev   2024-11-22T18:35:04Z
    Copy to Clipboard Toggle word wrap

RHOAIENG-7716 - パイプライン条件グループのステータスが更新されない

ループ (dsl.ParallelFor) または条件グループ (dsl.lf) を含むパイプラインを実行すると、パイプラインの実行が完了した後でも、UI にループとグループの実行ステータスが表示されます。

回避策

アクティブな子タスクがないことを確認することで、パイプラインがまだ実行中かどうかを確認できます。

  1. OpenShift AI ダッシュボードから、Data Science PipelinesRuns をクリックします。
  2. Project リストから、データサイエンスプロジェクトをクリックします。
  3. Runs タブから、ステータスを確認する必要があるパイプライン実行をクリックします。
  4. 条件グループを展開し、子タスクをクリックします。

    子タスクに関する情報を含むパネルが表示されます。

  5. パネルで、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 インストールを削除するか、datasciencepipelinesRemoved に設定してから、インストールまたはアップグレードを続行します。

RHOAIENG-3913 - Red Hat OpenShift AI Operator が、エラーとともに Degraded 条件を False と誤表示する

OpenShift AI Operator が使用する DataScienceCluster (DSC) オブジェクトで KServe コンポーネントを有効にし、依存する Red Hat OpenShift Service Mesh および Red Hat OpenShift Serverless Operators をインストールしていない場合、DSC オブジェクトの kserveReady 条件は、KServe の準備ができていないことを正しく示します。しかし、Degraded 条件には False の値が誤表示されます。

回避策
Red Hat OpenShift Serverless および Red Hat OpenShift Service Mesh Operators をインストールし、DSC を再作成します。

RHOAIENG-3025 - OVMS が要求するディレクトリーレイアウトが KServe StoragePuller レイアウトと競合する

OpenVINO Model Server (OVMS) ランタイムを使用してシングルモデルサービングプラットフォーム (KServe を使用) にモデルをデプロイすると、OVMS が要求するディレクトリーレイアウトと KServe で使用されるモデル取得ロジックのレイアウトの間に不一致が生じます。具体的には、OVMS はモデルファイルを /<mnt>/models/1/ ディレクトリーに配置することを要求しますが、KServe はモデルファイルを /<mnt>/models/ ディレクトリーに配置します。

回避策

次の操作を実行します。

  1. S3 互換ストレージバケットで、モデルファイルを 1/ というディレクトリーに置きます (例: /<s3_storage_bucket>/models/1/<model_files>)。
  2. OVMS ランタイムを使用してシングルモデルサービングプラットフォームにモデルをデプロイするには、次のいずれかの方法を選択して、モデルファイルへのパスを指定します。

    • OpenShift AI ダッシュボードを使用してモデルをデプロイする場合は、データ接続の Path フィールドで、/<s3_storage_bucket>/models/ 形式を使用してモデルファイルへのパスを指定します。パスの一部として 1/ ディレクトリーを指定しないでください。
    • 独自の InferenceService カスタムリソースを作成してモデルをデプロイする場合は、storageURI フィールドの値を /<s3_storage_bucket>/models/ に設定します。パスの一部として 1/ ディレクトリーを指定しないでください。

KServe は、指定したパスのサブディレクトリーからモデルファイルを取得します。この場合、KServe は S3 互換ストレージの /<s3_storage_bucket>/models/1/ ディレクトリーからモデルファイルを正しく取得します。

RHOAIENG-3018 - KServe 上の OVMS がダッシュボードに正しいエンドポイントを公開しない

OpenVINO Model Server (OVMS) ランタイムを使用してシングルモデルサービングプラットフォームにモデルをデプロイした場合、デプロイしたモデルの Inference endpoint フィールドに表示される URL が不完全なものになります。

回避策
モデルにクエリーを送信するには、URL の末尾に /v2/models/_<model-name>_/infer 文字列を追加する必要があります。_<model-name>_ は、デプロイしたモデルの名前に置き換えてください。

RHOAIENG-2602 - ModelMesh Pod の再起動により、"平均応答時間" のサーバーメトリクスグラフに複数の行が表示される

ModelMesh Pod が再起動されると、平均応答時間 のサーバーメトリクスグラフに複数の行が表示されます。

回避策
なし。

RHOAIENG-2585 - クラスターで UWM が有効になっていない場合、UI にエラー/警告が表示されない

クラスターで User Workload Monitoring (UWM) が 無効化 されている場合、Red Hat OpenShift AI はユーザーに正しく警告しません。UWM は、モデルメトリクスが正しく機能するために必要です。

回避策
ユーザー定義プロジェクトのモニタリングの有効化 の説明に従って、クラスター内で UWM が有効になっていることを手動で確認します。

RHOAIENG-2555 - フォームでサービングランタイムを変更すると、モデルフレームワークセレクターがリセットされない

Deploy model ダイアログを使用してシングルモデルサービングプラットフォームにモデルをデプロイするときに、ランタイムとサポートされているフレームワークを選択した後で別のランタイムに切り替えても、既存のフレームワークの選択がリセットされません。そのため、選択したランタイムでサポートされていないフレームワークを使用してモデルをデプロイできます。

回避策
モデルのデプロイ時に、選択したランタイムを変更する場合は、Select a framework リストを再度クリックして、サポートされているフレームワークを選択してください。

RHOAIENG-2468 - KServe と同じプロジェクト内のサービスが OpenShift でアクセスできなくなる場合がある

シングルモデルサービングプラットフォーム (KServe を使用) にデプロイされたモデルを含むデータサイエンスプロジェクトに OpenShift AI 以外のサービスをデプロイする場合、サービスのアクセシビリティーが、OpenShift クラスターのネットワーク設定の影響を受ける可能性があります。これは、OVN-Kubernetes ネットワークプラグイン をホストのネットワーク namespace と組み合わせて使用している場合に、特に発生しやすくなります。

回避策

次のいずれかの操作を実行します。

  • シングルモデルサービングプラットフォームにデプロイされたモデルが含まれていない別のデータサイエンスプロジェクトに、サービスをデプロイします。または、別の OpenShift プロジェクトにサービスをデプロイします。
  • 次の例に示すように、サービスが存在するデータサイエンスプロジェクトで、アプリケーション Pod への Ingress トラフィックを受け入れる ネットワークポリシー を追加します。

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-ingress-to-myapp
    spec:
      podSelector:
        matchLabels:
          app: myapp
      ingress:
         - {}
    Copy to Clipboard Toggle word wrap

RHOAIENG-2228 - 間隔が 15 秒に設定されている場合、パフォーマンスメトリクスグラフが絶えず変化する

モデルメトリクス画面の Endpoint performance タブで、Refresh interval を 15 秒に、Time range を 1 時間に設定すると、グラフの結果は連続的に変化します。

回避策
なし。

RHOAIENG-2183 - エンドポイントのパフォーマンスグラフに間違ったラベルが表示される場合がある

モデルメトリクス画面の Endpoint performance タブで、グラフツールチップに誤ったラベルが表示される場合があります。

回避策
なし。

RHOAIENG-1919 - Model Serving ページが、デプロイメント直後にモデルルート URL の取得または報告に失敗する

OpenShift AI ダッシュボードからモデルをデプロイすると、システムは次の警告メッセージを表示し、モデルの Status 列には OK または緑色のチェックマークが付き、成功したことを示します。

Failed to get endpoint for this deployed model. routes.rout.openshift.io"<model_name>" not found
Copy to Clipboard Toggle word wrap
回避策
ブラウザーページを更新します。

RHOAIENG-404 - OpenShift AI のダッシュボードで、Enabled ページではなく No Components Found というページがランダムに表示される

Red Hat OpenShift AI ダッシュボードにアクセスすると、No Components Found というページが表示される場合があります。

回避策
ブラウザーのページを更新します。

RHOAIENG-234 - 安全でないクラスターの VSCode で .ipynb ファイルを表示できない

安全でないクラスター内の Google Chrome で code-server workbench イメージを使用する場合、.ipynb ファイルを表示できません。

回避策
別のブラウザーを使用してください。

RHOAIENG-1128 - ワークベンチに接続されていない永続ボリューム (PV) のサイズを増やそうとすると、不明確なエラーメッセージが表示される

ワークベンチに接続されていない永続ボリューム (PV) のサイズを増やそうとすると、不明確なエラーメッセージが表示されます。

回避策
サイズを増やす前に、PV がワークベンチに接続されていることを確認してください。

RHOAIENG-497 - DSCI を削除すると、OpenShift Service Mesh CR がユーザーへの通知なしに削除される

DSCInitialization リソースを削除すると、OpenShift Service Mesh CR も削除されます。警告メッセージは表示されません。

回避策
なし。

RHOAIENG-282 - 必要なリソースが利用できない場合、ワークロードはディスパッチすべきではない

場合によっては、単一マシンインスタンスに RayCluster を正常にプロビジョニングするために十分なリソースがない場合でも、ワークロードがディスパッチされることがあります。AppWrapper CRD は Running 状態のままであり、関連する Pod は無期限に Pending 状態になります。

回避策
追加のリソースをクラスターに追加します。

RHOAIENG-131 - InferenceService が Loaded と報告した後、gRPC エンドポイントが適切に応答しない

多数の InferenceService インスタンスが生成され、リクエストがダイレクトされると、Service Mesh Control Plane (SMCP) が応答しなくなります。InferenceService インスタンスのステータスは Loaded ですが、gRPC エンドポイントへの呼び出しはエラーとともに返されます。

回避策
ServiceMeshControlPlane カスタムリソース (CR) を編集して、Istio Egress Pod と Ingress Pod のメモリー制限を増やします。

RHOAIENG-130 - モデルが起動されたばかりの場合の同期の問題

KServe コンテナーのステータスが Ready の場合、TGIS コンテナーの準備ができていなくてもリクエストは受け入れられます。

回避策
数秒待って、すべての初期化が完了し、TGIS コンテナーが実際に準備完了であることを確認してから、リクエストの出力を確認します。

RHOAIENG-3115 - モデルが準備完了として表示された後も数秒間クエリーできない

マルチモデルサービングプラットフォームを使用してデプロイされたモデルは、ダッシュボードに Ready と表示されてもクエリーに応答しない場合があります。モデルエンドポイントにクエリーを実行すると、“Application is not available" という応答が表示されることがあります。

回避策
30 - 40 秒待ってから、ブラウザーでページを更新します。

RHOAIENG-1619 (以前は DATA-SCIENCE-PIPELINES-165 として記録されていた問題) - S3 バケットが書き込み可能でない場合の不適切なエラーメッセージ

データ接続を設定し、S3 バケットが書き込み可能でない場合にパイプラインをアップロードしようとすると、Failed to store pipelines というエラーメッセージが表示されますが、有用ではありません。

回避策
データ接続の認証情報が正しいこと、および指定したバケットへの書き込みアクセス権があることを確認してください。

RHOAIENG-1207 (以前は ODH-DASHBOARD-1758 として記録されていた問題) - OOTB カスタムサービングランタイムを数回複製するときにエラーが発生する

モデルサービングランタイムを複数回複製すると、複製が失敗し、Serving runtime name "<name>" already exists というエラーメッセージが表示されます。

回避策
metadata.name フィールドを一意の値に変更します。

RHOAIENG-1201 (以前は ODH-DASHBOARD-1908 として記録されていた問題) - 空の環境変数でワークベンチを作成できない

ワークベンチを作成するときに、Add variable をクリックしてもリストから環境変数のタイプを選択しないと、ワークベンチを作成できません。このフィールドは必須としてマークされておらず、エラーメッセージも表示されません。

回避策
なし。

RHOAIENG-432 (以前は RHODS-12928 として記録されていた問題) - サポートされていない文字を使用すると、複数のダッシュを含む Kubernetes リソース名が生成される場合がある

リソースを作成し、サポートされていない文字を名前として指定すると、各スペースがダッシュに置き換えられ、他のサポートされていない文字が削除されるため、リソース名が無効になる可能性があります。

回避策
なし。

RHOAIENG-226 (以前は RHODS-12432 として記録されていた問題) - notebook-culler ConfigMap を削除すると、ダッシュボードに Permission Denied と表示される

redhat-ods-applications namespace で notebook-controller-culler-config ConfigMap を削除すると、OpenShift AI ダッシュボードの Cluster Settings ページへの変更を保存できなくなります。保存操作は、HTTP request has failed というエラーで失敗します。

回避策

cluster-admin 権限を持つユーザーとして以下の手順を実行します。

  1. oc クライアントを使用して、クラスターにログインします。
  2. 次のコマンドを入力して、redhat-ods-applications アプリケーション namespace の OdhDashboardConfig カスタムリソースを更新します。

    $ oc patch OdhDashboardConfig odh-dashboard-config -n redhat-ods-applications --type=merge -p '{"spec": {"dashboardConfig": {"notebookController.enabled": true}}}'
    Copy to Clipboard Toggle word wrap

RHOAIENG-133 - 既存のワークベンチは、ワークベンチの再起動後に Elyra パイプラインを実行できない

Elyra JupyterLab エクステンションを使用して JupyterLab 内でデータサイエンスパイプラインを作成および実行し、ワークベンチを作成してワークベンチ内でワークベンチイメージを指定した 後に パイプラインサーバーを設定すると、ワークベンチを再起動した後でもパイプラインを実行できません。

回避策
  1. 実行中のワークベンチを停止します。
  2. ワークベンチを編集して小さな変更を加えます。たとえば、新しいダミー環境変数を追加したり、既存の不要な環境変数を削除したりします。変更を保存します。
  3. ワークベンチを再起動します。
  4. JupyterLab の左側のサイドバーで、Runtimes をクリックします。
  5. デフォルトのランタイムが選択されていることを確認します。

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
Copy to Clipboard Toggle word wrap
回避策
Red Hat ナレッジベースのソリューション記事 Pods failing with error loading seccomp filter into kernel: errno 524 in OpenShift 4 の説明に従って、net.core.bpf_jit_limit の値を増やします。

KUBEFLOW-177 - OAuth-proxy で転送されないアプリケーションのベアラートークン

アプリケーションの内部認証メカニズムがベアラートークンに基づいている場合、アプリケーションをカスタムワークベンチイメージとして使用できません。OAuth プロキシー設定によりヘッダーからベアラートークンが削除されるため、アプリケーションは適切に動作できなくなります。

回避策
なし。

RHOAIENG-1210 (以前は ODH-DASHBOARD-1699 として記録されていた問題) - すべての設定変更に対してワークベンチが自動的に再起動しない

設定の変更を加えるとワークベンチが再起動されることを示す警告メッセージが、ワークベンチの設定の編集時に表示されます。次の場合、ワークベンチは自動的に再起動しないため、この警告は誤解を招きます。

  • 名前を編集する
  • 説明を編集する
  • 既存の環境変数のキーおよび値を編集、追加、または削除する
回避策
ワークベンチを手動で再起動します。

RHOAIENG-1208 (以前は ODH-DASHBOARD-1741 として記録されていた問題) - 名前が数字で始まるワークベンチを作成できない

名前が数字で始まるワークベンチを作成しようとすると、ワークベンチは起動しません。

回避策
ワークベンチを削除し、文字で始まる名前を付けて新しいワークベンチを作成します。

KUBEFLOW-157: OpenShift AI ダッシュボードからすでにログアウトしている場合、JupyterLab からのログアウトが機能しない

JupyterLab からログアウトする前に OpenShift AI ダッシュボードからログアウトすると、JupyterLab から正常にログアウトされません。たとえば、Jupyter ノートブックの URL がわかっている場合は、これをブラウザーで再度開くことができます。

回避策
OpenShift AI ダッシュボードからログアウトする前に、JupyterLab からログアウトします。

RHODS-9789: データベース名またはユーザー名フィールドにダッシュがあるカスタムデータベースが含まれる場合はパイプラインサーバーは起動に失敗する

カスタムデータベースを使用するパイプラインサーバーを作成する場合、dbname フィールドまたは username フィールドに設定した値にダッシュが含まれていると、パイプラインサーバーは起動に失敗します。

回避策
パイプラインサーバーを編集して、対象のフィールドからダッシュを削除します。

RHODS-7718 - ダッシュボード権限のないユーザーが実行中のワークベンチを無期限に使い続けることができる

Red Hat OpenShift AI 管理者がユーザーの権限を取り消しても、引き続きユーザーは実行中のワークベンチを無期限で使用できます。

回避策
OpenShift AI 管理者がユーザーの権限を取り消す場合、管理者はそのユーザーに対して実行中のワークベンチも停止する必要があります。

RHOAIENG-1157 (以前は RHODS-6955 として記録されていた問題) - ワークベンチを編集しようとするとエラーが発生することがある

ワークベンチの編集時に、以下のようなエラーが発生する可能性があります。

Error creating workbench
Operation cannot be fulfilled on notebooks.kubeflow.org "workbench-name": the object has been modified; please apply your changes to the latest version and try again
Copy to Clipboard Toggle word wrap
回避策
なし。

RHOAIENG-1152 (以前は RHODS-6356 として記録されていた問題) - ダッシュボードにログインしたことがないユーザーの basic-workbench 作成プロセスが失敗する

ダッシュボードの基本ワークベンチの Administration ページには、OpenShift のユーザーグループと管理者グループに属するユーザーが表示されます。ただし、管理者がダッシュボードにログインしたことのないユーザーに代わって基本ワークベンチを起動しようとすると、基本ワークベンチの作成プロセスは失敗し、次のエラーメッセージが表示されます。

Request invalid against a username that does not exist.
Copy to Clipboard Toggle word wrap
回避策
該当するユーザーにダッシュボードへのログインを依頼します。

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.metadatacluster-api/accelerator ラベルを適用します。これにより、オートスケーラーは、GPU ドライバーがデプロイされるまで、これらのノードを準備ができていないと見なします。

RHOAIENG-1149 (以前に文書化された RHODS-5216) - アプリケーション起動メニューに OpenShift Cluster Manager へのリンクが誤って表示される

Red Hat OpenShift AI は、アプリケーションランチャーメニューから OpenShift Cluster Manager へのリンクを誤って表示します。このリンクをクリックすると、URL が無効なため、"Page Not Found" エラーが発生します。

回避策
なし。

RHOAIENG-1137 (以前は RHODS-5251 として記録されていた問題) - 基本ワークベンチの管理ページに権限へのアクセスを失ったユーザーが表示される

以前に基本ワークベンチを開始したユーザーがその権限を失った場合 (たとえば、OpenShift AI 管理者がユーザーのグループ設定を変更したり、許可されたグループからユーザーを削除したりした場合)、管理者は引き続き Administration ページでユーザーの基本ワークベンチを表示します。その結果、管理者は権限が取り消されたユーザーに属する基本ワークベンチを再起動できるようになります。

回避策
なし。

RHODS-4799: Tensorboard を表示するには手動の手順が必要

TensorFlow または PyTorch ワークベンチイメージを使用しており、TensorBoard を使用してデータを表示する場合に、ワークベンチ環境に環境変数を追加して、独自のコードで使用する環境変数をインポートするといった手作業の手順が必要です。

回避策

基本ワークベンチを起動するときに、次のコードを使用して TENSORBOARD_PROXY_URL 環境変数の値を設定し、OpenShift AI ユーザー ID を使用します。

import os
os.environ["TENSORBOARD_PROXY_URL"]= os.environ["NB_PREFIX"]+"/proxy/6006/"
Copy to Clipboard Toggle word wrap

RHODS-4718: Intel® oneAPI AI Analytics Toolkits のクイックスタートが、存在しないサンプルノートブックを参照している

ダッシュボードの Resources ページにある Intel® oneAPI AI アナリティクスツールキットクイックスタートでは、手順の一部としてサンプルノートブックをロードする必要がありますが、関連するリポジトリーに存在しないノートブックを参照しています。

回避策
なし。

RHOAIENG-1141 (以前は RHODS-4502 として記録されていた問題) - ダッシュボード上の NVIDIA GPU Operator タイルに不必要にボタンが表示される

NVIDIA GPU Operator がインストールされると、Jupyter で GPU が自動的に使用可能になります。したがって、Explore ページの NVIDIA GPU Operator タイルにある Enable ボタンは不要です。さらに、Enable ボタンをクリックすると、Operator がインストールされていない場合でも、NVIDIA GPU Operator タイルが Enabled ページに移動します。

回避策
なし。

RHODS-3984: ノートブックの選択時に誤ったパッケージバージョンが表示される

OpenShift AI インターフェイスで、Start a notebook server ページに、oneAPI AI Analytics Toolkit ノートブックイメージに含まれる JupyterLab パッケージおよび Notebook パッケージの誤ったバージョン番号が表示されます。このページには、このイメージが使用する Python バージョンの誤った値が表示される場合もあります。

回避策
oneAPI AI Analytics Toolkit ノートブックサーバーを起動するときに、ノートブックセルで !pip list コマンドを実行すると、ノートブックサーバーにインストールされている Python パッケージと、所有しているパッケージのバージョンを確認できます。

RHODS-2956: ノートブックインスタンスの作成時にエラーが発生する可能性がある

Jupyter でノートブックインスタンスを作成すると、Directory not found エラーが断続的に表示されます。このエラーメッセージは、Dismiss をクリックすると無視できます。

回避策
なし。

RHOAING-1147 (以前は RHODS-2881 として記録されていた問題) - ダッシュボード上のアクションが明確に表示されない

無効になったアプリケーションのライセンスを再検証し、無効になったアプリケーションのタイルを削除するダッシュボードアクションは、ユーザーには明確に表示されません。これらのアクションは、ユーザーがアプリケーションタイルの Disabled ラベルをクリックすると表示されます。その結果、意図したワークフローがユーザーにとって明確でない場合があります。

回避策
なし。

RHOAIENG-1134 (以前は RHODS-2879 として記録されていた問題) - ライセンス再検証アクションが不必要に表示される

無効になったアプリケーションのライセンスを再検証するダッシュボードアクションは、ライセンス検証またはアクティベーションシステムがないアプリケーションでは不要に表示されます。さらに、ユーザーが再検証できないライセンスを再検証しようとしても、アクションを完了できない理由を示すフィードバックが表示されません。

回避策
なし。

RHOAIENG-2305 (以前は RHODS-2650 として記録されていた問題) - Pachyderm のデプロイ中にエラーが発生することがある

Pachyderm Operator のインスタンスを作成すると、Webhook エラーが断続的に表示され、作成プロセスを正常に開始できなくなります。Webhook エラーは、Pachyderm Operator がヘルスチェックに失敗して再起動したか、Operator プロセスがコンテナーに割り当てられたメモリー制限を超えてメモリー不足 (OOM) キルをトリガーしたことを示しています。

回避策
エラーが表示されなくなるまで、Pachyderm インスタンスの作成プロセスを繰り返します。

RHODS-2096 - IBM Watson Studio は OpenShift AI で利用できない

IBM Watson Studio は、OpenShift AI が OpenShift Dedicated 4.9 以降にインストールされている場合は使用できません。これは、OpenShift Dedicated のこれらのバージョンと互換性がないためです。

回避策
OpenShift Dedicated 4.9 以降で Watson Studio を手動で設定する方法は、Marketplace サポート にお問い合わせください。

第8章 製品機能

Red Hat OpenShift AI は、データサイエンティストやクラスター管理者向けに豊富な機能を提供します。詳細は、Red Hat OpenShift AI の概要 を参照してください。

法律上の通知

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat