リリースノート

Red Hat OpenShift AI Cloud Service 1

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

概要

これらのリリースノートでは、Red Hat OpenShift AI のこのリリースの新機能、機能拡張、解決された問題、および既知の問題を概説します。OpenShift AI は現在、Red Hat OpenShift Dedicated および Red Hat OpenShift Service on Amazon Web Services (ROSA) で利用できます。

第1章 OpenShift AI の概要

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

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

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

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

OpenShift AI には 2 つのディストリビューションがあります。

  • Red Hat OpenShift Dedicated (AWS または GCP のカスタマークラウドサブスクリプション付き) または Red Hat OpenShift Service on Amazon Web Services (ROSA) 用の マネージドクラウドサービスアドオン

    Red Hat マネージド環境での OpenShift AI に関する詳細は、Red Hat OpenShift AI の製品ドキュメント を参照してください。

  • オンプレミスまたはパブリッククラウドに OpenShift Container Platform などの セルフマネージド環境でインストールできるセルフマネージドソフトウェア

    接続環境または非接続環境の OpenShift クラスターでのセルフマネージドソフトウェアとしての OpenShift AI の詳細は、Red Hat OpenShift AI Self-Managed の製品ドキュメント を参照してください。

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

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

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

2.1. 新機能

分散ワークロード

分散ワークロードにより、データサイエンティストは複数のクラスターノードを並行して使用して、より高速かつ効率的なデータ処理とモデルトレーニングを行うことができます。CodeFlare フレームワークは、タスクのオーケストレーションと監視を簡素化し、高度な GPU サポートによる自動リソーススケーリングと最適なノード利用のためのシームレスな統合を提供します。

データサイエンティスト向けに設計された CodeFlare フレームワークは、Jupyter Notebook または Python コードから直接ワークロード設定を可能にし、導入の障壁を低くし、合理化された中断のないワークフローを保証します。ワークロードを分散すると、タスクの完了時間が大幅に短縮され、より大規模なデータセットとより複雑なモデルの使用が可能になります。

シングルモデルサービングプラットフォームの認可プロバイダー
シングルモデルサービング (KServe) プラットフォームの認可プロバイダーとして Authorino を追加できるようになりました。認可プロバイダーを追加すると、プラットフォームにデプロイするモデルに対してトークン認可を有効にできます。その場合、認可されなければモデルに対して推論リクエストを実行できないようになります。

2.2. 機能拡張

Data Science Projects のユーザーインターフェイスの改善
Data Science Projects のユーザーインターフェイス (UI) が再設計され、さまざまなプロジェクトコンポーネントへのアクセスと開始が簡単になりました。新しいデザインには、更新されたレイアウト、さらに視覚を重視したインターフェイス、各プロジェクトコンポーネントの概要を示す追加の UI テキストが含まれています。
データサイエンスパイプラインにおける Kubeflow Pipelines v2 のサポート
OpenShift AI を最新の機能で継続的に更新するために、データサイエンスパイプラインは KubeFlow Pipelines (KFP) バージョン 2.0 をベースにするようになりました。OpenShift AI では、デフォルトで Data Science Pipelines (DSP) 2.0 が有効化され、デプロイされます。詳細は、Enabling Data Science Pipelines 2.0 の有効化 を参照してください。
重要

これまで、OpenShift AI のデータサイエンスパイプラインは KubeFlow Pipelines v1 をベースにしていました。OpenShift AI のダッシュボードから、DSP 1.0 をベースとするパイプラインの詳細をデプロイ、表示、または編集できなくなりました。

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

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

ワークベンチのイメージを更新
ワークベンチイメージのプリインストールパッケージが 2024.1 イメージバージョンに更新されました。最新のワークベンチイメージバージョンを使用することで、開発環境を最適化できます。ワークベンチイメージで使用される Python パッケージには、PyTorch や TensorFlow などの Python エコシステムの進歩が含まれています。code-server、RStudio、Elyra、Habana、CUDA ワークベンチイメージをサポートするオペレーティングシステムでも、ツールが更新されました。

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

重要

このセクションでは、Red Hat OpenShift AI のテクノロジープレビュー機能について説明します。テクノロジープレビュー機能は、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 のライセンス条項が適用されます。このサンプルワークベンチを使用する前に、ライセンス条項を確認してください。

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 でテクノロジープレビュー機能として利用できます。

