リリースノート


Red Hat OpenShift AI Self-Managed 2.13

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

概要

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

第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 Cloud Service の詳細は、Red Hat OpenShift AI の製品ドキュメント を参照してください。

OpenShift AI がサポートするソフトウェアプラットフォーム、コンポーネント、および依存関係の詳細は、サポートされる構成 を参照してください。

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

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

重要

このバージョンの OpenShift AI は、データサイエンスパイプラインバージョン 2.0 の使用をサポートしています。OpenShift AI 2.8 を使用しており、データサイエンスパイプラインバージョン 1.0 を引き続き使用したい場合、Red Hat では OpenShift AI 2.8 を使い続けることを推奨します。詳細は、サポートの削除 を参照してください。

2.1. 新機能

Red Hat Enterprise Linux AI モデルのサポート
Red Hat Enterprise Linux AI に含まれる Granite ファミリーの大規模言語モデル (LLM) をサービングおよびデプロイできるようになりました。モデルのデプロイの詳細は、シングルモデルサービングプラットフォームを使用したモデルのデプロイ を参照してください。サポートされているモデルの詳細は、Red Hat Enterprise Linux AI ドキュメントの モデルのダウンロード を参照してください。

2.2. 機能拡張

データサイエンスパイプラインのアーティファクト API
データサイエンスパイプラインダッシュボードで S3 ストレージからのアーティファクトを視覚化できるようになりました。パイプラインによって作成されたか、外部からインポートされたかに関係なく、S3 に保存されたアーティファクトは、API 呼び出しで安全に取得し、ダウンロードしたり、ダッシュボードに直接表示したりできます。

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

重要

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

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

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 のライセンス条項が適用されます。このサンプルワークベンチを使用する前に、ライセンス条項を確認してください。

データドリフトモニタリング (TrustyAI)

データのドリフトモニタリングにより、データサイエンティストは、デプロイされたモデルの入力データディストリビューションの大幅な変更を検出できるため、モデルの予測が正確で、時間が経過しても信頼性を維持できるようになります。

TrustyAI データドリフトモニタリングのメトリクスは、最新の実際のデータを元のトレーニングデータと比較し、トレーニングデータと推論データ間の調整の定量的な測定を提供します。

データドリフトモニタリングを使用するには、Open Data Hub ドキュメントの データドリフトのモニタリング を参照してください。

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 のドキュメントで入手できます。このサンプルワークベンチを使用する前に、ライセンス条項を確認してください。

code-server ワークベンチイメージ

Red Hat OpenShift AI に、code-server ワークベンチイメージが追加されました。詳細は、GitHub の code-server を参照してください。

code-server ワークベンチイメージを使用すると、さまざまな拡張機能を使用して新しい言語、テーマ、デバッガーを追加したり、追加サービスに接続したりして、ワークベンチ環境をカスタマイズできます。構文の強調表示、自動インデント、括弧の一致により、データサイエンス作業の効率も向上します。

注記

Elyra ベースのパイプラインは、code-server ワークベンチイメージでは使用できません。

現在、code-server ワークブックイメージは Red Hat OpenShift AI 2.13 でテクノロジープレビュー機能として利用できます。この機能は OpenShift AI 2.6 で初めて導入されました。

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

重要

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

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

AMD GPU のサポート
AMD ROCm ワークベンチイメージは、AMD グラフィックスプロセッシングユニット (GPU) Operator のサポートを追加し、コンピュートを集中的に使用するアクティビティーの処理パフォーマンスを大幅に向上させます。これにより、AI ワークロードと幅広いモデルをサポートするドライバー、開発ツール、API にアクセスできるようになります。さらに、AMD ROCm ワークベンチイメージには、TensorFlow や PyTorch などの AI フレームワークをサポートする機械学習ライブラリーが含まれています。開発者プレビューリリースでは、AMD GPU を使用したサービングおよびトレーニング/チューニングのユースケースを調査するために使用できるイメージにもアクセスできます。詳細は、Using AMD GPUs with workbenches in OpenShift AI を参照してください。
KServe Modelcars

OpenShift AI の KServe コンポーネントには、開発者プレビュー機能として Modelcars が含まれています。Modelcars 機能は、モデルデータを含む Open Container Initiative (OCI) イメージを使用して、モデルの取得を効率化します。これにより、大規模なモデルの起動時間が短縮され、ディスク領域の使用量が削減され、パフォーマンスが向上します。

