第6章既知の問題

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

重要

OpenShift AI 2.8 の最新の更新を受け取るには、Red Hat OpenShift AI Operator のインストールで、eus-2.8 更新チャネルを使用するように設定する必要があります。

2.8 リリースのライフサイクル (フルサポートフェーズ期間を含む) に関する最新情報は、Red Hat OpenShift AI Self-Managed のライフサイクルを参照してください。

RHOAIENG-10596 - モデルサービングスタックが DSCInitialization オブジェクト内のカスタム CA バンドルを正しく処理しない

DSCInitialization オブジェクトにカスタム認証局 (CA) バンドルを追加すると、カスタム CA バンドルには含まれないエンドポイントに対して、Model Serving スタック (ModelMesh および KServe) 内のすべての SSL 検証が失敗します。これは、単一モデルサービングスタックとマルチモデルサービングスタックの両方に影響します。

回避策: 適切な場合は、カスタム CA バンドルの使用を回避してください。デプロイメントにカスタム CA バンドルが必要な場合は、Model Serving スタックからの接続が必要になる可能性があるエンドポイントの自己署名証明書を追加します。

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

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

回避策: Ray クラスターの名前を、namespace 内の対応するノートブック名と異なる名前に変更します。

RHOAIENG-7806 - 利用可能なワークベンチイメージが多数ある場合は、利用可能なワークベンチイメージのリストが部分的に隠れる

Data Science Projects ページの Workbenches タブでワークベンチを作成しようとする際に、デプロイメントに多数のワークベンチイメージが含まれていると、使用可能なワークベンチイメージのリストがユーザーインターフェイスによって部分的に隠れてしまいます。その結果、隠れたワークベンチイメージをリストから選択することはできません。

回避策: 各ワークベンチイメージがユーザーインターフェイスによって隠れないように、デプロイメントで使用可能なワークベンチイメージの数を減らします。

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

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

OpenShift Container Platform クラスター管理者は、クラスター上で内部イメージレジストリーが有効になっているかどうかを確認できます。
OpenShift AI 管理ユーザーは、タグ表記を使用してカスタムイメージをインポートしたかどうかを確認できます。
回避策
SHA ダイジェスト (例: quay.io/my-repo/my-image@sha256:xxxxxxxxxxxxx) を使用してカスタムイメージをインポートし、カスタムイメージを使用してワークベンチを作成します。

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

OpenShift Container Platform 内部イメージレジストリーが有効になっていない OpenShift Container Platform 4.15 クラスターでワークベンチを作成すると、ワークベンチは正常に起動しますが、ログインすることはできません。The authorization server encountered an unexpected condition that prevented it from fulfilling the request というエラーが表示されます。

回避策

作成するワークベンチごとに、OpenShift Container Platform でサービスアカウントトークンシークレットを手動で作成します。

OpenShift CLI から、次のコマンドを使用してサービスアカウントトークンシークレットを作成します。<workbench-name> はワークベンチの名前に置き換え、<project-name> はデータサイエンスプロジェクトの名前に置き換えます。
```
cat <<'EOF' | oc apply -f -
---
kind: Secret
apiVersion: v1
metadata:
  name: <workbench-name>-token
  namespace: <project-name>
  annotations:
    kubernetes.io/service-account.name: <workbench-name>
type: kubernetes.io/service-account-token
EOF
```
ブラウザーでページを更新し、ワークベンチにログインします。

Web コンソールを使用してサービスアカウントトークンシークレットを作成する方法については、サービスアカウントトークンシークレットの作成を参照してください。

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

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

回避策

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

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

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

大文字またはスペースを含むデータサイエンスプロジェクト名を使用すると、ModelMesh コンポーネントに基づくモデルサーバーのモデルサーバーメトリクスページで問題が発生する可能性があります。メトリクスページがデータを正しく受信できず、400 Bad Request エラーが発生してページが読み込まれなくなる可能性があります。

回避策: OpenShift Container Platform で、Kubernetes リソース名の標準を満たすようにデータサイエンスプロジェクトの表示名を変更します。その際、小文字の英数字とハイフンのみを使用します。

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

場合によっては、カスタム CA バンドルで自己署名証明書が設定された後、カスタム証明書が odh-trusted-ca-bundle ConfigMap から欠落したり、ConfigMap が managed に設定されている場合に、予約されていない namespace に odh-trusted-ca-bundle ConfigMap が含まれていなかったりすることがあります。これらの問題はほとんど発生しません。

