第6章 解決された問題

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 を超える長いプロンプトを推論サービスに送信すると、推論サービスが応答しませんでした。この問題は発生しなくなりました。