Modelcars 機能はデフォルトでは有効になっていません。この機能を使用するには、KServe の設定を変更する必要があります。

詳細は、KServe ドキュメントの Serving models with OCI images および Enhancing KServe Model Fetching with Modelcars 設計ドキュメントを参照してください。

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

第5章 限定提供 (LA) 機能

重要

このセクションでは、Red Hat OpenShift AI 2.13 の限定提供機能を説明します。限定提供とは、Red Hat からの特別な承認がある場合にのみ、この機能をインストールしてサポートを受けることができます。このような承認がない場合、この機能はサポートされません。これは、このセクションで説明するすべての機能に当てはまります。

シングルノード OpenShift でのモデルサービング

この機能は、シングルノード OpenShift 上の OpenShift AI モデルサービング機能のサポートを拡張するものです。

OpenShift AI の KServe コンポーネントを RawDeployment モードで使用して機械学習モデルをデプロイできるようになりました。このモードでは、KServe の依存関係である他のコンポーネントがインストールされません。

詳細は、Deploy a machine learning model by using KServe RawDeployment mode on RHOAI with single node OpenShift を参照してください。

OpenShift AI のチューニング
OpenShift AI のチューニングは、限定提供機能として利用できます。Kubeflow Training Operator と Hugging Face Supervised Fine-tuning Trainer (SFT トレーナー) により、ユーザーは分散環境でモデルを簡単にファインチューニングおよびトレーニングできます。このリリースでは、PyTorch 機械学習フレームワークに基づくモデルにこの機能を使用できます。

第6章 サポートの削除

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

6.1. 削除された機能

6.1.1. Elyra パイプラインで実行される Python スクリプトのパイプラインログは S3 に保存されない

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

注記

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

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

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

6.1.2. データサイエンスパイプライン v1 から v2 にアップグレード

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

重要

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

OpenShift AI 2.13 のダッシュボードから、Data Science Pipelines 1.0 をベースとするパイプラインの詳細をデプロイ、表示、または編集できなくなりました。すでにデータサイエンスパイプラインを使用している場合は、Data Science Pipelines 2.0 の完全な機能が OpenShift AI の stable リリースで提供され、新しいパイプラインソリューションに移行する準備ができるまで、OpenShift AI 2.8 の使用を続けることを Red Hat は推奨します。ライフサイクル (フルサポートフェーズ期間を含む) の詳細は、Red Hat OpenShift AI Self-Managed のライフサイクル を参照してください。

重要

OpenShift AI 2.13 にアップグレードした後に Data Science Pipelines 2.0 で既存のパイプラインとワークベンチを使用する場合は、2024.1 ノートブックイメージバージョンを使用するようにワークベンチを更新した後に、パイプラインを Data Science Pipelines 1.0 から 2.0 に手動で移行する必要があります詳細は、Data Science Pipelines 2.0 へのアップグレード を参照してください。

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

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

6.1.4. バイアス検出の削除 (TrustyAI)

OpenShift AI 2.7 以降、バイアス検出 (TrustyAI) 機能が削除されました。以前にこの機能を有効にしていた場合、OpenShift AI 2.7 以降にアップグレードすると、この機能が削除されます。デフォルトの TrustyAI ノートブックイメージは引き続きサポートされます。

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

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

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

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

6.2. 非推奨の機能

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

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

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

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 のドキュメント (外部) を参照してください。

第7章 解決した問題

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

7.1. Red Hat OpenShift AI 2.13 で解決された問題

アップグレード後のダッシュボードのロゴが間違っている

以前は、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 クラスター内のノートブックから分散データサイエンスワークロードを実行すると、ConnectionError: Failed to connect to Ray というエラーメッセージが表示されることがありました。この問題は解決されています。

第8章 既知の問題

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

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

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

回避策
なし

RHOAIENG-12233 - /v1/chat/completions エンドポイントを使用する場合は、chat_template パラメーターが必要

vLLM ServingRuntime for KServe ランタイムを設定し、/v1/chat/completions エンドポイントを使用してモデルをクエリーすると、モデルは次の 400 Bad Request エラーで失敗します。