第4章 サポートの削除

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

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

これまで、OpenShift AI のデータサイエンスパイプラインは KubeFlow Pipelines v1 をベースにしていました。データサイエンスパイプラインは現在、異なるワークフローエンジンを使用する KubeFlow Pipelines v2 をベースにしています。OpenShift AI では、デフォルトで Data Science Pipelines (DSP) 2.0 が有効化され、デプロイされます。ダッシュボードから、DSP 1.0 をベースとするパイプラインの詳細をデプロイ、表示、または編集できなくなりました。詳細は、Enabling Data Science Pipelines 2.0 の有効化 を参照してください。

重要

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

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

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

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

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

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

4.4. NVIDIA GPU Operator が NVIDIA GPU アドオンを置き換える

以前は、Graphics Processing Unit (GPU) が計算負荷の高いワークロードを支援できるようにするために、NVIDIA GPU アドオンをインストールしていました。OpenShift AI はこのアドオンをサポートしなくなりました。

GPU サポートを有効にするには、NVIDIA GPU Operator をインストールする必要があります。GPU Operator のインストール方法の詳細は、NVIDIA GPU Operator on Red Hat OpenShift Container Platform (外部) を参照してください。

4.5. Kubeflow Notebook Controller が JupyterHub を置き換える

OpenShift AI 1.15 以前では、ノートブックサーバー環境の作成と起動に JupyterHub が使用されていました。OpenShift AI 1.16 以降では、JupyterHub は含まれなくなり、その機能は Kubeflow Notebook Controller に置き換えられます。

この変更により、次の利点が得られます。

  • ユーザーは、最初のリクエストがタイムアウトするまで 5 分以上待つのではなく、すぐにリクエストをキャンセルし、変更を加えて、リクエストを再試行できるようになりました。これは、たとえば、ノートブックサーバーが正しく起動しない場合など、要求が失敗したときに、ユーザーがそれほど長く待機しないことを意味します。
  • このアーキテクチャーにより、1 人のユーザーが複数のノートブックサーバーセッションを持つことが妨げられなくなり、将来の機能の可能性が広がります。
  • PostgreSQL データベース要件が削除されたことで、OpenShift AI での将来的な拡張環境サポートが可能になります。

ただし、この更新により、次の動作の変更も作成されます。

  • IT 運用管理者の場合、現在、ノートブックサーバー管理インターフェイスでは、データサイエンティストユーザーのノートブックサーバーへのログインアクセスが許可されていません。これは、将来のリリースで追加される予定です。
  • データサイエンティストの場合、JupyterHub インターフェイスの URL は無効になりました。OpenShift AI ダッシュボードを指すようにブックマークを更新します。

JupyterLab インターフェイスは変更されておらず、データサイエンティストは引き続き JupyterLab を使用して、通常どおりノートブックファイルを操作できます。

第5章 解決した問題

Red Hat OpenShift AI では、次の重要な問題が解決されました。

RHOAIENG-6709 - 異なる環境変数が指定されると、Jupyter ノートブックの作成が失敗する場合がある

以前は、Jupyter ノートブックを起動して停止し、OpenShift AI ワークベンチで環境変数を編集すると、ノートブックの再起動に失敗していました。この問題は解決されています。

RHOAIENG-6701 - クラスター管理者権限を持たないユーザーは Ray ダッシュボードのジョブ送信エンドポイントにアクセスできない

以前は、OpenShift のクラスター管理者権限を持たない分散ワークロード機能のユーザーは、Ray ダッシュボードのジョブ送信エンドポイントにアクセスしたり使用したりできなかった可能性があります。この問題は解決されています。

RHOAIENG-6578 - 保護された推論ポイントへのトークンなしのリクエストがデフォルトで機能しない

以前は、Authorino を単一モデルサービングプラットフォームの認証プロバイダーとして追加し、デプロイしたモデルのトークン認証を有効にした場合でも、トークンを指定せずにモデルをクエリーすることが可能でした。この問題は解決されています。

RHOAIENG-6343 - OpenShift AI のインストール後に一部のコンポーネントが Removed に設定される

以前は、OpenShift AI をインストールすると、codeflarekueue、および 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.crtodh-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 frameworkPath の値が更新されませんでした。この問題は解決されています。

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 Project ページに表示されていました。その場合、ステータスが常に不明のままでした。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 - ワークベンチの再起動時にアクセラレータープロファイル容認が削除される

