第6章 解決された問題

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

OCPBUGS-44432 - ImageStream は OpenShift 非接続環境でイメージタグをインポートできない

この更新前は、OpenShift の非接続環境で ImageTagMirrorSet (ITMS) または ImageDigestMirrorSet (IDMS) を使用した場合、ImageStream リソースによってミラーがイメージをインポートできず、RHOAI ワークベンチインスタンスを作成できませんでした。この問題は、OpenShift Container Platform 4.19.13 以降で解決されました。この問題を回避するには、OpenShift インスタンスを 4.19.13 以降に更新してください。

RHOAIENG-29729 - アップグレード後の再起動ループでモデルレジストリー Operator が実行される

モデルレジストリーコンポーネントが有効になっている OpenShift AI 2.22 以前からアップグレードすると、モデルレジストリー Operator が再起動ループに入る可能性があります。これは model-registry-operator-controller-manager Pod 内のマネージャーコンテナーのメモリー制限が不十分なために発生しました。この問題は解決されています。

RHOAIENG-31248 - KServe http: TLS ハンドシェイクエラー

以前は、localmodelcache 検証 webhook 設定の OpenShift CA 自動インジェクションに必要なアノテーションが欠落しているため、TLS ハンドシェイクエラーが繰り返し発生していました。この問題は解決されています。

RHOAIENG-31376 - vLLM ランタイムを使用した推論サービスの作成が IBM Power クラスターで失敗する

以前は、IBM Power クラスターで vLLM ランタイムを使用して推論サービスを作成しようとすると、OpNamespace' '_C_utils' object has no attribute 'init_cpu_threads_env エラーが発生して失敗しました。この問題は解決されています。

RHOAIENG-31377 - IBM Power クラスターで推論サービスの作成が失敗する

以前は、IBM Power クラスターで vLLM ランタイムを使用して推論サービスを作成しようとすると、ValueError: 'aimv2' is already used by a Transformers config, pick another name エラーが発生して失敗しました。この問題は解決されています。

RHOAIENG-31498 - LlamaStack LMEval プロバイダーの推論 URL が正しくない

この更新前は、LMEval プロバイダーを使用して Llama Stack で評価を実行すると、評価ジョブはモデルサーバーのエンドポイントを誤って v1/openai/v1/completions として使用していました。正しいモデルサーバーのエンドポイントが v1/completions であったため、ジョブは失敗しました。この問題は解決されています。

RHOAIENG-31536 - Prometheus の設定が適切に調整されていない

この更新前は、監視リソースは適切に調整されず、2.23 へのアップグレードまたはインストール時に "Not Ready" とのステータスが表示されていました。この問題は、DSCInitialization リソースに新しい監視またはトレース設定が追加されていない場合でも、リソースに OpenTelemetry および Cluster Observability Operator をインストールする必要があったために発生しました。その結果、Prometheus の設定が調整されず、アラート設定が空になったり、古くなったりしました。この問題は解決されています。

RHOAIENG-4148 - 文字数制限によりスタンドアロンノートブックの起動に失敗する

以前は、ノートブックコントローラーロジックは、リソースの作成を試みる前にユーザー名の長さを事前にチェックしませんでした。ノートブックコントローラーは、ユーザー名を直接使用して OpenShift リソースを作成します。その結果、OpenShift Route と名前空間を組み合わせた名前が DNS サブドメインの 63 文字の制限を超えると、OpenShift Route の作成が spec.host: ... must be no more than 63 characters の検証エラーで失敗しました。ルートがないと、依存する OAuthClient を設定できず、ワークベンチを起動できません。

このリリースでは、ノートブックコントローラーのロジックが更新され、リソースを作成する前に名前の文字の長さを事前にチェックするようになりました。ルートの場合、ノートブック名と namespace の合計の長さが 63 文字の制限を超えてしまう場合、コントローラーは接頭辞が nb- の generateName フィールドを使用してルートを作成します。StatefulSets の場合、ノートブック名が 52 文字を超える場合、コントローラーは名前の競合を防ぐために generateName: "nb-" も使用します。

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

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

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

以前は、OpenShift AI のトップナビゲーションバーでヘルプアイコン ( ) をクリックすると、メニューには About メニューのみが表示され、Documentation と Support のメニュー項目はありませんでした。この問題は解決されています。

RHAIENG-496 - 管理者以外のユーザーとして LlamaStackDistribution を作成中にエラーが発生する

以前は、デプロイされたロール定義が現在の Llama Stack リソース (LlamaStackDistribution CRD など) に対して古くなっているか不完全であることが原因でロールベースのアクセス制御 (RBAC) が不十分となり、管理者以外のリクエストは失敗していました。この問題は解決されています。

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

ワークベンチ、デプロイメント、またはモデルサーバーを作成した後にアクセラレータープロファイルを削除すると、Edit ページでは既存の設定が使用されず、間違ったアクセラレータープロファイルが表示されていました。この問題は解決されています。

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

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

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

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

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

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

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

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

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

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

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

oc create configmap notebook-controller-setting-config --from-literal=INJECT_CLUSTER_PROXY_ENV=true -n redhat-ods-applications

$ oc create configmap notebook-controller-setting-config --from-literal=INJECT_CLUSTER_PROXY_ENV=true -n redhat-ods-applications

oc delete pod -l app=odh-notebook-controller -A

$ oc delete pod -l app=odh-notebook-controller -A

oc rollout restart -n redhat-ods-applications deployment/odh-notebook-controller-manager

$ oc rollout restart -n redhat-ods-applications deployment/odh-notebook-controller-manager

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RHOAIENG-24886 - モデル URI フィールドに接頭辞が含まれている場合、OCI モデルをデプロイできない