As of transformers v4.44, default chat template is no longer allowed, so you must provide a chat template if the tokenizer does not define one

Transformers v4.44.2 は vLLM v0.5.5 に同梱されています。vLLM v0.5.5 以降では、/v1/chat/completions エンドポイントを使用してモデルをクエリーするときに、チャットテンプレートを提供する必要があります。

回避策

モデルに定義済みのチャットテンプレートが含まれていない場合は、例に示すように、chat-template コマンドラインパラメーターを使用して、カスタム vLLM ランタイムでチャットテンプレートを指定できます。<CHAT_TEMPLATE> をテンプレートのパスに置き換えます。

containers:
  - args:
      - --chat-template=<CHAT_TEMPLATE>

https://github.com/opendatahub-io/vllm/tree/main/examples.jinja ファイルとして、または /apps/data/template の下の vLLM イメージとして利用できるチャットテンプレートを使用できます。詳細は、チャットテンプレート を参照してください。

RHOAIENG-11895 - |- を使用してカスタム CA バンドルを設定すると、JupyterLab で GitHub リポジトリーをクローンできない

|- を使用して DSCInitialization (DSCI) オブジェクトでカスタム認証局 (CA) バンドルを設定すると、JupyterLab からのリポジトリーのクローン作成が次のエラーで失敗します。

Cloning into 'ods-ci-notebooks-main'... fatal: unable to access 'https://github.com/redhat-rhods-qe/ods-ci-notebooks-main/': error setting certificate file: /etc/pki/tls/custom-certs/ca-bundle.crt
回避策
  1. DSCI で、customCABundle: |-customCABundle: | に置き換えます。以下に例を示します。

      trustedCABundle:
        customCABundle: |
  2. 数分待ってから、ワークベンチを再作成し、リポジトリーをクローンします。

RHOAIENG-11024 - リソースエントリーが、opendatahub.io/managed アノテーションの削除後に消去される

コンポーネントデプロイメント YAML ファイルから opendatahub.io/managed アノテーションを手動で削除すると、ファイル内の resource エントリー値が消去される可能性があります。

回避策

デプロイメントからアノテーションを削除するには、次の手順に従ってデプロイメントを削除します。

コンポーネントのコントローラー Pod は、デフォルト値で自動的に再デプロイされます。

  1. OpenShift コンソールにクラスター管理者としてログインします。
  2. Administrator パースペクティブで、Workloads > Deployments をクリックします。
  3. Project ドロップダウンリストから、redhat-ods-applications を選択します。
  4. アノテーションを削除するデプロイメントの横にあるオプションメニュー Options menu をクリックします。
  5. Delete Deployment をクリックします。

RHOAIENG-10790 - パイプラインスケジュールは、OpenShift AI 2.12 以降へのアップグレード後、または手動で podToPodTLS DSPA オプションを有効化/無効化した後に失敗する

以前のバージョンから OpenShift AI 2.12 以降にアップグレードすると、アップグレード前に存在していたデータサイエンスパイプラインのスケジュールされた実行が失敗します。error reading server preface: EOF エラーがタスク Pod に表示されます。

プロジェクトの DataSciencePipelinesApplication リソースの spec.podToPodTLS フィールドの値を手動で変更すると、同じエラーが発生します。

回避策
実行に失敗したスケジュールされた実行を削除し、再作成します。または、既存のスケジュールされた実行を複製することもできます。

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
回避策
  1. 既存の AppWrapper CRD を削除します。

    $ oc delete crd appwrappers.workload.codeflare.dev
  2. AppWrapper CRD の最新バージョンをインストールします。

    $ oc apply -f https://raw.githubusercontent.com/project-codeflare/codeflare-operator/main/config/crd/crd-appwrapper.yml

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

ModelMesh コンポーネントをインストールしてマルチモデルサービングプラットフォームを有効にしてから、KServe コンポーネントをインストールしてシングルモデルサービングプラットフォームを有効にすると、シングルモデルサービングプラットフォームにデプロイされたモデルへの推論リクエストが失敗する可能性があります。このような場合、推論リクエストは 404 - Not Found エラーを返し、odh-model-controller デプロイメントオブジェクトのログに Reconciler エラーメッセージが表示されます。

回避策
OpenShift で、odh-model-controller デプロイメントオブジェクトを再起動します。