以前は、容認を含むアクセラレータープロファイルを使用するワークベンチを作成した場合、ワークベンチを再起動すると容認情報が削除され、再起動が完了できませんでした。新しく作成された 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>/

この問題は、スケジュールされたパイプライン実行が原因で S3 オブジェクトストアエンドポイントが Pod に正常に渡されなかったために発生しました。この問題は解決されています。

RHODS-4769: サポートされていないテイントが含まれるノード上の GPU をノートブックサーバーに割り当てできない

サポートされている nvidia.com/gpu テイント以外のテイントでマークされたノード上の 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 ...)

エラーメッセージでは問題を明確に示すことができませんでした。今回で、エラーメッセージから、無効な文字が入力されたことが分かります。

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-applicationsredhat-ods-monitoring、および rhods-notebooks namespace に存在する場合があります。

$ oc get kfdefs.kfdef.apps.kubeflow.org -A

NAMESPACE                  NAME                                   AGE
redhat-ods-applications    rhods-anaconda                         3h6m
redhat-ods-applications    rhods-dashboard                        3h6m
redhat-ods-applications    rhods-data-science-pipelines-operator  3h6m
redhat-ods-applications    rhods-model-mesh                       3h6m
redhat-ods-applications    rhods-nbc                              3h6m
redhat-ods-applications    rhods-osd-config                       3h6m
redhat-ods-monitoring      modelmesh-monitoring                   3h6m
redhat-ods-monitoring      monitoring                             3h6m
rhods-notebooks            rhods-notebooks                        3h6m
rhods-notebooks            rhods-osd-config                       3h5m

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 にアップグレードした後、デプロイメントにパイプラインサーバーとデータ接続を備えたデータサイエンスプロジェクトが含まれている場合、修正を有効にするために次の追加アクションを実行する必要があります。

  1. ブラウザーページを更新します。
  2. デプロイメントで実行中のワークベンチをすべて停止し、再起動します。

さらに、Elyra ランタイム設定に修正が含まれていることを確認するには、以下のアクションを実行します。

  1. JupyterLab の左側のサイドバーで、Runtimes ( The Runtimes icon ) をクリックします。
  2. 表示するランタイム設定の上にカーソルを置き、Edit ボタン ( Edit runtime configuration ) をクリックします。

    Data Science Pipelines runtime configuration ページが開きます。

  3. KUBERNETES_SECRETCloud Object Storage Authentication Type フィールドの値として定義されていることを確認します。
  4. 変更せずにランタイム設定を閉じます。

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 PipelinesRuns ページで選択したプロジェクトに属するパイプラインが表示されます。この問題は解決されています。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 管理者ユーザーが SettingsUser management ページにアクセスしようとすると、"Page Not Found" エラーが表示されました。
  • クラスター管理者は、OpenShift AI ダッシュボードの Settings ページへのアクセスを 失うことはありませんでした。クラスター管理者が、SettingsUser management ページにアクセスすると、削除された OpenShift AI 管理者グループが OpenShift に存在しないことを示す警告メッセージが表示されました。その後、削除された管理者グループは OdhDashboardConfig から削除され、管理者アクセスが復元されました。

この問題は解決されています。

RHODS-1968 - 削除されたユーザーはダッシュボードが更新されるまでログインしたままになる

以前は、Red Hat OpenShift AI ダッシュボードに対するユーザーの権限が取り消された場合、この変更について、ユーザーはダッシュボードページの更新後に初めて気づきました。

この問題は解決されています。ユーザーの権限が取り消されると、更新する必要なしに、OpenShift AI ダッシュボードは 30 秒以内にユーザーをロックアウトします。

RHODS-6384 - 重複したデータ接続を作成するときに、ワークベンチのデータ接続が誤って更新される

既存のデータ接続と同じ名前を含むデータ接続を作成すると、データ接続の作成は失敗していましたが、関連付けられたワークベンチが再起動し、間違ったデータ接続に接続していました。この問題は解決されています。ワークベンチが正しいデータ接続に接続するようになりました。

RHODS-6370 - ワークベンチが最新の容認の受信に失敗する

以前は、最新の 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 ダッシュボードに戻ると失敗する