以前は、OCI モデルをデプロイするときに、Model URI フィールドに完全な URI を貼り付けてからカーソルを別のフィールドに移動すると、URL 接頭辞 (例: http://) は Model URI フィールドから削除されましたが、InferenceService リソースの storageUri 値には含まれていました。その結果、OCI モデルをデプロイできませんでした。この問題は解決されています。

RHOAIENG-24104 - KServe reconciler は、Authorino がインストールされている場合にのみ、特定のリソースをデプロイする必要があります。

以前は、Authorino がインストールされていない場合、Red Hat OpenShift AI は AuthorizationPolicy および EnvoyFilter リソースを KServe サーバーレスデプロイメントモードに適用していました。これにより、一部の推論要求がブロックされる可能性があります。この問題は解決されています。

RHOAIENG-23562 - FIPS クラスターにおける TrustyAIService TLS ハンドシェイクエラー

以前は、外部ルートを使用して TrustyAIService にリクエストを送信する FIPS クラスターを使用すると、ログに TLS ハンドシェイクエラーが表示され、リクエストは処理されませんでした。この問題は解決されています。

RHOAIENG-23169 - StorageInitializer がモデルを Hugging Face リポジトリーからダウンロードできない

以前は、クラスターにこのプロトコルのサポートが組み込まれていない場合、hf:// プロトコルを使用して KServe 環境で Hugging Face からモデルをデプロイしようとすると失敗しました。さらに、KServe のストレージイニシャライザー InitContainer では、デフォルトのキャッシュディレクトリー (/.cache) への書き込み権限が不足しているために、PermissionError エラーが発生する可能性がありました。この問題は解決されています。

RHOAIENG-22965 - オプションの入力パラメーターが設定されていない場合にデータサイエンスパイプラインタスクが失敗する

以前は、パイプラインにオプションの入力パラメーターがある場合、パラメーターが設定されていないパイプライン実行とタスクを作成すると、次のエラーで失敗しました。

failed: failed to resolve inputs: resolving input parameter optional_input with spec component_input_parameter:"parameter_name": parent DAG does not have input parameter

failed: failed to resolve inputs: resolving input parameter optional_input with spec component_input_parameter:"parameter_name": parent DAG does not have input parameter

この問題は InstructLab パイプラインにも影響しました。この問題は解決されています。

RHOAIENG-22439 - cuda-rstudio-rhel9 をビルドできない

以前は、RStudio Server ワークベンチイメージのビルド時に、次のエラーで cuda-rstudio-rhel9 のビルドが失敗していました。

Package supervisor-4.2.5-6.el9.noarch is already installed.
Dependencies resolved.
Nothing to do.
Complete!
.M...U...    /run/supervisor
error: build error: building at STEP "RUN yum -y module enable nginx:$NGINX_VERSION &&     INSTALL_PKGS="nss_wrapper bind-utils gettext hostname nginx nginx-mod-stream nginx-mod-http-perl fcgiwrap initscripts chkconfig supervisor" &&     yum install -y --setopt=tsflags=nodocs $INSTALL_PKGS &&     rpm -V $INSTALL_PKGS &&     nginx -v 2>&1 | grep -qe "nginx/$NGINX_VERSION\." && echo "Found VERSION $NGINX_VERSION" &&     yum -y clean all --enablerepo='*'": while running runtime: exit status 1

Package supervisor-4.2.5-6.el9.noarch is already installed.
Dependencies resolved.
Nothing to do.
Complete!
.M...U...    /run/supervisor
error: build error: building at STEP "RUN yum -y module enable nginx:$NGINX_VERSION &&     INSTALL_PKGS="nss_wrapper bind-utils gettext hostname nginx nginx-mod-stream nginx-mod-http-perl fcgiwrap initscripts chkconfig supervisor" &&     yum install -y --setopt=tsflags=nodocs $INSTALL_PKGS &&     rpm -V $INSTALL_PKGS &&     nginx -v 2>&1 | grep -qe "nginx/$NGINX_VERSION\." && echo "Found VERSION $NGINX_VERSION" &&     yum -y clean all --enablerepo='*'": while running runtime: exit status 1

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

RHOAIENG-21274 - OCI 接続タイプでモデルをデプロイすると、接続タイプが S3 または URI に戻る

以前は、一致する接続がないプロジェクトで S3 または URI 接続タイプを使用しているモデルをデプロイすると、S3 または URI ストレージの場所のモデルの場所のデータを使用して、Create new connection セクションが事前に入力されました。接続タイプを OCI に変更し、Model URI フィールドに値を入力すると、接続タイプは S3 または URI に戻ります。この問題は解決されています。

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

以前は、TensorFlow ベースのワークベンチイメージを使用すると、ユーザーは Elyra JupyterLab エクステンションを使用するときに Pod ラベル、アノテーション、および toleration を使用できませんでした。2025.1 イメージでは、TensorFlow ベースのワークベンチが Kubeflow パイプライン SDK (kfp) でアップグレードされます。アップグレードされた SDK では、Elyra エクステンションを使用してデータサイエンスパイプラインをスケジュールするときに、Pod ラベル、アノテーション、toleration を設定できます。

RHOAIENG-21197 - FIPS 対応クラスターの AMD GPU アクセラレーターで vLLM ランタイムを使用する場合、デプロイメントに失敗する

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

RHOAIENG-20245 - 一部のモデルレジストリー操作により、登録されたモデルおよびバージョンからカスタムプロパティーが削除されます。

以前は、モデルバージョンの説明、ラベル、またはプロパティーを編集すると、関連付けられたモデルからラベルとカスタムプロパティーが削除されました。モデルバージョンをデプロイするか、そのモデルソース形式を編集すると、そのバージョンおよび関連モデルからラベルとカスタムプロパティーが削除されました。この問題は解決されています。

RHOAIENG-19954 - Kueue アラートが OpenShift で監視されない

以前は、OpenShift コンソールでは Kueue アラートは監視されていませんでした。新しい ServiceMonitor リソースは BearerTokenFile フィールドの使用を拒否しました。これは、Prometheus にターゲットをスクレープするために必要なパーミッションがないことを意味します。その結果、Kueue アラートは Observe Alerting ページに表示されず、Kueue ターゲットは Observe Targets ページに表示されませんでした。この問題は解決されています。

RHOAIENG-19716 - system-authenticated ユーザーグループはダッシュボードを使用して削除できない

以前は、Red Hat OpenShift AI をインストールまたはアップグレードすると、system-authenticated ユーザーグループが Data science user groups の下の Settings > User management に表示されました。このユーザーグループを Data science user groups から削除して変更を保存すると、グループが誤って再度追加されます。この問題は解決されています。

RHOAIENG-18238 - Authorino Operator をアップグレードした後、デプロイされたモデルの推論エンドポイントが 403 エラーを返す

以前は、Authorino Operator をアップグレードした後、自動 Istio サイドカーインジェクションが再適用されていない可能性がありました。サイドカーがないと、Authorino はサービスメッシュに正しく統合されず、推論エンドポイントリクエストが HTTP 403 エラーで失敗していました。この問題は解決されています。

RHOAIENG-11371 - ExitHandler を使用した実行で誤った実行ステータスが報告される

以前は、パイプライン終了ハンドラー (dsl.ExitHandler) を使用する場合、ハンドル内のタスクが失敗しても終了タスクが成功すると、パイプライン全体の実行ステータスが Failed ではなく Succeeded と不正確に報告されました。この問題は解決されています。

RHOAIENG-16146 - モデルレジストリーからモデルをデプロイするときに接続が事前に選択されないことがある

以前は、モデルレジストリーからモデルをデプロイする場合、オブジェクトストレージ 接続 (以前は データ接続 と呼ばれていました) が事前に選択されないことがありました。この問題は解決されています。

RHOAIENG-21068 - パラメーター sdg_repo_pr が空のままの場合、InstructLab パイプライン実行を作成できない

以前は、InstructLab パイプラインのパイプライン実行を作成する場合に、パラメーター sdg_repo_pr が空のままになると、パイプライン実行は作成できず、エラーメッセージが表示されました。この問題は解決されています。

RHOAIENG-19711 - Kueue-controller-manager は 2.16.0 から 2.17.0 にアップグレードした後、古いメトリクスポートが使用される

以前は、アップグレード後に、Kueue Operator はメトリクスに新しいポート (8443) の代わりに古いポート (8080) を引き続き使用していました。その結果、OpenShift コンソールの Observe > Targets ページには、Kueue Operator のステータスが Down と表示されていました。この問題は解決されています。

RHOAIENG-19261 - カスタムリソース定義 (CRD) が不足しているため、TrustyAI のインストールが失敗する可能性がある

以前は、OpenShift AI をインストールまたはアップグレードするときに、InferenceService および ServingRuntime CRD がないために、TrustyAI のインストールが失敗する可能性がありました。その結果、Trusty AI コントローラーは CrashLoopBackOff 状態になりました。この問題は解決されています。

RHOAIENG-18933 - ワークベンチのイメージサイズが大きくなると、ワークベンチの起動が遅れることがある

以前は、2024.2 ワークベンチイメージに kubeflow-training Python SDK が存在したため、ワークベンチイメージのサイズが大きくなり、ワークベンチの起動時に遅延が生じる可能性がありました。この問題は解決されています。

RHOAIENG-18884 - NIM アカウントの有効化設定が完了しない

以前は、NVIDIA NIM モデルサービングプラットフォームを有効にしようとすると、NIM アカウントのセットアップが完了する前に odh-model-controller デプロイメントが開始されていました。その結果、NIM アカウントのセットアップが不完全で、プラットフォームが有効になりませんでした。この問題は解決されています。

RHOAIENG-18675 - アップグレード後にワークベンチコンポーネントが失敗する

以前は、OpenShift AI 1 にアップグレードすると、ワークベンチコンポーネントが正しくアップグレードされませんでした。具体的には、これに続く BuildConfigs およびリソース (例: RStudio BuildConfigs や ROCm imagestreams) は更新されず、これにより DataScienceCluster でのワークベンチコンポーネントの調整に失敗していました。この問題は解決されています。

RHOAIENG-15123 (RHOAIENG-10790 および RHOAIENG-14265) - アップグレード後にパイプラインのスケジュールが失敗する場合がある

以前は、OpenShift AI 1 にアップグレードすると、アップグレード前に存在していたデータサイエンスパイプラインのスケジュールされた実行が失敗し、タスク Pod にエラーメッセージが表示される場合がありました。この問題は解決されています。

RHOAIENG-16900 - サービングランタイム引数のスペース区切り形式により、デプロイメントが失敗することがある

以前は、モデルをデプロイするときに、スペース区切り形式を使用して追加のサービングランタイム引数を指定すると、認識されない引数 エラーが発生する可能性がありました。この問題は解決されています。

RHOAIENG-16073 - クラスターオブジェクトのジョブクライアントを取得するときに属性エラーが発生する

以前は、get_cluster メソッドを使用してクラスターを初期化するときに、client = cluster.job_client を割り当てると、AttributeError: 'Cluster' object has no attribute '_job_submission_client' エラーが発生することがありました。この問題は解決されています。

RHOAIENG-15773 - 新しいモデルレジストリーユーザーを追加できない

以前は、モデルレジストリーの権限を管理するときに、モデルレジストリーの権限の管理 で説明されているように、新しいユーザー、グループ、またはプロジェクトを追加できませんでした。HTTP request failed エラーが表示されます。この問題は解決されています。

RHOAIENG-14197 - CPU およびメモリーグラフのツールチップテキストが切り取られ、判読できない

以前は、Distributed Workloads Metrics ページの Project metrics タブにある Top resource-consuming distributed workloads セクションの CPU および Memory グラフにカーソルを合わせると、ツールチップテキストが切り取られ、判読できませんでした。この問題は解決されています。

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

以前は、コンポーネントデプロイメント YAML ファイルから opendatahub.io/managed アノテーションを手動で削除すると、ファイル内の リソース エントリー値が消去される可能性がありました。この問題は解決されています。

RHOAIENG-8102 - クラスターに複数のクラスターキューがある場合、要求されたリソースの報告が不正確になる

以前は、クラスターに複数のクラスターキューがある場合、すべてのプロジェクトによって要求されたリソースが、実際の値ではなく、誤ってゼロとして報告されていました。この問題は解決されています。

RHOAIENG-16484 - Gaudi アクセラレーターの vLLM サーバーエンジンが一定期間非アクティブになると失敗する

以前は、Gaudi ハードウェアを備えたクラスターで vLLM ServingRuntime with Gaudi accelerators support for KServe を使用する場合、vLLM サーバーで継続的な推論リクエストが処理されない非アクティブな期間が続くと、サーバーが失敗して TimeoutError メッセージが表示されることがありました。この問題は発生しなくなりました。

RHOAIENG-15033 - OpenShift AI のアップグレード後にモデルレジストリーインスタンスが再起動または更新されない

以前は、OpenShift AI をアップグレードしても、モデルレジストリーコンポーネントの既存のインスタンスが更新されませんでした。これにより、インスタンス Pod が Operator Pod によって参照されるイメージよりも古いイメージを使用していました。この問題は解決されています。

RHOAIENG-15008 - リクエスト名なしで CLI からバイアスメトリクスを作成するとエラーが発生する

以前は、requestName パラメーターが設定されていない場合、バイアスメトリクスを表示すると、ユーザーインターフェイスにエラーメッセージが表示されることがありました。バイアスメトリクスの表示にはユーザーインターフェイスを使用し、その設定は CLI 経由で行う場合は、ペイロード内で requestName パラメーターを指定する必要がありました。この問題は解決されています。

RHOAIENG-14986 - パッケージパスが正しくないため copy_demo_nbs が失敗する

以前は、SDK パッケージへのパスが正しくなかったため、CodeFlare SDK の copy_demo_nbs() 関数が失敗していました。この関数を実行すると、FileNotFound エラーが発生していました。この問題は解決されています。

RHOAIENG-14552 - OpenShift Container Platform 4.16 でワークベンチまたはノートブックの OAuth プロキシーが FIPS で失敗する

以前は、FIPS 対応クラスターで OpenShift 4.16 以降を使用すると、実行中のワークベンチへの接続が失敗していました。これは、内部コンポーネント oauth-proxy と OpenShift Ingress 間の接続が TLS ハンドシェイクエラーで失敗するために発生していました。ワークベンチを開くと、ブラウザーに "Application is not available" という画面が表示され、それ以外の診断情報が表示されませんでした。この問題は解決されています。

RHOAIENG-14095 - OpenShift AI Operator のインストール後、ダッシュボードが一時的に利用できなくなる

以前は、OpenShift AI Operator をインストールした後、OpenShift AI ダッシュボードを約 3 分間使用できませんでした。その結果、Cannot read properties of undefined というメッセージが表示されることがありました。この問題は解決されています。

RHOAIENG-13633 - モデルレジストリーの外部からモデルを最初にデプロイしないと、プロジェクトのサービングプラットフォームを設定できない

以前は、モデルレジストリーの外部からモデルを最初にデプロイしないと、プロジェクトのサービングプラットフォームを設定できませんでした。プロジェクトでシングルモデルサービングまたはマルチモデルサービングがすでに選択されていない限り、モデルレジストリーからプロジェクトにモデルをデプロイできませんでした。OpenShift AI UI からシングルモデルサービングまたはマルチモデルサービングを選択するには、先にレジストリーの外部からモデルまたはモデルサーバーをデプロイする必要がありました。この問題は解決されています。

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

以前は、JupyterLab IDE パイプラインエディターで Elyra パイプラインを編集し、PIPELINE PROPERTIES タブをクリックして、Generic Node Defaults セクションまでスクロールし、Runtime Image フィールドを編集しても、変更内容が保存されませんでした。この問題は解決されています。

RHOAIENG-14571 - マネージド IBM Cloud OpenShift AI インストールで Data Science Pipelines API Server にアクセスできない

以前は、データサイエンスパイプラインサーバーの設定時に、パイプラインサーバーとの正常なやり取りを妨げる通信エラーが発生しました。この問題は解決されています。

RHOAIENG-14195 - 非推奨の head_memory パラメーターを使用すると、Ray クラスターの作成が失敗する

以前は、Ray クラスター設定に非推奨の head_memory パラメーターを含めると、Ray クラスターの作成に失敗しました。この問題は解決されています。

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

以前は、|- を使用して DSCInitialization (DSCI) オブジェクトでカスタム認証局 (CA) バンドルを設定すると、JupyterLab からのリポジトリーのクローン作成に失敗しました。この問題は解決されています。

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

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

RHOAIENG-13327 - インポーターコンポーネント (dsl.importer) によりパイプラインの実行が妨げられる

データサイエンスパイプラインのインポーターコンポーネント (dsl.importer) 使用時にパイプラインを実行できませんでした。この問題は解決されています。

RHOAIENG-14652 - OpenShift Container Platform 4.16 以降では、kfp-client がパイプラインサーバーに接続できない

OpenShift 4.16 以降の FIPS クラスターでは、OpenShift AI ダッシュボードからデータサイエンスパイプラインにアクセスできました。しかし、TLS ハンドシェイクエラーが原因で、KFP SDK からパイプライン API サーバーへの接続は失敗しました。この問題は解決されています。

RHOAIENG-10129 - 名前が一致する Notebook と Ray クラスターにより、シークレット解決が失敗する

以前は、同じ namespace に一致する名前を持つノートブックと Ray クラスターを作成した場合、シークレットにすでに所有者が存在していたため、1 つのコントローラーがそのシークレットを解決できませんでした。この問題は解決されています。

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

以前は、すべてのコンポーネントを有効にして DataScienceCluster CR を作成すると、Ray コンポーネントと Training Operator コンポーネントの前に Kueue コンポーネントがインストールされていました。その結果、Kueue コンポーネントは RayCluster または PyTorchJob リソースを監視しませんでした。ユーザーが RayCluster または PyTorchJob リソースを作成した場合、Kueue はそれらのリソースの受付を制御しませんでした。この問題は解決されています。

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

データサイエンスプロジェクト名とパイプラインサーバー名の合計文字数制限が 62 文字を超えると、パイプラインサーバーを正常に作成できませんでした。同様に、データサイエンスプロジェクト名とワークベンチ名の合計文字数制限が 62 文字を超えると、ワークベンチの起動に失敗しました。この問題は解決されています。

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

以前は、OpenShift AI 2.11 から OpenShift AI 2.12 にアップグレードした後、ダッシュボードに Red Hat OpenShift AI ロゴではなく Open Data Hub ロゴが誤って表示されることがありました。この問題は解決されています。

RHOAIENG-11297 - パイプライン実行後の認証失敗

以前は、パイプライン実行中に、証明書認証の失敗により接続エラーが発生する可能性がありました。この証明書認証の失敗は、データサイエンスパイプラインでサポートされていない、default-dsci オブジェクトの customCABundle に複数行の文字列区切り文字を使用したことが原因で発生する可能性があります。この問題は解決されています。

RHOAIENG-11232 - 分散ワークロード: Kueue アラートが runbook リンクを提供しない

Kueue アラートの実行後に、クラスター管理者は Observe Alerting Alerts の順にクリックし、アラートの名前をクリックして Alert details ページを開くことができます。Alert details ページの Runbook セクションに、アラートをトリガーした問題を診断して解決する際に役立つ適切な runbook へのリンクを提供する必要があります。以前は、runbook リンクがありませんでした。

RHOAIENG-10665 - 投機的デコーディングを使用した granite モデル用のドラフトモデルをクエリーできない

以前は、granite-7b モデルおよび granite-7b-accelerator ドラフトモデルでは投機的デコードを使用できませんでした。これらのモデルをクエリーすると、内部エラーが発生してクエリーが失敗しました。この問題は解決されています。

RHOAIENG-9481 - アクションメニューをクリックするとパイプライン実行メニューに不具合が発生する

以前は、Experiments > Experiments and runs ページでパイプライン実行の横にあるアクションメニュー (⋮) をクリックしても、表示されるメニューが完全には表示されず、すべてのメニュー項目を表示するにはスクロールする必要がありました。この問題は解決されています。

RHOAIENG-8553 - カスタムイメージで作成したワークベンチに !Deleted フラグが表示される

以前は、OpenShift クラスターで内部イメージレジストリーを無効にし、イメージタグ (例: quay.io/my-wb-images/my-image:tag) を使用してインポートしたカスタムイメージでワークベンチを作成すると、Data science projects ページの Workbenches タブの Notebook image 列に !Deleted フラグが表示されていました。ワークベンチを停止すると、再起動できなくなっていました。この問題は解決されています。

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

以前は、パイプラインを作成し、コンポーネントの pip_index_urls 値をポート番号とパスを含む URL に設定すると、パイプラインコードをコンパイルしてパイプライン実行を作成するとエラーが発生する可能性がありました。この問題は解決されています。

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

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

RHOAIENG-9670 - リクエストの処理中に vLLM コンテナーが断続的にクラッシュする

以前は、シングルモデルサービングプラットフォームで vLLM ServingRuntime for KServe ランタイムを使用してモデルをデプロイし、tensor-parallel-size も設定した場合、使用したハードウェアプラットフォームによっては、リクエストの処理中に kserve-container コンテナーが断続的にクラッシュしていました。この問題は解決されています。

RHOAIENG-8043 - mixtral-8x7b で生成中に vLLM エラーが発生する

以前は、Mixtral-8x7b などの一部のモデルでは、FileNotFoundError:No such file or directory など、triton の問題が原因でスポラディックエラーが発生していた可能性があります。この問題は解決されています。

RHOAIENG-2974 - データサイエンスクラスターは、関連する初期化オブジェクトなしで削除できない

以前は、関連付けられた DSCInitialization (DSCI) オブジェクトが存在しない場合、DataScienceCluster (DSC) オブジェクトを削除できませんでした。この問題は解決されています。

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

以前は、Allow collection of usage data オプションは、OpenShift AI をアップグレードするたびにアクティブ化されていました。今後は、アップグレード時に Allow collection of usage data オプションを手動で選択解除する必要がなくなりました。

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

以前は、実行が開始されると、パイプラインの Run details ページが機能停止していました。この問題は解決されています。

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

プロジェクトの Permissions タブでは、この権限によって付与されるアクションをより正確に説明するために、Edit という用語が Contributor に置き換えられました。

更新の完全なリストは、エラータアドバイザリー を参照してください。

RHOAIENG-8819 - ibm-granite/granite-3b-code-instruct モデルをシングルモデルサービングプラットフォームにデプロイできない

以前は、vLLM ServingRuntime for KServe を使用して、シングルモデルサービングプラットフォームに ibm-granite/granite-3b-code-instruct モデルをデプロイしようとすると、モデルのデプロイがエラーで失敗していました。この問題は解決されています。

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

以前は、データサイエンスパイプライン SDK または OpenShift AI ユーザーインターフェイスを使用してデフォルトのパイプラインルートを設定しようとすると、エラーが表示されていました。この問題は解決されています。

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

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

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

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

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

以前は、セキュリティー保護されていない OpenShift クラスター内の Jupyter ノートブックから分散データサイエンスワークロードを実行すると、続行前に Ray クラスターの準備が完了するまで待機する機能 (cluster.wait_ready()) が、Ray クラスターの準備が完了していてもスタックしていました。この問題は解決されています。

RHOAIENG-2312 - code-server ワークベンチで numpy のインポートが失敗する

以前は、numpy をインポートしようとすると、code-server ワークベンチが失敗していました。この問題は解決されています。

RHOAIENG-1197 - Linux で Firefox を使用する場合、パイプライン実行作成ページの終了日ピッカーがデフォルトで NaN 値に設定されるため、パイプラインを作成できない

以前は、Linux 上の Firefox を使用して、スケジュールされた定期実行を含むパイプラインを作成しようとすると、End Date パラメーターを有効にすると、日付と時刻の両方に Not a number (Nan) 値が生成されました。この問題は解決されています。

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

以前は、ダッシュボードには JupterLab や Notebook などのパッケージのバージョン番号が不正確に表示されていました。この問題は解決されています。

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

以前は、デフォルトのパイプラインサービスアカウントを使用して Ray クラスターを作成できませんでした。この問題は解決されています。

RHOAIENG-52 - 自己署名証明書を使用したクラスターでトークン認証が失敗する

以前は、自己署名証明書を使用し、ノートブック内またはパイプラインの一部として Python スクリプト内で Python codeflare-sdk を使用した場合、トークン認証は失敗していました。この問題は解決されています。

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

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

RHOAIENG-7181 (以前は RHOAIENG-6343 として記録されていた問題) - OpenShift AI をインストールした後、一部のコンポーネントが Removed に設定される

以前は、OpenShift AI をインストールすると、codeflare、kueue、および ray コンポーネントの managementState フィールドは、DataScienceCluster カスタムリソースの Managed ではなく Removed に誤って設定されまていました。この問題は解決されています。

RHOAIENG-7079 (以前は RHOAIENG-6317 として記録されていた問題) - パイプラインタスクのステータスとログが OpenShift AI ダッシュボードに表示されないことがある

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

RHOAIENG-7070 (以前は RHOAIENG-6709 として記録されていた問題) - 異なる環境変数を指定すると、Jupyter ノートブックの作成が失敗する場合がある

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

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

以前は、Elyra パイプライン Pod に Pod 許容を設定しても、許容が有効になりませんでした。この問題は解決されています。

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

以前は、新しいクラスター上にデータサイエンスパイプラインサーバーを作成すると、ユーザーインターフェイスがロード中のままになり、パイプラインサーバーが起動しませんでした。この問題は解決されています。

RHOAIENG-4252 - データサイエンスパイプラインサーバーの削除プロセスで ScheduledWorkFlow リソースの削除に失敗する

以前は、パイプラインサーバーの削除プロセスで、ScheduledWorkFlow リソースが削除されませんでした。その結果、新しい DataSciencePipelinesApplications (DSPA) が、冗長な ScheduledWorkFlow リソースを認識しませんでした。この問題は解決されています。

RHOAIENG-3411 (以前は RHOAIENG-3378 として記録されていた問題) - 内部イメージレジストリーが、Jupyter ノートブック生成プロセスの未宣言の強い依存関係である

以前は、OpenShift AI ノートブックおよびワークベンチを起動する前に、OpenShift の内部の統合コンテナーイメージレジストリーを有効にしておく必要がありました。イメージレジストリーを有効にせずにノートブックまたはワークベンチを起動しようとすると、"InvalidImageName" エラーが発生して失敗しました。内部 OpenShift イメージレジストリーを有効にせずに、OpenShift AI でワークベンチを作成して使用できるようになりました。クラスターを更新して内部イメージレジストリーを有効または無効にする場合は、レジストリーの変更を反映するために既存のワークベンチを再作成する必要があります。

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

以前は、OpenShift クラスターにシークレットが多数ある場合、メモリー不足 (OOM) エラーにより KServe コントローラー Pod が継続的にクラッシュするころがありました。この問題は解決されています。

RHOAIENG-1452 - Red Hat OpenShift AI アドオンがスタックする

以前は、OCM API 経由でインストールがトリガーされた場合、Red Hat OpenShift AI アドオンのアンインストール時に OpenShift AI コンポーネントが削除されませんでした。この問題は解決されています。

RHOAIENG-307 - DataScienceCluster を削除すると、すべての OpenShift Serverless CR が削除される

以前は、DataScienceCluster カスタムリソース (CR) を削除すると、すべての OpenShift Serverless CR (knative-serving、デプロイメント、ゲートウェイ、Pod を含む) も削除されていました。この問題は解決されています。

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

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

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

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

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

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

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

以前は、OpenShift AI をインストールすると、codeflare、kueue、および ray コンポーネントの managementState フィールドは、DataScienceCluster カスタムリソースの Managed ではなく Removed に誤って設定されまていました。この問題は解決されています。

RHOAIENG-5067 - ModelMesh コンポーネントをベースとするモデルサーバーのモデルサーバーメトリクスページがロードされない

以前は、データサイエンスプロジェクト名に大文字またはスペースが含まれていると、ModelMesh コンポーネントをベースとするモデルサーバーのモデルサーバーメトリクスページで問題が発生することがありました。メトリクスページがデータを正常に受信しなかったために 400 Bad Request エラーが発生し、ページがロードされない場合がありました。この問題は解決されています。

RHOAIENG-4966 - カスタム CA バンドル内の自己署名証明書が odh-trusted-ca-bundle 設定マップから欠落している可能性がある

以前は、自己署名証明書を使用するためにカスタム認証局 (CA) バンドルを追加すると、カスタム証明書が odh-trusted-ca-bundle ConfigMap にないことや、ConfigMap が managed に設定されている場合に予約されていない namespace に odh-trusted-ca-bundle ConfigMap が含まれていないことがありました。この問題は解決されています。

RHOAIENG-4938 (以前は RHOAIENG-4327) - ワークベンチが一元的に設定されたバンドルからの自己署名証明書を自動的に使用しない

OpenShift AI に自己署名証明書を追加するためのバンドルの選択肢には、ca-bundle.crt と odh-ca-bundle.crt の 2 つがあります。以前は、ワークベンチは一元的に設定されたバンドルからの自己署名証明書を自動的に使用しなかったため、証明書パスを指す環境変数を定義する必要がありました。この問題は解決されています。

RHOAIENG-4572 - 特定の状況でインストールおよびアップグレードするとデータサイエンスパイプラインを実行できない

以前は、次の状況で OpenShift AI をインストールまたはアップグレードすると、データサイエンスパイプラインを実行できませんでした。

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

RHOAIENG-4524 - RStudio イメージの BuildConfig 定義に間違ったブランチが含まれている

以前は、RStudio および CUDA - RStudio ワークベンチイメージの BuildConfig 定義は、OpenShift AI の間違ったブランチを指していました。この問題は解決されています。

RHOAIENG-3963 - 管理対象リソースに関する不必要な警告

以前は、redhat-ods-applications プロジェクトの OdhDashboardConfig カスタムリソースを編集して保存すると、システムにより Managed resource 警告メッセージが誤表示されました。この問題は解決されています。

RHOAIENG-2542 - 推論サービス Pod が Istio サイドカーを取得しないことがある

以前は、シングルモデルサービングプラットフォーム (KServe を使用) を使用してモデルをデプロイすると、推論サービスに sidecar.istio.io/inject=true アノテーションがあっても、作成される Pod に istio-proxy コンテナーが欠落していることがありました。この問題は解決されています。

RHOAIENG-1666 - Import Pipeline ボタンが早期にアクセス可能になる

以前は、データサイエンスプロジェクトに属するワークベンチにパイプラインをインポートすると、パイプラインサーバーが完全に使用可能になる前に Import Pipeline ボタンがアクセス可能になりました。この問題は解決されています。

RHOAIENG-673 (以前は RHODS-12946 として記録されていた問題) - 非接続環境またはプライベート証明書を使用している場合、PyPI ミラーからインストールできない

非接続環境では、Red Hat OpenShift AI は公開されている PyPI リポジトリーに接続できないため、ネットワーク内にリポジトリーを指定する必要があります。以前は、プライベート TLS 証明書を使用していて、データサイエンスパイプラインが Python パッケージをインストールするように設定されている場合、パイプラインの実行は失敗していました。この問題は解決されています。

RHOAIENG-3355 - KServe 上の OVMS がアクセラレーターを正しく使用しない

以前は、シングルモデルサービングプラットフォームを使用してモデルをデプロイし、OpenVINO Model Server サービスランタイムを選択した場合、アクセラレーターをモデルサーバーに割り当てるように要求すると、アクセラレーターハードウェアが検出されるものの、そのハードウェアがクエリーへの応答時にモデルによって使用されませんでした。この問題は解決されています。

RHOAIENG-2869 - マルチモデルプロジェクトで既存のモデルフレームワークとモデルパスを編集できない

以前は、Deploy model ダイアログを使用してマルチモデルプロジェクト内のモデルを編集しようとすると、Model framework と Path の値が更新されませんでした。この問題は解決されています。

RHOAIENG-2724 - ダイアログ内のフィールドが自動的にリセットされるため、モデルのデプロイメントが失敗する

以前は、モデルをデプロイするか、デプロイされたモデルを編集すると、"Deploy model" ダイアログの Model servers および Model framework フィールドがデフォルトの状態にリセットされる場合がありました。これらの必須フィールドに有効な値が含まれていなくても、Deploy ボタンが有効なままになっている場合がありました。この問題は解決されています。

RHOAIENG-2099 - 新規クラスターでデータサイエンスパイプラインサーバーのデプロイに失敗する

以前は、新しいクラスター上にデータサイエンスパイプラインサーバーを作成すると、ユーザーインターフェイスがロード中のままになり、パイプラインサーバーが起動しませんでした。この問題は解決されています。

RHOAIENG-1199 (以前は ODH-DASHBOARD-1928 として記録されていた問題) - カスタムサービスランタイム作成のエラーメッセージが有用でない

以前は、カスタムのモデルサービングランタイムを作成または編集しようとしてエラーが発生した場合、エラーメッセージにエラーの原因が示されませんでした。このエラーメッセージは改善されました。

RHOAIENG-556 - KServe モデルの ServingRuntime がエラーにもかかわらず作成される

以前は、KServe モデルをデプロイしようとしてエラーが発生した場合でも、InferenceService カスタムリソース (CR) が作成され、モデルが Data science projects ページに表示されていました。その場合、ステータスが常に不明のままでした。KServe デプロイプロセスが更新され、エラーが発生した場合に ServingRuntime が作成されなくなりました。

RHOAIENG-548 (以前は ODH-DASHBOARD-1776 として記録されていた問題) - ユーザーにプロジェクト管理者権限がない場合のエラーメッセージ

以前は、プロジェクトに対する管理者権限がない場合、一部の機能にアクセスできず、エラーメッセージにその理由が説明されませんでした。たとえば、1 つの namespace にしかアクセスできない環境でモデルサーバーを作成すると、Error creating model server というエラーメッセージが表示されていました。ただし、モデルサーバーはそのまま正常に作成されます。この問題は解決されています。

RHOAIENG-66 - CodeFlare SDK によってデプロイされた Ray ダッシュボードルートがクラスター証明書の代わりに自己署名証明書を公開する

以前は、openshift_oauth=True オプションを指定して CodeFlare SDK を使用して Ray クラスターをデプロイすると、デプロイ時に作成される Ray クラスターのルートが passthrough 方式を使用して保護されていました。その結果、OAuth プロキシーで使用される自己署名証明書が公開されていました。この問題は解決されています。

RHOAIENG-12 - 一部のブラウザーから Ray ダッシュボードにアクセスできない

一部のブラウザーでは、ブラウザーがダッシュボード URL の接頭辞を http から https に自動的に変更するため、分散ワークロード機能を使用する場合に Ray ダッシュボードにアクセスできないことがありました。この問題は解決されています。

RHODS-6216: ModelMesh oauth-proxy コンテナーが断続的に不安定になる

以前は、ModelMesh oauth-proxy コンテナーの障害により、ModelMesh Pod が正しくデプロイされませんでした。この問題は、ModelMesh ランタイム環境で認証が有効になっている場合にのみ、断続的に発生していました。この問題は解決されています。

RHOAIENG-535 - HTTP リクエストがない場合、デプロイされたモデルの HTTP リクエストを示すメトリクスグラフが正しくない

以前は、デプロイされたモデルが 2 つのデータタイプ (成功と失敗) それぞれの HTTP リクエストを 1 つ以上受信しなかった場合、(モデルサーバー上のすべてのモデルまたは特定のモデルの) HTTP リクエストのパフォーマンスメトリクスを示すグラフが正しく表示されず、失敗したリクエストの数が一定して増加していることを示す直線が表示されていました。この問題は解決されています。

RHOAIENG-1467 - Serverless net-istio コントローラー Pod が OOM に到達する可能性がある

以前は、Knative net-istio-controller Pod (KServe の依存関係) が、メモリー不足 (OOM) エラーにより継続的にクラッシュすることがありました。この問題は解決されています。

RHOAIENG-1899 (以前は RHODS-6539 として記録されていた問題) - Anaconda Professional Edition を検証して有効にできない

以前は、ダッシュボードのキー検証が機能しなかったため、Anaconda Professional Edition を有効にすることができませんでした。この問題は解決されています。

RHOAIENG-2269 - (シングルモデル) ダッシュボードにモデルレプリカの正しい数が表示されない

以前は、シングルモデルサービングプラットフォームで、データサイエンスプロジェクトの Models and model servers セクションにモデルレプリカの正しい数が表示されませんでした。この問題は解決されています。

RHOAIENG-2270 - (シングルモデル) ユーザーがモデルのデプロイメント設定を更新できない

以前は、シングルモデルサービングプラットフォームでデプロイしたモデルのデプロイメント設定 (レプリカの数など) を編集できませんでした。この問題は解決されています。

RHODS-8865: Amazon Web Services (AWS) シンプルストレージサービス (S3) バケットリソースを指定しないとパイプラインサーバーの起動に失敗する

以前は、データサイエンスプロジェクトのデータ接続を作成するときに、AWS_S3_BUCKET フィールドが必須フィールドとして指定されていませんでした。しかし、AWS_S3_BUCKET フィールドが設定されていないデータ接続を使用してパイプラインサーバーを設定しようとすると、パイプラインサーバーを正常に起動できませんでした。この問題は解決されています。Configure pipeline server ダイアログが更新され、Bucket フィールドが必須フィールドとして追加されました。

RHODS-12899 - OpenVINO ランタイムに NVIDIA GPU のアノテーションが欠落している

以前は、ユーザーがモデルサーバーのユーザーインターフェイスで OpenVINO model server (supports GPUs) ランタイムを選択し、NVIDIA GPU アクセラレーターを選択した場合、選択したアクセラレーターが選択したランタイムと互換性がないという不要な警告がシステムによって表示されることがありました。この警告は表示されなくなりました。

RHOAIENG-84 - KServe で自己署名証明書を使用できない

以前は、シングルモデルサービングプラットフォームが自己署名証明書をサポートしていませんでした。この問題は解決されています。KServe で自己署名証明書を使用するには、証明書の使用 で説明されている手順に従ってください。

RHOAIENG-164 - Kserve のモデルサーバーレプリカの数がダッシュボードから正しく適用されない

以前は、デフォルト (1) とは異なるモデルサーバーレプリカの数を設定しても、モデル (サーバー) は 1 つのレプリカでデプロイされました。この問題は解決されています。

RHOAIENG-288 - ワークベンチの推奨イメージバージョンラベルが 2 つのバージョンで表示される

OpenShift AI で使用できるワークベンチイメージのほとんどは、複数のバージョンで提供されます。推奨されるバージョンは最新バージョンのみです。Red Hat OpenShift AI 2.4 および 2.5 では、イメージの複数のバージョンに対して 推奨 タグが誤って表示されていました。この問題は解決されています。

RHOAIENG-293 - 非推奨の ModelMesh モニタリングスタックが 2.4 から 2.5 にアップグレードした後も削除されない

Red Hat OpenShift AI 2.5 では、以前の ModelMesh モニタリングスタックは、ユーザーワークロードモニタリングに置き換えられたため、デプロイされなくなりました。ただし、以前のモニタリングスタックは OpenShift AI 2.5 へのアップグレード中に削除されませんでした。一部のコンポーネントは残り、クラスターリソースを使用しました。この問題は解決されています。

RHOAIENG-343 - OpenShift Service Mesh および OpenShift Serverless の手動設定が KServe では機能しない

OpenShift Serverless および OpenShift Service Mesh をインストールしてから、KServe を有効にして Red Hat OpenShift AI をインストールした場合、KServe はデプロイされませんでした。この問題は解決されています。

RHOAIENG-517 - 編集権限を持つユーザーは作成されたモデルを表示できない

編集権限を持つユーザーは、プロジェクト所有者であるか、プロジェクトの管理者権限を持っていない限り、作成されたモデルを表示できませんでした。この問題は解決されています。

RHOAIENG-804 - FIPS 対応クラスター上で KServe を使用して大規模言語モデルをデプロイできない

以前は、Red Hat OpenShift AI はまだ FIPS 向けに完全には設計されていませんでした。FIPS 対応クラスターでは、KServe を使用して大規模言語モデル (LLM) をデプロイすることはできませんでした。この問題は解決されています。

RHOAIENG-908 - KServe が以前に有効化後に削除されているた場合、ModelMesh を使用できない

以前は、DataScienceCluster オブジェクトで ModelMesh と KServe の両方が有効になっており、その後 KServe を削除すると、ModelMesh を使用して新しいモデルをデプロイできなくなりました。以前に ModelMesh でデプロイされたモデルを引き続き使用できます。この問題は解決されています。

RHOAIENG-2184 - Ray クラスターまたは分散ワークロードを作成できない

以前は、ユーザーは admin 権限または edit 権限を持つ namespace で Ray クラスターまたは分散ワークロードを作成できませんでした。この問題は解決されています。

ODH-DASHBOARD-1991 - ovms-gpu-ootb に推奨アクセラレーターのアノテーションがない

以前は、プロジェクトにモデルサーバーを追加すると、Serving runtime リストに NVIDIA GPU の Recommended serving runtime ラベルが表示されませんでした。この問題は解決されています。

RHOAIENG-807 - ワークベンチの再起動時にアクセラレータープロファイル toleration が削除される

以前は、toleration を含むアクセラレータープロファイルを使用するワークベンチを作成した場合、ワークベンチを再起動すると toleration 情報が削除され、再起動が完了できませんでした。新しく作成された GPU 対応ワークベンチは、最初は起動する可能性がありますが、生成された Pod が永久に保留されたままになるため、その後は正常に再起動されません。この問題は解決されています。

DATA-SCIENCE-PIPELINES-OPERATOR-294: データ受け渡しを使用するスケジュールされたパイプラインの実行で、ステップ間でのデータの受け渡しに失敗するか、ステップ全体が失敗する可能性がある

S3 オブジェクトストアを使用してパイプラインアーティファクトを保存するスケジュールされたパイプラインの実行は、次のようなエラーで失敗する場合があります。

Bad value for --endpoint-url "cp": scheme is missing. Must be of the form http://<hostname>/ or https://<hostname>/

Bad value for --endpoint-url "cp": scheme is missing. Must be of the form http://<hostname>/ or https://<hostname>/

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

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

サポートされている nvidia.com/gpu taint 以外の taint でマークされたノード上の GPU は、ノートブックサーバーの作成時に選択できませんでした。この問題は解決されています。

RHODS-6346: 無効な文字を使用してデータサイエンスプロジェクトを作成すると、不明確なエラーメッセージが表示される

無効な特殊文字を使用してデータサイエンスプロジェクトのデータ接続、ワークベンチ、またはストレージ接続を作成すると、次のエラーメッセージが表示されました。

the object provided is unrecognized (must be of type Secret): couldn't get version/kind; json parse error: unexpected end of JSON input ({"apiVersion":"v1","kind":"Sec ...)

the object provided is unrecognized (must be of type Secret): couldn't get version/kind; json parse error: unexpected end of JSON input ({"apiVersion":"v1","kind":"Sec ...)

このエラーメッセージは、問題を明確に示していませんでした。現在は、エラーメッセージで無効な文字が入力されたことが示されるようになりました。

RHODS-6950: クラスター内のすべての GPU が使用されている場合はワークベンチの GPU をスケールダウンできない

以前のリリースでは、クラスター内のすべての GPU が使用されている場合、ワークベンチ GPU をスケールダウンできませんでした。この問題は、1 つのワークベンチで使用されている GPU と、複数のワークベンチで使用されている GPU に当てはまります。Accelerators リストから None を選択して、GPU をスケールダウンできるようになりました。

RHODS-8939 - 以前のリリースで作成された Jupyter ノートブックのデフォルトの共有メモリーによりランタイムエラーが発生する

リリース 1.31 以降、この問題は解決され、新しいノートブックの共有メモリーはノードのサイズに設定されます。

1.31 より前のリリースで作成された Jupyter ノートブックの場合に、Jupyter ノートブックのデフォルトの共有メモリーは 64 MB に設定されており、ノートブック設定でこのデフォルト値を変更できません。

この問題を修正するには、ナレッジベースの記事 How to change the shared memory for a Jupyter notebook in Red Hat OpenShift AI に記載のプロセスに従う必要があります。

RHODS-9030 - kfdefs リソースの削除時に OpenShift AI のアンインストールプロセスが停止することがある

OpenShift AI マネージドサービスをアンインストールする手順が、OpenShift AI のアンインストール で説明されています。

しかし、このガイドに従っても、アンインストールプロセスが正常に完了しない場合がありました。代わりに、プロセスは、Kubeflow Operator により使用される kfdefs リソースを削除するステップで停止したままになっていました。次の例に示すように、kfdefs リソースは、redhat-ods-applications、redhat-ods-monitoring、および rhods-notebooks namespace に存在する場合があります。

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

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

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

RHODS-8460 - 共有プロジェクトの詳細を編集すると、ユーザーインターフェイスがエラーを報告せずに読み込み状態のままになる

プロジェクトを編集する権限を持つユーザーがその詳細を編集しようとすると、ユーザーインターフェイスは読み込み中の状態のままになり、適切なエラーメッセージが表示されません。プロジェクトを編集する権限を持つユーザーは、説明など、プロジェクト内のフィールドを編集できません。これらのユーザーは、ワークベンチ、データ接続、ストレージなど、プロジェクトに属するコンポーネントのみを編集できます。

ユーザーインターフェイスには適切なエラーメッセージが表示され、プロジェクトの説明は更新されなくなりました。

RHODS-8482 - データサイエンスパイプライングラフに、実行中のパイプラインのノードエッジが表示されない

YAML コードで Tekton 形式の Parameters または when 式が含まれていないパイプラインを実行すると、OpenShift AI ユーザーインターフェイスにグラフノードとの間の接続エッジが表示されませんでした。たとえば、runAfter プロパティーまたは Workspaces を含むパイプラインを使用する場合、ユーザーインターフェイスには、エッジ接続なしで実行されたパイプラインのグラフが表示されます。OpenShift AI ユーザーインターフェイスには、グラフノードとの間の接続エッジが表示されるようになりました。

RHODS-8923 - パイプラインサーバーを作成しようとしたときに、新しく作成されたデータ接続が検出されない

データサイエンスプロジェクト内からデータ接続を作成し、パイプラインサーバーを作成しようとすると、Configure a pipeline server では作成したデータ接続が検出されませんでした。この問題は解決されています。

RHODS-8461 - プロジェクトを別のユーザーと共有する場合、OpenShift AI ユーザーインターフェイスのテキストが誤解を招く

データサイエンスプロジェクトを別のユーザーと共有しようとすると、ユーザーインターフェイスのテキストは、ユーザーがその説明などの詳細をすべて編集できるという誤解を招くような意味を与えます。ただし、ユーザーが編集できるのは、ワークベンチ、データ接続、ストレージなど、プロジェクトに属するコンポーネントのみです。この問題は解決され、ユーザーインターフェイスのテキストは、ユーザーが詳細をすべて編集できるという誤解を招くような意味を持たなくなりました。

RHODS-8462 - "編集" 権限を持つユーザーが Model Server を作成できない

"編集" 権限を持つユーザーは、トークン認証なしで Model Server を作成できるようになりました。トークン認証を使用して Model Server を作成するには、ユーザーは "管理者" 権限を持っている必要があります。

RHODS-8796 - OpenVINO Model Server ランタイムに、GPU の使用を強制するために必要なフラグがない

OpenShift AI には、OpenVINO Model Server (OVMS) モデルサービングランタイムがデフォルトで含まれています。新しいモデルサーバーを設定してこのランタイムを選択すると、Configure model server ダイアログでモデルサーバーで使用する GPU の数を指定できます。ただし、モデルサーバーの設定を完了し、そこからモデルをデプロイすると、モデルサーバーは実際には GPU を使用しませんでした。この問題は現在解決されており、モデルサーバーは GPU を使用します。

RHODS-8861 - パイプライン実行の作成時にホストプロジェクトを変更すると、使用可能なパイプラインのリストが不正確になる

パイプライン実行の作成中にホストプロジェクトを変更すると、インターフェイスは新しいホストプロジェクトのパイプラインを使用可能にすることができません。代わりに、インターフェイスには、最初に Data Science Pipelines Runs ページで選択したプロジェクトに属するパイプラインが表示されます。この問題は解決されています。Create run ページからパイプラインを選択する必要はなくなりました。Create run ボタンをクリックすると、現在のプロジェクトとそのパイプラインに基づいて、パイプラインの選択が自動的に更新されます。

RHODS-8249 - ConfigMap としてアップロードされた環境変数が、代わりに Secret に保存される

以前の OpenShift AI インターフェイスでは、ConfigMap 設定をアップロードして環境変数をワークベンチに追加すると、変数は代わりに Secret オブジェクトに保存されていました。この問題は解決されています。

RHODS-7975 - ワークベンチに複数のデータ接続がある可能性がある

以前は、ワークベンチのデータ接続を変更すると、既存のデータ接続は解放されませんでした。その結果、ワークベンチが複数のデータソースに接続したままになる可能性がありました。この問題は解決されています。

RHODS-7948 - 環境変数を含むシークレットファイルをアップロードすると、値が二重にエンコードされる

以前は、データサイエンスプロジェクトでワークベンチを作成するときに、環境変数を含む YAML ベースのシークレットファイルをアップロードすると、環境変数の値がデコードされませんでした。次に、このプロセスによって作成される結果となる OpenShift シークレットでは、エンコードされた値が再度エンコードされました。この問題は解決されています。

RHODS-6429 - Intel OpenVINO または Anaconda Professional Edition イメージを使用してワークベンチを作成すると、エラーが表示される

以前は、Intel OpenVINO または Anaconda Professional Edition イメージでワークベンチを作成すると、作成プロセス中にエラーが表示されていました。ただし、ワークベンチは正常に作成されています。この問題は解決されています。

RHODS-6372 - アイドル状態のノートブックの選別では、アクティブな端末が考慮されない

以前のバージョンでは、ノートブックイメージに実行中の端末があり、アクティブな実行中のカーネルがない場合、idle notebook culler はノートブックを非アクティブとして検出し、ターミナルを停止していました。この問題は解決されています。

RHODS-5700 - ワークベンチの作成時にデータ接続を作成または接続できない

ワークベンチの作成時に、ユーザーは新しいデータ接続を作成したり、既存のデータ接続に接続したりできませんでした。

RHODS-6281 - 管理者グループがクラスターから削除された場合、OpenShift AI 管理者は設定ページにアクセスできない

以前は、Red Hat OpenShift AI 管理者グループがクラスターから削除された場合、OpenShift AI 管理者ユーザーは OpenShift AI ダッシュボードの Settings ページにアクセスできなくなりました。特に、以下の動作が見られました。

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

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

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

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

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

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

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

以前は、最新の toleration を取得するために、ユーザーは関連するワークベンチを編集し、変更を加えず、ワークベンチを再度保存する必要がありました。ユーザーは、データサイエンスプロジェクトのワークベンチを停止してから再起動すると、最新の toleration の変更を適用できるようになりました。

RHODS-6779 - OpenShift AI 1.20 から OpenShift AI 1.21 にアップグレードした後、モデルのサービングに失敗する

OpenShift AI 1.20 から OpenShift AI 1.21 にアップグレードするときに、modelmesh-serving Pod が存在しないイメージをプルしようとしたため、イメージプルエラーが発生しました。その結果、OpenShift AI のモデル提供機能を使用してモデルを提供できませんでした。odh-openvino-servingruntime-container-v1.21.0-15 イメージが正常にデプロイされるようになりました。

RHODS-5945 - OpenShift AI で Anaconda Professional Edition を有効化できない

Anaconda Professional Edition を OpenShift AI で使用できるようにすることができませんでした。代わりに、関連する Pod の Events ページに InvalidImageName エラーが表示されました。Anaconda Professional Edition を有効にできるようになりました。

RHODS-5822 - データサイエンスプロジェクトによって作成された PVC の使用率が 90% および 100% を超えた際に、管理者ユーザーに警告が表示されない

PVC が 90% を超え、容量の 100% を超えたことを示す警告が、データサイエンスプロジェクトによって作成された PVC の管理者ユーザーに表示されませんでした。管理者ユーザーは、PVC が容量の 90% および 100% を超えたときに、ダッシュボードから警告を表示できるようになりました。

RHODS-5889 - データサイエンスノートブックが "保留中" ステータスのままになっている場合に、エラーメッセージが表示されない

ノートブック Pod を作成できなかった場合、OpenShift AI インターフェイスにはエラーメッセージが表示されませんでした。データサイエンスノートブックを生成できない場合は、エラーメッセージが表示されるようになりました。

RHODS-5886 - データサイエンスワークベンチから Hub Control Panel d ダッシュボードに戻ると失敗する

File Log Out をクリックして、ワークベンチ Jupyter ノートブックからダッシュボードに戻ろうとすると、ダッシュボードにリダイレクトされ、"Logging out" ページが表示されたままになります。同様に、File Hub Control Panel をクリックしてダッシュボードに戻ろうとすると、誤って Start a notebook server ページにリダイレクトされます。データサイエンスワークベンチから Hub コントロールパネルダッシュボードに戻ると、想定どおりに動作するようになりました。

RHODS-6101 - 管理者はすべてのノートブックサーバーを停止できない

OpenShift AI 管理者は、すべてのノートブックサーバーを同時に停止できませんでした。管理者は、Stop all servers ボタンを使用してすべてのノートブックサーバーを停止し、関連するユーザーの横にあるアクションメニューから Stop server を選択して、1 つのノートブックを停止できるようになりました。

RHODS-5891 - ワークベンチのイベントログが明確に表示されない

ワークベンチを作成するとき、ユーザーは OpenShift AI インターフェイスでイベントログウィンドウを簡単に見つけることができませんでした。Status 列の下の Starting ラベルにカーソルを合わせると、下線が引かれるようになりました。これは、クリックしてノートブックのステータスとイベントログを表示できることを示しています。

RHODS-6296 - Google Chrome 以外のブラウザーを使用すると ISV アイコンがレンダリングされない

Google Chrome 以外のブラウザーを使用すると、Explore および Resources ページの下にあるすべての ISV アイコンがレンダリングされませんでした。サポートされているすべてのブラウザーで ISV アイコンが正しく表示されるようになりました。

RHODS-3182 - Jupyter で使用可能な GPU の誤った数が表示される

ユーザーが Jupyter でノートブックインスタンスを作成しようとしても、GPU が割り当てられているため、スケジューリングに使用できる GPU の最大数は更新されませんでした。Jupyter で、使用可能な GPU の正しい数が表示されるようになりました。

RHODS-5890 - 複数の永続ボリュームが同じディレクトリーにマウントされている場合、ワークベンチの起動に失敗する

同じワークベンチ内の同じマウントフォルダーに複数の永続ボリューム (PV) をマウントすると、ノートブック Pod の作成が失敗し、問題があることを示すエラーが表示されませんでした。

RHODS-5768 - データサイエンスプロジェクトが Red Hat OpenShift AI のユーザーに表示されない

プロジェクトの Display Name プロパティーの末尾にある [DSP] 接尾辞を削除すると、関連するデータサイエンスプロジェクトが表示されなくなりました。ユーザーがこの接尾辞を削除することはできなくなりました。

RHODS-5701 - データ接続設定の詳細が上書きされる

データ接続がワークベンチに追加されると、そのデータ接続の設定の詳細が環境変数に保存されていました。2 番目のデータ接続が追加されると、設定の詳細は同じ環境変数を使用して保存されました。つまり、最初のデータ接続の設定が上書きされました。現時点では、ユーザーは各ワークベンチに最大 1 つのデータ接続を追加できます。

RHODS-5252 - ノートブック Administration ページでは、ユーザーのノートブックサーバーへの管理者アクセスが提供されない

OpenShift AI ダッシュボードからアクセスされるノートブック Administration ページには、管理者がユーザーのノートブックサーバーにアクセスする手段が提供されていませんでした。管理者は、ユーザーのノートブックサーバーの起動または停止のみに制限されていました。

RHODS-2438 - アップグレード時に PyTorch および TensorFlow イメージを利用できない

OpenShift AI 1.3 からそれより後のバージョンにアップグレードする場合、ユーザーは PyTorch および TensorFlow イメージを約 30 分間利用できませんでした。その結果、ユーザーはアップグレードプロセス中に Jupyter で PyTorch および TensorFlow ノートブックを起動できなくなりました。この問題は解決されています。

RHODS-5354 - ノートブックサーバーの起動時に環境変数名が検証されない

環境変数名は、Start a notebook server ページで検証されませんでした。無効な環境変数が追加された場合、ユーザーはノートブックを正常に起動できませんでした。環境変数名がリアルタイムでチェックされるようになりました。無効な環境変数名を入力した場合は、有効な環境変数名はアルファベット、数字、_、-、または . で構成され、数字で始まってはいけないことを示すエラーメッセージが表示されます。

RHODS-4617 - 利用可能な GPU がある場合にのみ、Number of GPUs ドロップダウンが表示される

以前は、GPU ノードが使用可能な場合、Number of GPUs は Start a notebook server ページにのみ表示されていました。クラスターで自動スケーリングマシンプールが定義されている場合は、Number of GPUs のドロップダウンも正しく表示されるようになりました。現在 GPU ノードを使用できない場合でも、クラスターで新しい GPU ノードがプロビジョニングされる可能性があります。

RHODS-5420 - クラスター管理者がクラスター内に存在する唯一のユーザーの場合、管理者アクセス権を取得しない

以前は、クラスター管理者がクラスター内に存在する唯一のユーザーである場合、Red Hat OpenShift 管理者アクセスは自動的に取得されませんでした。管理者アクセスがクラスター管理者ユーザーに正しく適用されるようになりました。

RHODS-4321 - ノートブックの選択中に間違ったパッケージバージョンが表示される

Start a notebook server ページに、CUDA ノートブックイメージの誤ったバージョン番号 (11.7 ではなく 11.4) が表示されました。インストールされている CUDA のバージョンは、このページでは指定されなくなりました。

RHODS-5001 - 管理者ユーザーが無効な toleration をノートブック Pod に追加できる可能性がある

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

RHODS-5100 - グループロールバインディングがクラスター管理者に適用されない

以前は、クラスター管理者権限を特定のユーザーではなくグループに割り当てると、ダッシュボードは管理グループ内のユーザーの管理者権限を認識できませんでした。グループロールバインディングが、期待どおりにクラスター管理者に正しく適用されるようになりました。

RHODS-4947 - 古い Minimal Python ノートブックイメージがアップグレード後も存続する

OpenShift AI 1.14 から 1.15 にアップグレードした後、Minimal Python ノートブックの古いバージョンが、関連するすべてのパッケージバージョンを含む形で永続します。最小限の Python ノートブックの古いバージョンは、アップグレード後に保持されなくなりました。

RHODS-4935 - ダッシュボードログに "missing x-forwarded-access-token header" というエラーメッセージが過剰に表示される

rhods-dashboard Pod のログには、readiness プローブが /status エンドポイントにヒットしたため、"missing x-forwarded-access-token header" ヘッダーエラーメッセージが大量に含まれていました。この問題は解決されています。

RHODS-2653 - サンプル Pachyderm ノートブックで生成されたイメージをフェッチ中にエラーが発生する

ユーザーが Jupyter のサンプル Pachyderm ノートブックを使用してイメージを取得しようとしたときに、エラーが発生しました。エラーには、イメージが見つからなかったと表示されていました。Pachyderm はこの問題を修正しました。

RHODS-4584 - Jupyter が OpenVINO ノートブックイメージを使用したノートブックサーバーの起動に失敗する

Jupyter の Start a notebook server ページは、OpenVINO ノートブックイメージを使用してノートブックサーバーの起動に失敗します。Intel 社は、この問題を修正するために OpenVINO Operator への更新を提供しました。

RHODS-4923 - 使用状況データの収集を無効にした後に非標準のチェックボックスが表示される

Cluster settings ページで使用状況データの収集を無効にした後、ユーザーが OpenShift AI ダッシュボードの別の領域にアクセスしてから Cluster settings ページに戻ると、Allow collection of usage data チェックボックスに非標準のスタイルが適用されていたため、オンまたはオフにすると、他のチェックボックスと同じように表示されませんでした。

RHODS-4938 - Notebook Images ページに間違った見出しが表示される

OpenShift AI ダッシュボードの Settings ページからアクセスできる Notebook Images ページには、ユーザーインターフェイスに間違った見出しが表示されていました。Notebook image settings の見出しは BYON image settings として表示され、Import Notebook images の見出しは Import BYON images として表示されます。正しい見出しが予想通りに表示されるようになりました。

RHODS-4818 - NVIDIA GPU アドオンがインストールされている場合、Jupyter はイメージを表示できない

Start a notebook server ページには、NVIDIA GPU アドオンのインストール後にノートブックイメージが表示されませんでした。イメージが正しく表示され、Start a notebook server ページから起動できるようになりました。

RHODS-4797 - 使用率が 90% および 100% を超えた場合、PVC 使用量制限アラートが送信されない

PVC が 90% を超え、容量の 100% を超えて送信できなかったかどうかを示すアラート。これらのアラートはトリガーされ、予想通りに送信されるようになりました。

RHODS-4366 - Operator の再起動時にクラスター設定がリセットされる

OpenShift AI Operator Pod が再起動されると、クラスター設定がデフォルト値にリセットされ、カスタム設定が削除されることがありました。OpenShift AI Operator は、OpenShift AI の新しいバージョンがリリースされたとき、および Operator を実行するノードに障害が発生したときに再起動されました。この問題は、Operator が ConfigMap を誤ってデプロイするために生じました。Operator デプロイメントの手順が更新され、これが実行されなくなりました。

RHODS-4318 - OpenVINO ノートブックイメージが正常にビルドされない

OpenVINO ノートブックイメージは正常にビルドに失敗し、エラーメッセージを表示していました。この問題は解決されています。

RHODS-3743 - Starburst Galaxy クイックスタートの手順にダウンロードリンクが提供されていない

ダッシュボードの Resources ページにある Starburst Galaxy クイックスタートでは、ユーザーが explore-data.ipynb notebook を開く必要がありましたが、手順でリンクを提供されませんでした。代わりに、リンクはクイックスタートの導入時に提供されていました。

RHODS-1974 - アラート通知メールを変更するには Pod の再起動が必要

Red Hat OpenShift AI Add-On の通知メールアドレスのリストへの変更は、rhods-operator Pod と prometheus-* Pod が再起動されるまで適用されませんでした。

RHODS-2738 - Red Hat OpenShift API Management 1.15.2 アドオンのインストールが正常に完了しない

Red Hat OpenShift API Management 1.15.2 アドオンと統合された OpenShift AI インストールの場合、Red Hat OpenShift API Management インストールプロセスは SMTP 認証情報のシークレットを正常に取得できませんでした。そのため、インストールが完了しませんでした。

RHODS-3237 - GPU チュートリアルがダッシュボードに表示されない

Gtc2018-numba にある "GPU コンピューティングチュートリアル" は、ダッシュボードの Resources ページに表示されませんでした。

RHODS-3069 - GPU ノードが利用できないときに GPU の選択が持続する

ユーザーが GPU をサポートするノートブックサーバーをプロビジョニングし、その後、使用されている GPU ノードがクラスターから削除された場合、ユーザーはノートブックサーバーを作成できませんでした。これは、接続されている GPU の数に最近使用された設定がデフォルトで使用されていたために発生しました。

RHODS-3181 - Pachyderm が OpenShift Dedicated 4.10 クラスターと互換性を持つようになる

Pachyderm は当初、OpenShift Dedicated 4.10 と互換性がなかったため、OpenShift Dedicated 4.10 クラスター上で実行される OpenShift AI では使用できませんでした。Pachyderm は、OpenShift Dedicated 4.10 で利用可能になり、互換性があります。

RHODS-2160 - OpenShift AI と OpenShift API Management の両方がインストールされている場合、アンインストールプロセスが完了しない

OpenShift AI と OpenShift API Management を同じクラスターに共にインストールすると、両方とも同じ Virtual Private Cluster (VPC) を使用します。これらのアドオンのアンインストールプロセスでは、VPC の削除が試行されます。以前は、両方のアドオンがインストールされている場合、一方のサービスのアンインストールプロセスがブロックされていました。これは、VPC 内にもう一方のサービスのリソースがまだ残っているためです。この競合が発生しないように、クリーンアッププロセスが更新されました。

RHODS-2747 - OpenShift AI のアップグレード後にイメージが誤って更新される

OpenShift AI をアップグレードするプロセスが完了した後、Jupyter はノートブックイメージを更新できませんでした。これは、イメージキャッシュメカニズムの問題が原因です。アップグレード後、イメージが正しく更新されるようになりました。

RHODS-2425 - ノートブックの選択中に誤った TensorFlow および TensorBoard が表示される

Start a notebook server ページに、TensorFlow ノートブックイメージの TensorFlow と TensorBoard のバージョン番号 (2.4.0) が正しく表示されませんでした。これらのバージョンは、TensorFlow 2.7.0 および TensorBoard 2.6.0 に修正されています。

RHODS-24339 - 有効なアプリケーションのクイックスタートリンクが表示されない

一部のアプリケーションでは、Enabled ページのアプリケーションタイルに Open quick start リンクが表示されませんでした。その結果、ユーザーは関連するアプリケーションのクイックスタートツアーに直接アクセスできませんでした。

RHODS-2215 - ノートブックの選択中に間違った Python バージョンが表示される

Start a notebook server ページに、TensorFlow および PyTorch ノートブックイメージに対して誤ったバージョンの Python が表示されました。さらに、パッケージバージョン番号の 3 番目の整数が表示されなくなりました。

RHODS-1977 - ノートブックサーバーの起動に失敗した後、10 分間待機する

ノートブックサーバーの起動中に Jupyter リーダー Pod に障害が発生した場合、ユーザーは Pod が再起動するまでノートブックサーバーにアクセスできませんでした。これには約 10 分かかりました。このプロセスは改善され、新しいリーダー Pod が選出されたときにユーザーがサーバーにリダイレクトされるようになりました。このプロセスがタイムアウトになると、ユーザーには 504 Gateway Timeout エラーが表示され、サーバーにアクセスするために更新できます。