回避策: Red Hat OpenShift AI Operator Pod を再起動します。

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

RStudio および CUDA - RStudio ワークベンチイメージの BuildConfig 定義が、OpenShift AI の間違ったブランチを参照しています。BuildConfig 定義は、rhoai-2.8 ブランチではなく main ブランチを誤って参照しています。

回避策: OpenShift AI で RStudio および CUDA - RStudio ワークベンチイメージを使用するには、ナレッジベース記事 Branch workaround for RStudio image BuildConfig definition の手順に従ってください。

RHOAIENG-4497 - 自己署名証明書を使用したマルチモデルサービスプラットフォーム上のモデルが、2.8 にアップグレードした後に動作しなくなる

以前のバージョンでは、マルチモデルサービスプラットフォームでモデルを提供するときに自己署名証明書を使用する場合は、データ接続で使用される storage-config シークレットを手動で設定して、認証局 (CA) バンドルを指定する必要がありました。

この回避策を使用していた以前のバージョンの OpenShift AI を最新バージョンにアップグレードすると、マルチモデルサービスプラットフォームがモデルを提供できなくなります。

回避策: マルチモデルとシングルモデルの両方のサービス提供プラットフォームで自己署名証明書を使用するには、CA バンドルの追加の手順に従います。

RHOAIENG-4430 - データ接続がないと KServe に対して CA バンドルが機能しない