FileLog Out をクリックして、ワークベンチ Jupyter ノートブックからダッシュボードに戻ろうとすると、ダッシュボードにリダイレクトされ、ログアウトページが表示されたままになります。同様に、FileHub 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) を同じワークベンチの同じマウントフォルダーにマウントすると、Notebook 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 GPUsStart 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 - 管理者ユーザーが無効な容認をノートブック Pod に追加できる可能性がある

管理者ユーザーは、エラーをトリガーすることなく、Cluster settings ページに無効な容認を追加できました。無効な容認が追加されると、ユーザーはノートブックを正常に起動できませんでした。容認キーがリアルタイムでチェックされるようになりました。無効な容認名を入力すると、有効な容認名が英数字、-_、または . で構成され、英数字で開始および終了する必要があることを示すエラーメッセージが表示されます。

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) を使用します。これらの Add-on アンインストールプロセスは、VPC を削除しようとします。以前は、両方の Add-on インストールされていると、一方のサービスが 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 エラーが表示され、サーバーにアクセスするために更新できます。

第6章 既知の問題

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

RHOAIENG-7312 - KServe でのトークン認証によるクエリー中にモデルの提供が失敗する

DataScienceCluster オブジェクトで ModelMesh コンポーネントと KServe コンポーネントの両方を有効にし、Authorino を認証プロバイダーとして追加した場合、競合状態が発生し、odh-model-controller Pod が ModelMesh には適しているが KServe と Authorino には適していない状態でロールアウトされる可能性があります。このような状況では、KServe を使用してデプロイされた実行中のモデルに対して推論リクエストを行うと、404 - Not Found エラーが表示されます。さらに、odh-model-controller デプロイメントオブジェクトのログには、Reconciler エラーメッセージが表示されます。

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

RHOAIENG-7079 - パイプラインタスクのステータスとログが OpenShift AI ダッシュボードに表示されないことがある

特に Elyra を使用してパイプラインを実行している場合は、関連する Pod がプルーニングされておらず、情報が OpenShift コンソールで引き続き利用できる場合でも、OpenShift AI ダッシュボードにパイプラインタスクのステータスとログが表示されないことがあります。

回避策
ナレッジベースソリューション Data Science Pipelines workaround for how to view pipeline run pod logs in the Red Hat OpenShift AI dashboard に記載された手順を実行してください。

RHOAIENG-6853 - Elyra パイプライン Pod で Pod 許容を設定できない

Elyra パイプライン Pod に Pod 許容値を設定すると、許容値は有効になりません。

回避策
なし。

RHOAIENG-7209 - デフォルトのパイプラインルートを設定するときにエラーが表示される

Data Science Pipelines SDK または OpenShift AI ユーザーインターフェイスを使用してデフォルトのパイプラインルートを設定すると、次のようなエラーが表示されます。

F0513 18:25:25.155794 28 main.go:49] failed to execute component: Failed to open bucket "mlpipeline": Failed to retrieve credentials for bucket mlpipeline: Failed to get Bucket credentials from secret name="" namespace="dspa1": resource name may not be empty44
回避策
なし。

RHOAIENG-6711 - ODH-model-controller が ServiceMeshMemberRoll オブジェクトの spec.memberSelectors フィールドを上書きする

ServiceMeshMemberRoll リソースの spec.memberSelectors フィールドを使用してプロジェクトまたは namespace を ServiceMeshMemberRoll リソースに追加すると、ODH-model-controller によってフィールドが上書きされます。

回避策

次の例に示すように、spec.members フィールドを使用して、ServiceMeshMemberRoll リソースに namespace を明示的に追加します。

spec:
 members:
 - <namespace 1>
 - <namespace 2>

RHOAIENG-6649 - 外部ルートが定義されていないモデルサーバー上のモデルを表示するとエラーが表示される

ダッシュボードを使用して、外部ルートが有効になっていないモデルサーバー上にモデルをデプロイすると、モデルの作成中に t.components is undefined というエラーメッセージが表示されることがあります。

回避策
なし。

RHOAIENG-6646 - アップグレード中に Model Serving ページを表示するとエラーが表示される

OpenShift AI のアップグレードにダッシュボードを使用してモデルをデプロイしようとすると、t.status is undefined というエラーメッセージが表示されることがあります。

