第7章 解決した問題

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

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 - Importer コンポーネント(dsl.importer)により、パイプラインが実行されない

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

rhOAIENG-14652 - kfp-client が OCP 4.16 以降のパイプラインサーバーに接続できない

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

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 クラスター内のノートブックから分散データサイエンスワークロードを実行すると、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 モデルをシングルモデルサービングプラットフォームにデプロイできない

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

RHOAIENG-8218 - OCP 内部イメージレジストリーを使用せずに OpenShift 4.15 クラスターに作成されたワークベンチにログインできない

OpenShift Container Platform 内部イメージレジストリーが有効になっていない OpenShift クラスターでワークベンチを作成すると、ワークベンチは正常に起動しますが、ログインすることはできません。

これは、4.15.15 より前の OpenShift 4.15.x バージョンにおける既知の問題です。この問題を解決するには、OpenShift 4.15.15 以降にアップグレードしてください。

RHOAIENG-7346 - アップグレード後、分散ワークロードが既存のパイプラインから実行されなくなる

以前は、OpenShift AI 2.10 にアップグレードしようとすると、クラスターがパイプライン内でのみ作成された場合、分散ワークロードは既存のパイプラインから実行されなくなりました。この問題は解決されています。

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 クラスター内のノートブックから分散データサイエンスワークロードを実行すると、続行前に 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 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 - ワークベンチの再起動時にアクセラレータープロファイル 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>/

この問題は、スケジュールされたパイプライン実行が原因で 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 ...)

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

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

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) を同じワークベンチの同じマウントフォルダーにマウントすると、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 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) を使用します。これらの 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 エラーが表示され、サーバーにアクセスするために更新できます。