自己署名証明書を使用するために OpenShift クラスターに認証局 (CA) バンドルをインストールし、モデルを提供するためのデータ接続を OpenShift AI ダッシュボードを使用して作成した場合、証明書が storage-config というシークレットに自動的に保存されます。しかし、OpenShift AI ダッシュボードを使用せずに、別のシークレット名またはサービスアカウントを指定するように基礎となる InferenceService リソースを設定すると、OpenShift AI がモデルへの SSL 接続の検証に失敗し、モデルのステータスに [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate と表示されます。

回避策: OpenShift AI ダッシュボードを使用して、モデルのデータ接続を作成します。InferenceService リソースを手動で変更して別のシークレット名またはサービスアカウントを指定しないでください。

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

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

回避策

パイプラインサーバーを削除します。詳細は、パイプラインサーバーの削除を参照してください。
OpenShift コマンドラインインターフェイス (CLI) で、クラスター管理者としてクラスターにログインし、次のコマンドを実行して冗長な ScheduledWorkFlow リソースを削除します。
```
$ oc -n <data science project name> delete scheduledworkflows --all
```

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

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

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

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

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

回避策

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

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

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

redhat-ods-applications プロジェクトの OdhDashboardConfig カスタムリソースを編集して保存すると、次のような Managed resource に関する警告メッセージが誤って表示されます。

This resource is managed by DSC default-doc and any modifications may be overwritten. Edit the managing resource to preserve changes.

このメッセージは無視しても問題ありません。

回避策: Save をクリックして警告メッセージを閉じ、編集内容を適用します。

RHOAIENG-3372 - 非接続環境でのパイプラインの実行がイメージ URL により失敗する

データサイエンスパイプラインの実行では、registry.redhat.io/ubi8/ubi-micro イメージ URL ではなく、registry.access.redhat.com/ubi8/ubi-micro イメージ URL が参照されます。非接続環境ではこの不一致があると、パイプライン実行に失敗します。

回避策

次のコードを含む新しいカスタムリソース (CR) を作成します。ここで、my-disconnected-registry.com:8443 はイメージレジストリーの URL に置き換えます。

apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: workaround-3372 # Enter a unique name
spec:
  repositoryDigestMirrors:
  - mirrors:
    - my-disconnected-registry.com:8443/ubi8 # Use your image registry URL
    source: registry.access.redhat.com/ubi8

Pipeline を再度実行します。

RHOAIENG-1825 - 自己署名証明書を設定した後、Elyra を含むワークベンチでパイプラインの実行が失敗する場合がある

自己署名証明書を一元的に設定した後、Elyra を含むワークベンチでパイプラインを実行すると失敗する場合があります。

回避策

回避策の手順については、次のナレッジベースの記事を参照してください。

RHOAIENG-3025 - OVMS が要求するディレクトリーレイアウトが KServe StoragePuller レイアウトと競合する

OpenVINO Model Server (OVMS) ランタイムを使用してシングルモデルサービスプラットフォーム (KServe を使用) にモデルをデプロイすると、OVMS が要求するディレクトリーレイアウトと KServe で使用されるモデル取得ロジックのレイアウトの間に不一致が生じます。具体的には、OVMS はモデルファイルを /<mnt>/models/1/ ディレクトリーに配置することを要求しますが、KServe はモデルファイルを /<mnt>/models/ ディレクトリーに配置します。

回避策

次の操作を実行します。

S3 互換ストレージバケットで、モデルファイルを 1/ というディレクトリーに置きます (例: /<s3_storage_bucket>/models/1/<model_files>)。
OVMS ランタイムを使用してシングルモデルサービスプラットフォームにモデルをデプロイするには、次のいずれかの方法を選択して、モデルファイルへのパスを指定します。
- OpenShift AI ダッシュボードを使用してモデルをデプロイする場合は、データ接続の Path フィールドで、/<s3_storage_bucket>/models/ 形式を使用してモデルファイルへのパスを指定します。パスの一部として 1/ ディレクトリーを指定しないでください。
- 独自の InferenceService カスタムリソースを作成してモデルをデプロイする場合は、storageURI フィールドの値を /<s3_storage_bucket>/models/ に設定します。パスの一部として 1/ ディレクトリーを指定しないでください。

KServe は、指定したパスのサブディレクトリーからモデルファイルを取得します。この場合、KServe は S3 互換ストレージの /<s3_storage_bucket>/models/1/ ディレクトリーからモデルファイルを正しく取得します。

RHOAIENG-3018 - KServe 上の OVMS がダッシュボードに正しいエンドポイントを公開しない

OpenVINO Model Server (OVMS) ランタイムを使用して単一モデルサービングプラットフォームにモデルをデプロイした場合、デプロイしたモデルの Inference endpoint フィールドに表示される URL が不完全なものになります。モデルにクエリーを送信するには、URL の末尾に /v2/models/_<model-name>_/infer 文字列を追加する必要があります。_<model-name>_ は、デプロイしたモデルの名前に置き換えてください。

回避策: なし。

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

シングルモデルサービスプラットフォーム (KServe を使用) を使用してモデルをデプロイすると、推論サービスに sidecar.istio.io/inject=true アノテーションが付いている場合でも、作成される Pod から istio-proxy コンテナーが欠落する場合があります。

OpenShift AI 2.7 では、istio-proxy コンテナーがなくても問題が発生しない場合があります。ただし、Pod で接続の問題が発生した場合は、コンテナーの欠落が原因である可能性があります。

回避策: 問題のある Pod を削除します。欠落していたコンテナーを持つ新しい Pod が OpenShift AI によって自動的に作成されます。

RHOAIENG-2759 - プロジェクトにセキュリティーで保護されたモデルサーバーと通常のモデルサーバーの両方が存在する場合、モデルのデプロイメントが失敗する

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

回避策: 利用できるものはありません。

RHOAIENG-2602 - ModelMesh Pod の再起動により、"平均応答時間" のサーバーメトリクスグラフに複数の行が表示される

ModelMesh Pod が再起動されると、平均応答時間 のサーバーメトリクスグラフに複数の行が表示されます。

回避策: 利用できるものはありません。

RHOAIENG-2585 - クラスターで UWM が有効になっていない場合、UI にエラー/警告が表示されない

クラスターで User Workload Monitoring (UWM) が 無効化 されている場合、Red Hat OpenShift AI はユーザーに正しく警告しません。UWM は、モデルメトリクスが正しく機能するために必要です。

回避策: ユーザー定義プロジェクトのモニタリングの有効化の説明に従って、クラスター内で UWM が有効になっていることを手動で確認します。

RHOAIENG-2555 - フォームでサービスランタイムを変更すると、モデルフレームワークセレクターがリセットされない

Deploy model ダイアログを使用してシングルモデルサービスプラットフォームにモデルをデプロイするときに、ランタイムとサポートされているフレームワークを選択した後で別のランタイムに切り替えても、既存のフレームワークの選択がリセットされません。そのため、選択したランタイムでサポートされていないフレームワークを使用してモデルをデプロイできます。

回避策: モデルのデプロイ時に、選択したランタイムを変更する場合は、Select a framework リストを再度クリックして、サポートされているフレームワークを選択してください。

RHOAIENG-2479 - 2.4 または 2.5 からのアップグレード中に ModelMesh モニタリングスタックが削除されない

Red Hat OpenShift AI Operator をバージョン 2.4 から 2.5 にアップグレードしてから Operator をバージョン 2.6、2.7、または 2.8 に更新すると、ハードウェアリソースを消費するモデルのモニタリングに関連するすべてのコンポーネントが、クラスターから削除されます。ハードウェアリソースを消費しない一部の残りのモデルモニタリングリソースは、引き続き存在します。

回避策: これらのリソースを削除するには、cluster-admin 権限で次の oc delete コマンドを実行します。

$ oc delete service rhods-model-monitoring -n redhat-ods-monitoring
$ oc delete service prometheus-operated -n redhat-ods-monitoring
$ oc delete sa prometheus-custom -n redhat-ods-monitoring
$ oc delete sa rhods-prometheus-operator -n redhat-ods-monitoring
$ oc delete prometheus rhods-model-monitoring -n redhat-ods-monitoring
$ oc delete route rhods-model-monitoring -n redhat-ods-monitoring

RHOAIENG-2468 - KServe と同じプロジェクト内のサービスが OpenShift でアクセスできなくなる場合がある

シングルモデルサービスプラットフォーム (KServe を使用) にデプロイされたモデルを含むデータサイエンスプロジェクトに OpenShift AI 以外のサービスをデプロイする場合、サービスのアクセシビリティーが、OpenShift クラスターのネットワーク設定の影響を受ける可能性があります。これは、OVN-Kubernetes ネットワークプラグインをホストのネットワーク namespace と組み合わせて使用している場合に、特に起こりやすくなります。

回避策

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

シングルモデルサービスプラットフォームにデプロイされたモデルが含まれていない別のデータサイエンスプロジェクトに、サービスをデプロイします。または、別の OpenShift プロジェクトにサービスをデプロイします。
次の例に示すように、サービスが存在するデータサイエンスプロジェクトで、アプリケーション Pod への Ingress トラフィックを受け入れるネットワークポリシーを追加します。
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-to-myapp
spec:
  podSelector:
    matchLabels:
      app: myapp
  ingress:
     - {}
```

RHOAIENG-2312 - コードサーバーワークベンチで numpy のインポートが失敗する

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

回避策

code-server ワークベンチの Activity bar から、メニューアイコン ( ) > View > Command Palette を選択し、Command Palette を開きます。
Firefox では、F1 キーボードショートカットを使用してコマンドパレットを開くことができます。
python: s と入力します。
ドロップダウンリストから、Python: Select interpreter アクションを選択します。
Select Interpreter ダイアログで、Enter interpreter path… を選択します。
インタープリターのパスとして /opt/app-root/bin/python3 と入力し、Enter を押します。
ドロップダウンリストから、新しい Python インタープリターを選択します。
新しいインタープリター (app-root) が ステータスバー に表示されることを確認します。選択したインタープリターは、ワークベンチを停止して再起動しても保持されるため、回避策はワークベンチごとに 1 回だけ実行する必要があります。

RHOAIENG-2228 - 間隔が 15 秒に設定されている場合、パフォーマンスメトリクスグラフが絶えず変化する

モデルメトリクス画面の Endpoint performance タブで、Refresh interval を 15 秒に、Time range を 1 時間に設定すると、グラフの結果は連続的に変化します。

回避策: 利用できるものはありません。

RHOAIENG-2183 - エンドポイントのパフォーマンスグラフに間違ったラベルが表示される場合がある

モデルメトリクス画面の Endpoint performance タブで、グラフツールチップに誤ったラベルが表示される場合があります。

回避策: 利用できるものはありません。

RHOAIENG-1919 - Model Serving ページが、デプロイメント直後にモデルルート URL の取得または報告に失敗する

OpenShift AI ダッシュボードからモデルをデプロイすると、システムは次の警告メッセージを表示し、モデルの Status 列には OK または緑色のチェックマークが付き、成功したことを示します。

Failed to get endpoint for this deployed model. routes.rout.openshift.io"<model_name>" not found

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

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

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

回避策

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

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

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

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

回避策

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RHOAIENG-497 - DSCI を削除すると、OpenShift Service Mesh CR がユーザーへの通知なしに削除される

DSCInitialization リソースを削除すると、OpenShift Service Mesh CR も削除されます。警告メッセージは表示されません。

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

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

RHOAIENG-282 - 必要なリソースが利用できない場合、ワークロードはディスパッチすべきではない

場合によっては、単一マシンインスタンスに RayCluster を正常にプロビジョニングするために十分なリソースがない場合でも、ワークロードがディスパッチされることがあります。AppWrapper CRD は Running 状態のままであり、関連する Pod は無期限に Pending 状態になります。

回避策: 追加のリソースをクラスターに追加します。

RHOAIENG-131 - InferenceService が Loaded と報告した後、gRPC エンドポイントが適切に応答しない

多数の InferenceService インスタンスが生成され、リクエストがダイレクトされると、Service Mesh Control Plane (SMCP) が応答しなくなります。InferenceService インスタンスのステータスは Loaded ですが、gRPC エンドポイントへの呼び出しはエラーとともに返されます。

回避策: ServiceMeshControlPlane カスタムリソース (CR) を編集して、Istio Egress Pod と Ingress Pod のメモリー制限を増やします。

RHOAIENG-130 - モデルが起動されたばかりの場合の同期の問題

KServe コンテナーのステータスが Ready の場合、TGIS コンテナーの準備ができていなくてもリクエストは受け入れられます。

回避策: 数秒待って、すべての初期化が完了し、TGIS コンテナーが実際に準備完了であることを確認してから、リクエストの出力を確認します。

RHOAIENG-88 - Red Hat OpenShift AI ダッシュボードにログインできない

Red Hat OpenShift AI にログインしようとすると、500 internal error エラーメッセージが表示されることがあります。

回避策: DataScienceCluster オブジェクトの dashboard コンポーネントを無効にしてから再度有効にします。

RHOAIENG-3115 - モデルが準備完了として表示された後も数秒間クエリーできない

マルチモデルサービングプラットフォームを使用してデプロイされたモデルは、ダッシュボードに Ready と表示されてもクエリーに応答しない場合があります。モデルエンドポイントにクエリーを実行すると、“Application is not available" という応答が表示されることがあります。

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

RHOAIENG-1619 (以前は DATA-SCIENCE-PIPELINES-165 として記録されていた問題) - S3 バケットが書き込み可能でない場合の不適切なエラーメッセージ

データ接続を設定し、S3 バケットが書き込み可能でない場合にパイプラインをアップロードしようとすると、Failed to store pipelines というエラーメッセージが表示されますが、有用ではありません。

回避策: データ接続の認証情報が正しいこと、および指定したバケットへの書き込みアクセス権があることを確認してください。

RHOAIENG-1207 (以前は ODH-DASHBOARD-1758 として記録されていた問題) - OOTB カスタムサービングランタイムを数回複製するときにエラーが発生する

モデルサービングランタイムを複数回複製すると、複製が失敗し、Serving runtime name "<name>" already exists というエラーメッセージが表示されます。

回避策: metadata.name フィールドを一意の値に変更します。

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

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

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

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

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

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

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

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

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

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

回避策

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

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

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

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

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

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

RHOAIENG-432 (以前は RHODS-12928 として記録されていた問題) - サポートされていない文字を使用すると、複数のダッシュを含む Kubernetes リソース名が生成される場合がある

リソースを作成し、サポートされていない文字を名前として指定すると、各スペースがダッシュに置き換えられ、他のサポートされていない文字が削除されるため、リソース名が無効になる可能性があります。

RHOAIENG-226 (以前は RHODS-12432 として記録されていた問題) - notebook-culler ConfigMap を削除すると、ダッシュボードに Permission Denied と表示される

redhat-ods-applications namespace で notebook-controller-culler-config ConfigMap を削除すると、OpenShift AI ダッシュボードの Cluster Settings ページへの変更を保存できなくなります。保存操作は、HTTP request has failed というエラーで失敗します。

回避策

cluster-admin 権限を持つユーザーとして以下の手順を実行します。

oc クライアントを使用して、クラスターにログインします。

次のコマンドを入力して、redhat-ods-applications アプリケーション namespace の OdhDashboardConfig カスタムリソースを更新します。

$ oc patch OdhDashboardConfig odh-dashboard-config -n redhat-ods-applications --type=merge -p '{"spec": {"dashboardConfig": {"notebookController.enabled": true}}}'

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

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

回避策

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

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

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

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

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

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

RHODS-12986 - Red Hat OpenShift AI 2.8 へのアップグレード後に発生する可能性のある調整エラー

Red Hat OpenShift AI 2.8 にアップグレードした後、Red Hat OpenShift AI Operator Pod ログおよび DataScienceCluster カスタムリソース (CR) 条件に調整エラーが表示される場合があります。

エラーの例

2023-11-23T09:45:37Z    ERROR    Reconciler error    {"controller": "datasciencecluster", "controllerGroup": "datasciencecluster.opendatahub.io", "controllerKind": "DataScienceCluster", "DataScienceCluster": {"name":"default-dsc"}, "namespace": "", "name": "default-dsc", "reconcileID": "0c1a32ca-7ffd-4310-8259-f6baabf3c868", "error": "1 error occurred:\n\t* Deployment.apps \"rhods-prometheus-operator\" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{\"app.kubernetes.io/part-of\":\"model-mesh\", \"app.opendatahub.io/model-mesh\":\"true\", \"k8s-app\":\"rhods-prometheus-operator\"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable\n\n"}

回避策: Red Hat OpenShift AI Operator Pod を再起動します。

RHODS-12798 - Pod が "unable to init seccomp" エラーで失敗する

seccomp メモリーリークを引き起こす既知のカーネルバグが原因で、Pod は Running のステータスではなく CreateContainerError ステータスまたは Pending ステータスで失敗します。Pod が失敗した namespace でイベントをチェックするか、oc describe pod コマンドを実行すると、以下のエラーが表示されます。

runc create failed: unable to start container process: unable to init seccomp: error loading seccomp filter into kernel: error loading seccomp filter: errno 524

回避策: Red Hat ナレッジベースのソリューション記事 Pods failing with error loading seccomp filter into kernel: errno 524 in OpenShift 4 の説明に従って、net.core.bpf_jit_limit の値を増やします。

KUBEFLOW-177 - OAuth-proxy で転送されないアプリケーションのベアラートークン

アプリケーションの内部認証メカニズムがベアラートークンに基づいている場合、アプリケーションをカスタムワークベンチイメージとして使用できません。OAuth プロキシー設定によりヘッダーからベアラートークンが削除されるため、アプリケーションは適切に動作できなくなります。

RHOAIENG-642 (以前は RHODS-12903 として文書化されていました) - 正常に送信された Elyra パイプラインが実行に失敗する

プライベート TLS 証明書を使用し、Elyra で生成されたパイプラインをデータサイエンスパイプラインサーバーに対して正常に送信すると、パイプラインステップの実行に失敗し、次のエラーメッセージが表示されます。

File "/opt/app-root/src/bootstrapper.py", line 747, in <module>
main()
File "/opt/app-root/src/bootstrapper.py", line 730, in main
Actions
...
WARNING: Retrying (Retry (total-4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPSConnection obj
In this situation, a new runtime image should be created, to include the correct CA bundle, as well as all the required pip packages.

回避策: この問題を解決するには、Red Hat サポートにお問い合わせください。

RHOAIENG-1666 (以前は DATA-SCIENCE-PIPELINES-OPERATOR-349 として記録されていた問題) - Import Pipeline ボタンが早期にアクセス可能になる

データサイエンスプロジェクトに属するワークベンチにパイプラインをインポートすると、パイプラインサーバーが使用可能になる前に Import Pipeline ボタンがアクセス可能になります。

回避策: ブラウザーのページを更新して、パイプラインを再度インポートします。

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

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

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

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

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

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

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

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

名前を編集する
説明を編集する
既存の環境変数のキーおよび値を編集、追加、または削除する

回避策: ワークベンチを手動で再起動します。

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

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

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

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

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

回避策

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

OpenShift AI ダッシュボードの左側のメニューで、Settings Cluster settings をクリックします。
Cluster Settings ページが開きます。
Usage data collection セクションで、Allow collection of usage data の選択を解除します。
Save changes をクリックします。

KUBEFLOW-157: OpenShift AI ダッシュボードからすでにログアウトしている場合、JupyterLab からのログアウトが機能しない

JupyterLab からログアウトする前に OpenShift AI ダッシュボードからログアウトすると、JupyterLab から正常にログアウトされません。たとえば、Jupyter ノートブックの URL がわかっている場合は、これをブラウザーで再度開くことができます。

回避策: OpenShift AI ダッシュボードからログアウトする前に、JupyterLab からログアウトします。

RHODS-9789: データベース名またはユーザー名フィールドにダッシュがあるカスタムデータベースが含まれる場合はパイプラインサーバーは起動に失敗する

カスタムデータベースを使用するパイプラインサーバーを作成する場合、dbname フィールドまたは username フィールドに設定した値にダッシュが含まれていると、パイプラインサーバーは起動に失敗します。

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

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

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

ワークベンチの作成プロセス中に、Kubernetes ロールバインディングの作成に関連する Error creating workbench メッセージがユーザーに表示されます。
前述のエラーメッセージにもかかわらず、OpenShift AI は引き続きワークベンチを作成します。ただし、このエラーメッセージは、ユーザーがワークベンチを使用して Elyra データサイエンスパイプラインを実行できないことを意味します。
ユーザーがワークベンチを使用して Elyra パイプラインを実行しようとすると、Jupyter は初期化の失敗を説明する Error making request メッセージを表示します。
回避策
管理者権限を持つユーザー (プロジェクト所有者など) は、編集権限を持つユーザーに代わってワークベンチを作成する必要があります。その後、そのユーザーはワークベンチを使用して Elyra パイプラインを実行できるようになります。

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

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

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

RHODS-7718: ダッシュボード権限のないユーザーは、実行中のノートブックとワークベンチを無期限に使用し続けることができる

Red Hat OpenShift AI 管理者がユーザーの権限を取り消しても、引き続きユーザーは実行中のノートブックとワークベンチを無期限で使用できます。

回避策: OpenShift AI 管理者がユーザーの権限を取り消す場合、管理者はそのユーザーに対して実行中のノートブックとワークベンチも停止する必要があります。

RHOAIENG-1157 (以前は RHODS-6955 として記録されていた問題) - ワークベンチを編集しようとするとエラーが発生することがある

ワークベンチの編集時に、以下のようなエラーが発生する可能性があります。

Error creating workbench
Operation cannot be fulfilled on notebooks.kubeflow.org "workbench-name": the object has been modified; please apply your changes to the latest version and try again

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

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

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

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

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

Request invalid against a username that does not exist.

回避策: 該当するユーザーにダッシュボードへのログインを依頼します。

RHODS-5906: NVIDIA GPU Operator に OpenShift 4.11.12 との互換性がない

OpenShift 4.11.12 クラスターで GPU ノードをプロビジョニングすると、nvidia-driver-daemonset Pod が CrashLoopBackOff 状態で停止します。NVIDIA GPU Operator は OpenShift 4.11.9 および 4.11.13 と互換性があります。さらに、OpenShift AI のインストールに必要な OpenShift の最小バージョンは 4.12 です。

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

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

RHODS-5543: NVIDIA GPU Operator を使用すると、Node Autoscaler によって必要以上のノードが作成される

使用可能なリソースが不十分なために Pod をスケジュールできないと、Node Autoscaler は新しいノードを作成します。新しく作成されたノードが関連する GPU ワークロードを受け取るまで、遅延があります。したがって、Pod をスケジュールすることはできず、Node Autoscaler は、ノードの 1 つが GPU ワークロードを受け取る準備ができるまで、追加の新しいノードを継続的に作成します。この問題の詳細は、Red Hat ナレッジベースのソリューション記事 NVIDIA GPU Operator を使用すると、Node Autoscaler によって必要以上のノードが作成されるを参照してください。

回避策: machineset.spec.template.spec.metadata で cluster-api/accelerator ラベルを適用します。これにより、オートスケーラーは、GPU ドライバーがデプロイされるまで、これらのノードを準備ができていないと見なします。

RHOAIENG-1149 (以前に文書化された RHODS-5216) - アプリケーション起動メニューに OpenShift Cluster Manager へのリンクが誤って表示される

Red Hat OpenShift AI は、アプリケーションランチャーメニューから OpenShift Cluster Manager へのリンクを誤って表示します。このリンクをクリックすると、URL が無効なため、"Page Not Found" エラーが発生します。

RHOAIENG-1137 (以前は RHODS-5251 として記録されていた問題) - ノートブックサーバー管理ページに権限へのアクセスを失ったユーザーが表示される

以前に Jupyter でノートブックサーバーを起動したユーザーがその権限を失った場合 (たとえば、OpenShift AI 管理者がユーザーのグループ設定を変更したり、許可されたグループからユーザーを削除したりした場合)、管理者は引き続きサーバーの Administration ページでユーザーのノートブックサーバーを表示します。その結果、管理者は、権限が取り消されたユーザーに属するノートブックサーバーを再起動できるようになります。

RHODS-4799: Tensorboard を表示するには手動の手順が必要

TensorFlow または PyTorch ノートブックイメージを使用しており、TensorBoard を使用してデータを表示する場合に、ノートブック環境に環境変数を追加して、独自のコードで使用する環境変数をインポートするといった手作業の手順が必要です。

回避策: ノートブックサーバーを起動するときに、次のコードを使用して TENSORBOARD_PROXY_URL 環境変数の値を設定し、OpenShift AI ユーザー ID を使用します。

import os
os.environ["TENSORBOARD_PROXY_URL"]= os.environ["NB_PREFIX"]+"/proxy/6006/"

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

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

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

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

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

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

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

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

Error loading components
HTTP request failed

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

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

OpenShift AI インターフェイスで、Start a notebook server ページに、oneAPI AI Analytics Toolkit ノートブックイメージに含まれる JupyterLab パッケージおよび Notebook パッケージの誤ったバージョン番号が表示されます。このページには、このイメージが使用する Python バージョンの誤った値が表示される場合もあります。

回避策: oneAPI AI Analytics Toolkit ノートブックサーバーを起動するときに、ノートブックセルで !pip list コマンドを実行すると、ノートブックサーバーにインストールされている Python パッケージと、所有しているパッケージのバージョンを確認できます。

RHODS-2956: ノートブックインスタンスの作成時にエラーが発生する可能性がある

Jupyter でノートブックインスタンスを作成すると、Directory not found エラーが断続的に表示されます。このエラーメッセージは、Dismiss をクリックすると無視できます。

RHOAING-1147 (以前は RHODS-2881 として記録されていた問題) - ダッシュボード上のアクションが明確に表示されない

無効になったアプリケーションのライセンスを再検証し、無効になったアプリケーションのタイルを削除するダッシュボードアクションは、ユーザーには明確に表示されません。これらのアクションは、ユーザーがアプリケーションタイルの Disabled ラベルをクリックすると表示されます。その結果、意図したワークフローがユーザーにとって明確でない場合があります。

RHOAIENG-1134 (以前は RHODS-2879 として記録されていた問題) - ライセンス再検証アクションが不必要に表示される

無効になったアプリケーションのライセンスを再検証するダッシュボードアクションは、ライセンス検証またはアクティベーションシステムがないアプリケーションでは不要に表示されます。さらに、ユーザーが再検証できないライセンスを再検証しようとしても、アクションを完了できない理由を示すフィードバックが表示されません。

RHOAIENG-2305 (以前は RHODS-2650 として記録されていた問題) - Pachyderm のデプロイ中にエラーが発生することがある

Pachyderm Operator のインスタンスを作成すると、Webhook エラーが断続的に表示され、作成プロセスを正常に開始できなくなります。Webhook エラーは、Pachyderm Operator がヘルスチェックに失敗して再起動したか、Operator プロセスがコンテナーに割り当てられたメモリー制限を超えてメモリー不足 (OOM) キルをトリガーしたことを示しています。

回避策: エラーが表示されなくなるまで、Pachyderm インスタンスの作成プロセスを繰り返します。

RHODS-2096 - IBM Watson Studio は OpenShift AI で利用できない

IBM Watson Studio は、OpenShift AI が OpenShift Dedicated 4.9 以降にインストールされている場合は使用できません。これは、OpenShift Dedicated のこれらのバージョンと互換性がないためです。OpenShift Dedicated 4.9 以降で Watson Studio を手動で設定する方法は、Marketplace サポートにお問い合わせください。

第6章既知の問題

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links

第6章 既知の問題

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links

第6章既知の問題