回避策
アップグレードされた OpenShift AI Operator の準備が整うまで待機してから、ブラウザーでページを更新します。

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-6376 - パイプラインコンポーネントの pip_index_urls をポート番号とパスを含む URL に設定するとパイプライン実行の作成が失敗する

パイプラインを作成してコンポーネントの pip_index_urls 値をポート番号とパスを含む URL に設定した場合、パイプラインコードをコンパイルしてパイプライン実行を作成すると、次のエラーが発生します。

ValueError: Invalid IPv6 URL
回避策
  1. protocol://hostname のみを使用して新しい pip サーバーを作成し、その新しいサーバーでコンポーネントの pip_index_urls 値を更新します。
  2. パイプラインコードを再コンパイルします。
  3. 新しいパイプライン実行を作成します。

RHOAIENG-6317 - ダッシュボードでパイプライン実行 Pod のログを表示するとエラーが表示される

OpenShift AI ダッシュボードのログビューアーを使用してパイプライン実行 Pod のログを表示すると、pods not found エラーメッセージが表示される場合があります。

回避策

ナレッジベースソリューション Data Science Pipelines workaround for how to view pipeline run pod logs in the Red Hat OpenShift AI dashboard に記載された手順を実行してください。

注記

この問題は OpenShift AI 2.9.1 で部分的に修正されています。残りの作業の詳細は、RHOAIENG-7079 を参照してください。

RHOAIENG-5314 - ネットワークポリシーが原因で、新しいクラスターでデータサイエンスパイプラインサーバーのデプロイに失敗する

新規クラスター上でデータサイエンスパイプラインサーバーを作成すると、ユーザーインターフェイスの状態がロード中のままになり、パイプラインサーバーが起動しません。エラーメッセージ Pipeline server failed が表示される場合があります。

回避策
  1. OpenShift Web コンソールにクラスター管理者としてログインします。
  2. Networking > NetworkPolicies をクリックします。
  3. Project リストをクリックして、プロジェクトを選択します。
  4. Create NetworkPolicy ボタンをクリックします。
  5. Configure viaYAML view を選択し、次のようにネットワークポリシーを定義します。

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-from-redhat-ods-app-to-mariadb
    spec:
      podSelector:
        matchLabels:
          app: mariadb-pipelines-definition
      ingress:
        - ports:
            - protocol: TCP
              port: 3306
          from:
            - podSelector:
                matchLabels:
                  app.kubernetes.io/name: data-science-pipelines-operator
              namespaceSelector:
                matchLabels:
                  kubernetes.io/metadata.name: redhat-ods-applications
      policyTypes:
        - Ingress
  6. Create をクリックします。

RHOAIENG-4812 - 分散ワークロードメトリクスから GPU メトリクスが除外される

この OpenShift AI リリースでは、分散ワークロードメトリクスから GPU メトリクスが除外されます。

回避策
なし。

RHOAIENG-4570 - 既存の Argo Workflows インストールがインストールまたはアップグレードと競合する

Data Science Pipelines (DSP) 2.0 には、Argo Workflows のインストールが含まれています。OpenShift AI は、この Argo Workflows インストールの顧客による直接使用をサポートしていません。DSP 2.0 を使用して OpenShift AI をインストールまたはアップグレードするには、クラスターに Argo Workflows がインストールされていないことを確認してください。詳細は、Enabling 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-4252 - データサイエンスパイプラインサーバーの削除プロセスで ScheduledWorkFlow リソースの削除に失敗する

パイプラインサーバーの削除プロセスで、ScheduledWorkFlow リソースが削除されません。その結果、新しい DataSciencePipelinesApplications (DSPAs) が冗長な ScheduledWorkFlow リソースを認識しません。

回避策
  1. パイプラインサーバーを削除します。詳細は、パイプラインサーバーの削除 を参照してください。
  2. OpenShift コマンドラインインターフェイス (CLI) で、クラスター管理者としてクラスターにログインし、次のコマンドを実行して冗長な ScheduledWorkFlow リソースを削除します。

    $ oc -n <data science project name> delete scheduledworkflows --all

RHOAIENG-4240 - 保護されていない環境でジョブを Ray クラスターに送信できない

保護されていない OpenShift クラスター内のノートブックから分散データサイエンスワークロードを実行すると、ConnectionError: Failed to connect to Ray というエラーメッセージが表示されることがあります。

回避策
ノートブックの ClusterConfiguration セクションで、openshift_oauth オプションを True に設定します。