RHOAIENG-7887 - Kueue が RayCluster または PyTorchJob リソースの監視に失敗する

すべてのコンポーネントが有効な状態で DataScienceCluster CR を作成すると、Ray コンポーネントと Training Operator コンポーネントの前に Kueue コンポーネントがインストールされます。その結果、Kueue コンポーネントが RayCluster または PyTorchJob リソースを監視しなくなります。

回避策

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

  • Ray コンポーネントと Training Operator コンポーネントをインストールした後、redhat-ods-applications namespace で Kueue コントローラー Pod を再起動します。
  • または、DataScienceCluster CR を編集して kueue コンポーネントを Removed としてマークし、Kueue がアンインストールされるまで待ってから、kueue コンポーネントを再度 Managed としてマークします。

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

dsl.lf などの条件グループを持つパイプラインを実行すると、パイプラインの実行が完了した後でも、UI にグループのステータスが Running と表示されます。

回避策

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

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

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

  5. パネルで、Task 詳細タブをクリックします。

    Status フィールドに、子タスクの正しいステータスが表示されます。

RHOAIENG-6486 - TensorFlow 2024.1 ノートブックイメージで Elyra JupyterLab エクステンションを使用している場合、Pod ラベル、アノテーション、許容値を設定できない

TensorFlow 2024.1 ノートブックイメージで Elyra JupyterLab エクステンションを使用する場合、実行されたパイプラインから Pod ラベル、アノテーション、許容値は設定できません。これは、kfp および tf2onnx パッケージとの依存関係の競合が原因です。

回避策

TensorFlow 2024.1 ノートブックイメージを使用している場合は、作業が完了したら、割り当てられたワークベンチノートブックイメージを Standard Data Science 2024.1 ノートブックイメージに変更します。

Elyra JupyterLab エクステンションの Pipeline properties タブで、各パイプラインノードの Pod ラベル、アノテーション、許容値とともに、Tensorflow ランタイムイメージをパイプラインノードのデフォルトのランタイムイメージとして個別に設定します。

RHOAIENG-6435 - 分散ワークロードリソースがプロジェクトメトリクスに含まれていない

Distributed Workloads Metrics > Project metrics をクリックして Requested resources セクションを表示した場合は、許可されていない分散ワークロードのリソースが Requested by all projects 値から除外されています。

回避策
なし。

RHOAIENG-6409 - 実行が成功しても、パイプラインログに Cannot save paramete エラーが表示される

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 のインストールが含まれています。OpenShift AI は、この 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 が、エラーとともに Degrade 状態を 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-2759 - プロジェクトにセキュリティーで保護されたモデルサーバーと通常のモデルサーバーの両方が存在する場合、モデルのデプロイメントが失敗する

1 つのサーバーがトークン認証を使用し、もう 1 つのサーバーが認証を使用しないプロジェクトで 2 番目のモデルサーバーを作成すると、2 番目のモデルのデプロイメントが開始できない場合があります。

回避策
なし。

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:
         - {}

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
回避策
ブラウザーページを更新します。

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

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

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

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

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

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

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

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

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

RHOAIENG-545 - JupyterLab パイプラインエディターで汎用のデフォルトノードランタイムイメージを指定できない

JupyterLab IDE パイプラインエディターで Elyra パイプラインを編集し、PIPELINE PROPERTIES タブをクリックして、Generic Node Defaults セクションまでスクロールして Runtime Image フィールドを編集した場合、変更は保存されません。

回避策
必要なランタイムイメージをノードごとに明示的に定義します。NODE PROPERTIES タブをクリックし、Runtime Image フィールドに必要なイメージを指定します。

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}}}'

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

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

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

RHOAIENG-11 - 個別にインストールされた CodeFlare Operator のインスタンスはサポートされていない

Red Hat OpenShift AI では、CodeFlare Operator はベース製品に含まれており、別個の Operator には含まれていません。Red Hat またはコミュニティーから個別にインストールされた CodeFlare Operator のインスタンスはサポートされていません。

回避策
インストールされている CodeFlare Operators をすべて削除し、Red Hat OpenShift AI をインストールして設定します。Red Hat ナレッジベースソリューションの How to migrate from a separately installed CodeFlare Operator in your data science cluster の説明に従ってください。

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
回避策
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-5646 (以前は NOTEBOOKS-218 として文書化されていました) - Elyra パイプラインエディターから保存されたデータサイエンスパイプラインが互換性のないランタイムを参照している