RHOAIENG-3981 - 保護されていない環境で、Ray クラスターの準備が完了するまで待機する機能が停止する

保護されていない OpenShift クラスター内のノートブックから分散データサイエンスワークロードを実行すると、Ray クラスターの準備が完了するまで待機する機能 (cluster.wait_ready()) が、Ray クラスターの準備が完了していても停止します。

回避策

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

  • ノートブックの ClusterConfiguration セクションで、openshift_oauth オプションを True に設定します。
  • cluster.wait_ready() 機能を使用する代わりに、Ray クラスターのルート URL を開くことで、Ray クラスターの可用性を手動で確認できます。この URL で Ray ダッシュボードが利用可能であれば、クラスターの準備が完了しています。

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-3378 - 内部イメージレジストリーが、Jupyter ノートブック生成プロセスの未宣言の強い依存関係である

OpenShift AI ノートブックおよびワークベンチを起動するには、その前に OpenShift の内部の統合コンテナーイメージレジストリーを有効にする必要があります。イメージレジストリーを有効にせずにノートブックまたはワークベンチを起動しようとすると、"InvalidImageName" エラーが発生して失敗します。

次のコマンドを使用して、クラスターに対してイメージレジストリーが有効になっているかどうかを確認できます。

$ oc get pods -n openshift-image-registry
回避策
OpenShift の内部の統合コンテナーイメージレジストリーを有効にします。イメージレジストリーのセットアップおよび設定方法の詳細は、OpenShift の Image Registry Operator を参照してください。

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-2312 - code-server ワークベンチで numpy のインポートが失敗する

code-server ワークベンチに numpy をインポートすると失敗します。

回避策
  1. code-server ワークベンチの Activity bar から、メニューアイコン ( The Menu icon ) > View > Command Palette を選択し、Command Palette を開きます。

    Firefox では、F1 キーボードショートカットを使用してコマンドパレットを開くことができます。

  2. python: s と入力します。
  3. ドロップダウンリストから、Python: Select interpreter アクションを選択します。
  4. Select Interpreter ダイアログで、Enter interpreter path… を選択します。
  5. インタープリターのパスとして /opt/app-root/bin/python3 と入力し、Enter を押します。
  6. ドロップダウンリストから、新しい Python インタープリターを選択します。
  7. 新しいインタープリター (app-root) が ステータスバー に表示されることを確認します。選択したインタープリターは、ワークベンチを停止して再起動しても保持されるため、回避策はワークベンチごとに 1 回だけ実行する必要があります。

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-1452 - Red Hat OpenShift AI アドオンがスタックする

Red Hat OpenShift AI アドオンのアンインストールは、OCM API 経由でトリガーされた後、OpenShift AI コンポーネントを削除しません。

回避策

以下のように、残りの OpenShift AI リソースを手動で削除します。

  1. DataScienceCluster CR を削除します。
  2. すべての Pod が redhat-ods-applications namespace から削除されるまで待ちます。
  3. Serverless が DataScienceCluster CR で Managed に設定されている場合、すべての Pod が knative-serving namespace から削除されるまで待機します。
  4. DSCInitialization CR を削除します。
  5. DSCInitialization CR で Service Mesh が Managed に設定されている場合は、すべての Pod が istio-system namespace から削除されるまで待ちます。
  6. Red Hat OpenShift AI Operator をアンインストールします。
  7. すべての Pod が redhat-ods-operator namespace および redhat-ods-monitoring namespace から削除されるまで待ちます。

RHOAIENG-880 - デフォルトのパイプラインサービスアカウントが Ray クラスターを作成できない

デフォルトのパイプラインサービスアカウントを使用して Ray クラスターを作成することはできません。

回避策

CodeFlare SDK を使用して認証するには、次の行をパイプラインコードに追加します。

from codeflare_sdk.cluster.auth import TokenAuthentication
   auth = TokenAuthentication(
       token=openshift_token, server=openshift_server
   )
   auth_return = auth.login()
注記

クラスターが自己署名証明書を使用する場合は、TokenAuthentication パラメーターリストに ca-cert-path=<path> を含めます。

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

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

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

RHOAIENG-2541 - クラスター内のシークレットが多すぎるため、KServe コントローラー Pod で OOM が発生する

OpenShift クラスターにシークレットが多数ある場合、out-of-memory (OOM) エラーが原因で KServe コントローラー Pod が継続的にクラッシュする可能性があります。

回避策
KServe コントローラー Pod が安定するまで、OpenShift クラスター内のシークレット数を減らします。

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-307 - DataScienceCluster を削除すると、すべての OpenShift Serverless CR が削除される

DataScienceCluster カスタムリソース (CR) を削除すると、すべての OpenShift Serverless CR (knative-serving、デプロイメント、ゲートウェイ、Pod を含む) も削除されます。警告メッセージは表示されません。

回避策
なし。

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-1204 (以前は ODH-DASHBOARD-1771 として記録されていた問題) - パイプラインステップの初期化中の JavaScript エラー

実行が開始されると Run details ページが機能しなくなることがあります。

回避策
ページを更新します。

RHOAIENG-1203 (以前は ODH-DASHBOARD-1781 として記録されていた問題) - 開始済み実行ステータスのツールチップが表示されない

データサイエンスパイプラインの実行では、表示されるステータスアイコンのツールチップテキストが表示されないことがあります。

回避策
詳細は、Pipeline の Run details ページを表示し、実行出力を確認します。

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

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

回避策
なし。

RHOAIENG-1196 (以前は ODH-DASHBOARD-2140 として記録されていた問題) - ダッシュボードに表示されるパッケージバージョンがインストールされたバージョンと一致しない

ダッシュボードには、JupyterLab や Notebook などのパッケージの不正確なバージョン番号が表示される場合があります。パッケージが手動で更新された場合、イメージ内のパッケージのバージョン番号が異なる場合があります。

回避策

パッケージの実際のバージョン番号を確認するには、次の例に示すように、pip list コマンドを実行してパッケージ名を検索します。

$ pip list | grep jupyterlab
jupyterlab                        3.5.3
$ pip list | grep notebook
notebook                          6.5.3

RHOAIENG-582 (以前は ODH-DASHBOARD-1335 として記録されていた問題) - Edit 権限の名前を Contributor に変更する

Edit という用語は正確ではありません。

  • ほとんど のリソースで、Edit 権限を持つユーザーは、リソースを編集できるだけでなく、リソースを作成および削除することもできます。
  • Edit 権限を持つユーザーは、プロジェクトを編集できません。

Contributor という用語は、この権限によって付与されるアクションをより正確に表します。

回避策
なし。

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-52 - 自己署名証明書を使用したクラスターでトークン認証が失敗する

自己署名証明書を使用し、ノートブックまたは Python スクリプトでパイプラインの一部として Python codeflare-sdk を使用すると、トークン認証は失敗します。

回避策
なし。

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 プロキシー設定によりヘッダーからベアラートークンが削除されるため、アプリケーションは適切に動作できなくなります。

回避策
なし。

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

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

回避策
なし。

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

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

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

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

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

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

RHOAIENG-1205 (以前は RHODS-11791 として記録されていた問題) - アップグレード後に使用状況データの収集が有効になる

以前に Allow collection of usage data オプションの選択を解除していた (つまり、無効にしていた) 場合、OpenShift AI をアップグレードすると、このオプションが選択されます (つまり、有効になります)。

回避策

Allow collection of usage data オプションを手動でリセットします。これを行うには、次のアクションを実行します。

  1. OpenShift AI ダッシュボードの左側のメニューで、SettingsCluster settings をクリックします。

    Cluster Settings ページが開きます。

  2. Usage data collection セクションで、Allow collection of usage data の選択を解除します。
  3. Save Changes をクリックします。

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-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 Profressional Edition ライセンスの検証を担当する Cron ジョブが一時停止し、毎日は実行されない

Anaconda Professional Edition ライセンスの検証を担当する CronJob は、OpenShift AI Operator により自動的に一時停止します。その結果、Cron ジョブはスケジュールどおりに毎日実行されません。さらに、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 サポート にお問い合わせください。

RHODS-1888 - アンインストール後も OpenShift AI ハイパーリンクが表示される

OpenShift AI アドオンが OpenShift Dedicated クラスターからアンインストールされても、OpenShift AI インターフェイスへのリンクはアプリケーション起動メニューに表示されたままになります。OpenShift AI は利用できなくなっているため、このリンクをクリックすると "Page Not Found" エラーが発生します。

回避策
なし。

第7章 製品機能

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.