OpenShift AI バージョン 1.31 以前で、Elyra パイプラインエディターに .pipeline 形式でパイプラインを保存すると、パイプラインは OpenShift AI バージョン 1.32 以降と互換性のないランタイムを参照します。

その結果、OpenShift AI をバージョン 1.32 以降にアップグレードした後、パイプラインは実行に失敗します。

回避策
OpenShift AI バージョン 1.32 以降にアップグレードした後、関連するランタイムイメージを再度選択します。

NOTEBOOKS-210 - Jupyter でノートブックを PDF ファイルとしてエクスポートできない

Jupyter でノートブックを PDF ファイルとしてエクスポートすると、エラーが発生してエクスポートプロセスが失敗します。

回避策
なし。

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 フィールドに設定した値にダッシュが含まれていると、パイプラインサーバーは起動に失敗します。

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

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

プロジェクトの編集権限を付与されたユーザーがプロジェクトワークベンチを作成すると、そのユーザーには次の動作が表示されます。

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

    回避策
    管理者権限を持つユーザー (プロジェクト所有者など) は、編集権限を持つユーザーに代わってワークベンチを作成する必要があります。その後、そのユーザーはワークベンチを使用して Elyra パイプラインを実行できるようになります。

RHOAIENG-583 (以前は RHODS-8921 および RHODS-6373 として記録されていた問題) - 累積文字数上限を超えると、パイプラインサーバーの作成やワークベンチの起動ができない

データサイエンスプロジェクト名とパイプラインサーバー名の累積文字数上限である 62 文字を超えると、パイプラインサーバーを正常に作成できません。同様に、データサイエンスプロジェクト名とワークベンチ名の累積文字数上限である 62 文字を超えると、ワークベンチが起動しません。

回避策
データサイエンスプロジェクトの名前を 30 文字を超えないように変更します。

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
回避策
なし。

RHOAIENG-1132 (以前は RHODS-6383 として記録されていた問題) - ワークベンチの作成プロセス中に必要なときに ImagePullBackOff エラーメッセージが表示されない

コンテナーレジストリーからコンテナーイメージをプルする際に、Pod で問題が発生する可能性があります。エラーが発生した場合、関連する Pod は ImagePullBackOff 状態になります。ワークベンチの作成プロセス中に ImagePullBackOff エラーが発生した場合は、適切なメッセージが表示されません。

回避策
イベントログで ImagePullBackOff エラーの詳細を確認します。これを行うには、ワークベンチの起動時にワークベンチのステータスをクリックします。

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

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

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

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

Start a notebook server ページには、Anaconda ノートブックイメージの正しくないバージョン番号が表示されます。

回避策
なし。

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 として記録されていた問題) - ノートブックサーバー管理ページに権限へのアクセスを失ったユーザーが表示される

以前に Jupyter でノートブックサーバーを起動したユーザーがその権限を失った場合 (たとえば、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/"

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

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

回避策
なし。

RHODS-4627 - Anaconda Professional Edition のライセンスを検証する CronJob が一時停止し、毎日実行されない

Anaconda Professional Edition のライセンスを検証する CronJob が、OpenShift AI Operator によって自動的に一時停止されます。その結果、CronJob がスケジュールどおりに毎日実行されなくなります。さらに、Anaconda Professional Edition のライセンスの有効期限が切れると、Anaconda Professional Edition は OpenShift AI ダッシュボードで無効と示されません。

回避策
なし。

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

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

回避策
なし。

RHOAIENG-1135 (以前は RHODS-3985 として記録されていた問題) - ISV Operator のアンインストール後、ダッシュボードに Enabled ページのコンテンツが表示されない

ISV Operator をアンインストールすると、ダッシュボードの Enabled ページにコンテンツが表示されません。代わりに、以下のエラーが表示されます。

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

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 サポート にお問い合わせください。

第9章 製品機能

Red Hat OpenShift AI は、データサイエンティストおよび IT オペレーション管理者に豊富な機能を提供します。詳細は、Red Hat OpenShift AI の概要 を参照してください。

法律上の通知

Copyright © 2024 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 logoGithubRedditYoutube

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.