第7章既知の問題

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

RHAIENG-1139 - 複数の namespace に同じ名前の LlamaStackDistribution をデプロイできない

異なる namespace に同じ名前の LlamaStackDistribution リソースを 2 つ作成すると、2 番目のリソースの ReplicaSet は Llama Stack Pod の起動に失敗します。Llama Stack Operator は、namespace 全体で重複した名前が使用されている場合、セキュリティー制約を正しく割り当てません。

回避策: 各 namespace 内の各 LlamaStackDistribution に一意の名前を使用します。たとえば、プロジェクト名を含めるか、llama-stack-distribution-209342 などの接尾辞を追加します。

RHAIENG-1624 - 非接続クラスターでの Embeddings API タイムアウト

非接続クラスターでは、デフォルトの Llama Stack 配布イメージに含まれるデフォルトの組み込みモデル (ibm-granite/granite-embedding-125m-english) を使用すると、Embeddings API への呼び出しがタイムアウトになる可能性があります。

回避策

組み込みモデルをオフラインで使用するには、LlamaStackDistribution カスタムリソースに次の環境変数を追加します。

- name: SENTENCE_TRANSFORMERS_HOME
  value: /opt/app-root/src/.cache/huggingface/hub
- name: HF_HUB_OFFLINE
  value: "1"
- name: TRANSFORMERS_OFFLINE
  value: "1"
- name: HF_DATASETS_OFFLINE
  value: "1"

- name: SENTENCE_TRANSFORMERS_HOME
  value: /opt/app-root/src/.cache/huggingface/hub
- name: HF_HUB_OFFLINE
  value: "1"
- name: TRANSFORMERS_OFFLINE
  value: "1"
- name: HF_DATASETS_OFFLINE
  value: "1"

Copy to Clipboard

Toggle word wrap

RHOAIENG-34923 - JupyterLab からパイプラインを実行するときにランタイム設定が見つからない

プロジェクトの最初のアクティブなワークベンチからパイプラインを実行すると、ランタイム設定が Elyra パイプラインエディターに表示されないことがあります。これは、ワークベンチの初回セッション時に、設定が正常に入力されないために発生します。

回避策: ワークベンチを再起動します。再起動後、ランタイム設定がパイプライン実行に使用できるようになります。

RHAIENG-35055 - OpenShift AI 2.24 からのアップグレード後にモデルカタログの初期化に失敗する

OpenShift AI 2.24 からアップグレードした後、モデルカタログの初期化とロードに失敗する可能性があります。OpenShift AI ダッシュボードに、Request access to model catalog エラーが表示されます。

回避策

次のコマンドを実行して、既存のモデルカタログ ConfigMap とデプロイメントを削除します。

oc delete configmap model-catalog-sources -n rhoai-model-registries --ignore-not-found
$ oc delete deployment model-catalog -n rhoai-model-registries --ignore-not-found

$ oc delete configmap model-catalog-sources -n rhoai-model-registries --ignore-not-found
$ oc delete deployment model-catalog -n rhoai-model-registries --ignore-not-found

Copy to Clipboard

Toggle word wrap

RHAIENG-35529 - 外部 Argo Workflows 使用時の Data Science Pipelines Operator のリコンシリエーション問題

既存の外部 Argo Workflows インストールを削除する前に、組み込み Argo Workflows コントローラー (argoWorkflowsControllers: Managed) を有効にすると、ワークフローコントローラーが起動に失敗し、Data Science Pipelines Operator (DSPO) がカスタムリソースを正しくリコンサイルしない可能性があります。

回避策: 組み込み Argo Workflows コントローラーを有効にする前に、クラスターから既存の外部 Argo Workflows インスタンスを削除します。

RHAIENG-36756 - 接続が存在しない場合、モデルのデプロイメント時に既存のクラスターストレージのオプションが表示されない

データ接続が定義されていないプロジェクトでモデルデプロイメントを作成すると、永続ボリューム要求 (PVC) が使用可能な場合でも、既存のクラスターストレージ オプションは表示されません。その結果、モデルの保存に既存の PVC を選択できません。

回避策: プロジェクト内に URI タイプの接続を少なくとも 1 つ作成します。その後、既存のクラスターストレージ オプションが使用可能になります。

RHOAIENG-36817 - Model サーバーのサイズが small に設定されていると推論サーバーが失敗する

ダッシュボード経由で推論サービスを作成する際に、Model サーバーサイズとして small を選択すると、後続の推論要求が失敗します。その結果、推論サービス自体のデプロイメントは成功しますが、推論要求はタイムアウトエラーで失敗します。

回避策: この問題を解決するには、ドロップダウンから Model サーバーのサイズとして large を選択します。

RHOAIENG-33995 - Phi および Mistral モデルの推論サービスのデプロイメントが失敗する

openshift-container-platform 4.19 を搭載した IBM Power クラスターで vLLM ランタイムを使用して Phi および Mistral モデルの推論サービスを作成すると、CPU バックエンドに関連するエラーが原因で失敗します。その結果、これらのモデルのデプロイメントが影響を受け、推論サービスの作成が失敗します。

回避策: この問題を解決するには、CPU および Phi モデルに対して有効になっている場合は、サービスランタイムで sliding_window メカニズムを無効にします。スライディングウィンドウは現在 V1 ではサポートされていません。

RHOAIENG-33795 - IBM Z 上の Triton Inference Server の gRPC エンドポイント検証には手動 Route 作成が必要である

gRPC エンドポイントを使用して Triton Inference Server を検証する場合、Route が自動的に作成されません。これは、Operator が現在、デフォルトで REST のみのエッジ終了ルートを作成するために発生します。

回避策

この問題を解決するには、IBM Z 上の Triton Inference Server の gRPC エンドポイント検証用に手動でルートを作成する必要があります。

モデルデプロイメント Pod が起動して実行されている場合、次の内容を含む YAML ファイルでエッジ終了 Route オブジェクトを定義します。

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: <grpc-route-name>                  # e.g. triton-grpc
  namespace: <model-deployment-namespace>  # namespace where your model is deployed
  labels:
    inferenceservice-name: <inference-service-name>
  annotations:
    haproxy.router.openshift.io/timeout: 30s
spec:
  host: <custom-hostname>                  # e.g. triton-grpc.<apps-domain>
  to:
    kind: Service
    name: <service-name>                   # name of the predictor service (e.g. triton-predictor)
    weight: 100
  port:
    targetPort: grpc                       # must match the gRPC port exposed by the service
  tls:
    termination: edge
  wildcardPolicy: None

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: <grpc-route-name>                  # e.g. triton-grpc
  namespace: <model-deployment-namespace>  # namespace where your model is deployed
  labels:
    inferenceservice-name: <inference-service-name>
  annotations:
    haproxy.router.openshift.io/timeout: 30s
spec:
  host: <custom-hostname>                  # e.g. triton-grpc.<apps-domain>
  to:
    kind: Service
    name: <service-name>                   # name of the predictor service (e.g. triton-predictor)
    weight: 100
  port:
    targetPort: grpc                       # must match the gRPC port exposed by the service
  tls:
    termination: edge
  wildcardPolicy: None

Copy to Clipboard

Toggle word wrap

Route オブジェクトを作成します。
```
oc apply -f <route-file-name>.yaml
```
```
oc apply -f <route-file-name>.yaml
```
Copy to Clipboard Toggle word wrap

推論要求を送信するには、次のコマンドを入力します。

grpcurl -cacert <ca_cert_file>\ 
  -protoset triton_desc.pb \
  -d '{
    "model_name": "<model_name>",
    "inputs": [
      {
        "name": "<input_tensor_name>",
        "shape": [<shape>],
        "datatype": "<data_type>",
        "contents": {
          "<datatype_specific_contents>": [<input_data_values>]
        }
      }
    ],
    "outputs": [
      {
        "name": "<output_tensor_name>"
      }
    ]
  }' \
  <grpc_route_host>:443 \
  inference.GRPCInferenceService/ModelInfer

grpcurl -cacert <ca_cert_file>\


  -protoset triton_desc.pb \
  -d '{
    "model_name": "<model_name>",
    "inputs": [
      {
        "name": "<input_tensor_name>",
        "shape": [<shape>],
        "datatype": "<data_type>",
        "contents": {
          "<datatype_specific_contents>": [<input_data_values>]
        }
      }
    ],
    "outputs": [
      {
        "name": "<output_tensor_name>"
      }
    ]
  }' \
  <grpc_route_host>:443 \
  inference.GRPCInferenceService/ModelInfer

Copy to Clipboard

Toggle word wrap

1: <ca_cert_file> は、クラスタールーターの CA 証明書へのパスです (例: router-ca.crt)。

注記

<triton_protoset_file> は protobuf 記述子ファイルとしてコンパイルされます。protoc -I. --descriptor_set_out=triton_desc.pb --include_imports grpc_service.proto として生成できます。

triton-inference-service GitHub ページから grpc_service.proto および model_config.proto ファイルをダウンロードします。

RHOAIENG-33697 - ステータスが "Started" でない限り、モデルを編集または削除できない

NVIDIA NIM または単一モデルサービングプラットフォームにモデルをデプロイする場合、Starting または Pending 状態のモデルではアクションメニューの Edit および Delete オプションは使用できません。これらのオプションは、モデルが正常にデプロイされた後にのみ使用可能になります。

回避策: モデルを変更したり削除したりするには、モデルが Started 状態になるまで待機します。

RHOAIENG-33645 - LM-Eval Tier1 テストに失敗する

古いバージョンの trustyai-service-operator を使用している場合、ジョブの実行時に confirm_run_unsafe_code が引数として渡されないため、LM-Eval Tier1 テストが失敗する可能性があります。

回避策: 最新バージョンの trustyai-service-operator を使用しており、AllowCodeExecution が有効になっていることを確認してください。

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

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

回避策

この問題を解決するには、model-registry-operator-controller-manager デプロイメントのリコンシリエーションをトリガーする必要があります。デプロイメントに opendatahub.io/managed='true' アノテーションを追加すると、これが実現され、正しいメモリー制限が適用されます。次のコマンドを実行してアノテーションを追加できます。

oc annotate deployment model-registry-operator-controller-manager -n redhat-ods-applications opendatahub.io/managed='true' --overwrite

oc annotate deployment model-registry-operator-controller-manager -n redhat-ods-applications opendatahub.io/managed='true' --overwrite

Copy to Clipboard

Toggle word wrap

注記

このコマンドは model-registry-operator-controller-manager デプロイメント内のカスタム値を上書きします。カスタムデプロイメント値の詳細は、コンポーネントデプロイメントリソースのカスタマイズを参照してください。

デプロイメントが更新され、メモリー制限が 128Mi から 256Mi に増加すると、コンテナーのメモリー使用量が安定し、再起動ループが停止します。

RHOAIENG-31238 - DSCInitialization の作成時に新しい監視スタックが有効になった

DSCInitialization リソースを削除し、OpenShift AI コンソールフォームビューを使用して新しいリソースを作成すると、テクノロジープレビューの可観測性スタックが有効になります。その結果、DSCInitialization リソースを再作成するときに、不要な可観測性スタックがデプロイメントされることになります。

回避策

この問題を解決するには、フォームビューを使用して DSCInitiliazation リソースを再作成するときに、"metrics" と "traces" フィールドを手動で削除します。

テクノロジープレビューの監視スタックを使用する場合、これは必要ありません。

RHOAIENG-32145 - OpenShift バージョン 4.17 より前のバージョンで Llama Stack Operator のデプロイメントに失敗する

4.17 より前のバージョンを実行している OpenShift クラスターに OpenShift AI をインストールすると、統合された Llama Stack Operator (llamastackoperator) のデプロイに失敗する可能性があります。

Llama Stack Operator には Kubernetes バージョン 1.32 以降が必要ですが、OpenShift 4.15 では Kubernetes 1.28 が使用されます。このバージョンの違いにより、Kubernetes 1.32 で導入され、未対応の選択肢付きフィールドが原因で、LlamaStackDistribution カスタムリソース定義 (CRD) を適用するときにスキーマ検証が失敗する可能性があります。

回避策: バージョン 4.17 以降を実行している OpenShift クラスターに OpenShift AI をインストールします。

RHOAIENG-32242 - OpenShift バージョン 4.15 および 4.16 の NetworkPolicies の作成に失敗する

バージョン 4.15 または 4.16 を実行している OpenShift クラスターに OpenShift AI をインストールすると、特定の NetworkPolicy リソースのデプロイメントが失敗する可能性があります。これは、llamastackoperator または関連コンポーネントが redhat-ods-applications などの保護された namespace に NetworkPolicy を作成しようとしたときに発生する可能性があります。このリクエストは、アドミッション webhook networkpolicies-validation.managed.openshift.io によってブロックされる可能性があります。これにより、cluster-admin ユーザーであっても、特定の namespace とリソースへの変更が制限されます。この制限は、self-managed 環境と Red Hat 管理の OpenShift 環境の両方に適用されます。

回避策: バージョン 4.17 以降を実行している OpenShift クラスターに OpenShift AI をデプロイします。webhook の制限が適用されているクラスターの場合は、OpenShift 管理者または Red Hat サポートに連絡して、代わりのデプロイメントパターン、または影響を受ける namespace に対して承認されている変更が何かを判断してください。

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

IBM Z クラスターで vLLM ランタイムを使用して推論サービスを作成しようとすると、ValueError: 'aimv2' is already used by a Transformers config, pick another name エラーが発生して失敗します。

回避策: なし。

RHOAIENG-29731 - OpenShift 4.19 を使用した IBM Power クラスターで推論サービスの作成が失敗する

OpenShift Container Platform バージョン 4.19 上の IBM Power クラスターで vLLM ランタイムを使用して推論サービスを作成しようとすると、Non-Uniform Memory Access (NUMA) に関連するエラーが原因で失敗します。

回避策: 推論サービスを作成するときに、環境変数 VLLM_CPU_OMP_THREADS_BIND を all に設定します。

RHOAIENG-29292 - IBM Z 上で、使用状況統計ディレクトリーへのアクセスが原因で、vLLM が権限エラーをログに記録する

IBM Z アーキテクチャーで vLLM を実行すると、推論サービスは正常に起動しますが、使用状況統計レポートに関連するバックグラウンドスレッドにエラーが記録されます。これは、サービスがアクセス権限のない制限された場所 (/.config) に使用状況データを書き込もうとするために発生します。

以下のエラーがログに記録されます。

Exception in thread Thread-2 (_report_usage_worker):
Traceback (most recent call last):
 ...
PermissionError: [Error 13] Permission denied: '/.config'

Exception in thread Thread-2 (_report_usage_worker):
Traceback (most recent call last):
 ...
PermissionError: [Error 13] Permission denied: '/.config'

Copy to Clipboard

Toggle word wrap

回避策: このエラーを防止し、使用状況統計のロギングを抑制するには、推論サービスのデプロイメントで VLLM_NO_USAGE_STATS=1 環境変数を設定します。これにより、使用状況の自動レポートが無効になり、システムディレクトリーへの書き込み時に権限の問題が発生するのを回避できます。

RHOAIENG-28910 - 2.16 から 2.19 以降にアップグレードすると、Unmanaged 状態の KServe リソースが削除される

OpenShift AI 2.16 から 2.25 へのアップグレード中に、関連する KServe 関連リソースから所有者参照が完全に削除される前に、FeatureTracker カスタムリソース (CR) が削除されます。その結果、Red Hat OpenShift AI Operator によって最初に Managed 状態で作成され、その後 DataScienceCluster (DSC) カスタムリソース (CR) で Unmanaged に変更されたリソースが、意図せず削除される可能性があります。この問題により、リソースが手動で復元されるまでモデルサービング機能が停止する可能性があります。

次のリソースは、2.16 で Unmanaged に変更された場合、2.25 で削除される可能性があります。

Expand

種類	Namespace	名前
`KnativeServing`	`knative-serving`	`knative-serving`
`ServiceMeshMember`	`knative-serving`	`default`
`Gateway`	`istio-system`	`kserve-local-gateway`
`Gateway`	`knative-serving`	`knative-ingress-gateway`
`Gateway`	`knative-serving`	`knative-local-gateway`

回避策

OpenShift AI 2.16 から 2.25 にすでにアップグレードしている場合は、次のいずれかの操作を実行してください。

既存のバックアップがある場合は、FeatureTracker CR への所有者参照なしで削除されたリソースを手動で再作成します。
既存のバックアップがない場合は、Operator を使用して、削除されたリソースを再作成できます。
1. 再作成済みのリソースをバックアップします。
2. DSC で、spec.components.kserve.serving.managementState を Managed に設定し、変更を保存して、Operator がリソースを再作成できるようにします。
  Operator がリソースを再作成するまで待機します。
3. DSC で、spec.components.kserve.serving.managementState を Unmanaged に戻し、変更を保存します。
4. 再作成された KnativeServing、ServiceMeshMember、および Gateway CR リソースに以前のカスタムの変更を再適用します。

まだアップグレードしていない場合は、この問題を防ぐために、アップグレードする前に次の操作を実行してください。

DSC で、spec.components.kserve.serving.managementState を Unmanaged に設定します。
上記の表にリストされている影響を受ける KnativeServing、ServiceMeshMember、および Gateway リソースごとに、FeatureTracker の所有者参照を削除して CR を編集します。この編集により、FeatureTracker に対するリソースの依存関係が削除され、アップグレードプロセス中にリソースが削除されなくなります。

RHOAIENG-24545 - 初回の起動後にランタイムイメージがワークベンチに存在しない

ランタイムイメージのリストには、namespace で最初に実行されているワークベンチインスタンスが適切に入力されないため、Elyra パイプラインエディターで選択できるイメージが表示されません。

回避策: ワークベンチを再起動します。ワークベンチを再起動すると、ランタイムイメージのリストがワークベンチと Elyra パイプラインエディターの選択ボックスの両方に表示されます。

RHOAIENG-24786 - 非接続環境で Authorino Operator をテクニカルプレビューから Stable にアップグレードすると失敗する

非接続環境では、Red Hat Authorino Operator をテクニカルプレビューから Stable にアップグレードすると authconfig-migrator-qqttz Pod でエラーが発生して失敗します。

回避策

Red Hat Authorino Operator を tech-preview-v1 更新チャネルの最新バージョン (v1.1.2) に更新します。

次のスクリプトを実行します。

delete the migrator job
run the migrator script

#!/bin/bash
set -xe

# delete the migrator job
oc delete job -n openshift-operators authconfig-migrator || true

# run the migrator script
authconfigs=$(oc get authconfigs -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name' --no-headers)

if [[ ! -z "${authconfigs}" ]]; then
    while IFS=" " read -r namespace name; do
        oc get authconfig "$name" -n "$namespace" -o yaml > "/tmp/${name}.${namespace}.authconfig.yaml"
        oc apply -f "/tmp/${name}.${namespace}.authconfig.yaml"
    done <<< "${authconfigs}"
fi

oc patch crds authconfigs.authorino.kuadrant.io --type=merge --subresource status --patch '{"status":{"storedVersions":["v1beta2"]}}'

Copy to Clipboard

Toggle word wrap

Red Hat Authorino Operator サブスクリプションを更新して、stable 更新チャネルを使用します。
Authorino 1.2.1 の更新オプションを選択します。

RHOAIENG-20209 - 要求されたリソースがしきい値を超えても警告メッセージが表示されない

Distributed workloads Project metrics をクリックし、Requested resources セクションを表示すると、チャートには要求されたリソースの値と各リソースの合計共有クォータ値 (CPU および メモリー) が表示されます。ただし、Requested by all projects の値が、そのリソースの Warning threshold の値を超えると、予想される警告メッセージは表示されません。

回避策: なし。

SRVKS-1301 (以前は RHOAIENG-18590 として文書化されていました) - KServe を無効化にしてから有効化すると、KnativeServing リソースが失敗する

DataScienceCluster で kserve コンポーネントを無効にしてから有効にすると、KnativeServing リソースが失敗する可能性があります。

回避策

Knative に関連するすべての ValidatingWebhookConfiguration および MutatingWebhookConfiguration Webhook を削除します。

Webhook を取得します。

oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative

oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative

Copy to Clipboard

Toggle word wrap

KServe が無効になっていることを確認します。

Webhook を取得します。

oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative

oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative

Copy to Clipboard

Toggle word wrap

Webhook を削除します。
KServe を有効にします。
KServe Pod が正常に生成され、knative-serving namespace 内の Pod がアクティブで動作していることを確認します。

RHOAIENG-16247 - OpenShift AI ダッシュボードから実行を開始すると、Elyra パイプラインの実行出力が上書きされる

Elyra からパイプラインを作成して実行すると、パイプラインの実行によって生成された出力が、オブジェクトストレージのフォルダー bucket-name/pipeline-name-timestamp に保存されます。

Elyra からパイプラインを作成し、OpenShift AI ダッシュボードからパイプラインの実行を開始すると、タイムスタンプ値が更新されません。これにより、パイプラインの実行によって、同じパイプラインの以前のパイプライン実行によって作成されたファイルが上書きされる可能性があります。

この問題は、OpenShift AI ダッシュボードを使用してコンパイルおよびインポートされたパイプラインには影響しません。これは、オブジェクトストレージで使用されるフォルダーに runid が常に追加されるためです。データサイエンスパイプラインで使用されるストレージの場所の詳細は、データサイエンスパイプラインでのデータの保存を参照してください。

回避策: Elyra パイプラインにファイルを保存する場合は、パイプライン実行ごとに異なるサブフォルダー名を使用します。

OCPBUGS-49422 - 非接続環境内の AMD GPU および AMD ROCm ワークベンチイメージがサポートされていない

この OpenShift AI リリースでは、非接続環境内の AMD GPU および AMD ROCm ワークベンチイメージはサポートされていません。AMD GPU Operator をインストールするには、GPU ドライバーのコンパイルに必要な依存関係を取得するのにインターネットアクセスが必要であるためです。

回避策: なし。

RHOAIENG-12516 - fast リリースが意図しないリリースチャネルで利用できる

ストリームイメージ配信プロセスに関する既知の問題により、現在、fast リリースは stable や stable-x.y などの意図しないストリーミングチャネルで利用可能です。正確なリリースタイプ、チャネル、サポートライフサイクル情報は、Red Hat OpenShift AI Self-Managed ライフサイクルページの ライフサイクル日付 表を参照してください。

回避策: なし。

RHOAIENG-8294 - OpenShift AI 2.8 をバージョン 2.10 以降にアップグレードするときに CodeFlare エラーが発生する

OpenShift AI 2.8 をバージョン 2.10 以降にアップグレードしようとすると、AppWrapper カスタムリソース定義 (CRD) バージョンとの不一致により、CodeFlare コンポーネントに関する次のエラーメッセージが表示されます。

ReconcileCompletedWithComponentErrors DataScienceCluster resource reconciled with component errors: 1 error occurred: * CustomResourceDefinition.apiextensions.k8s.io "appwrappers.workload.codeflare.dev" is invalid: status.storedVersions[0]: Invalid value: "v1beta1": must appear in spec.versions

ReconcileCompletedWithComponentErrors DataScienceCluster resource reconciled with component errors: 1 error occurred: * CustomResourceDefinition.apiextensions.k8s.io "appwrappers.workload.codeflare.dev" is invalid: status.storedVersions[0]: Invalid value: "v1beta1": must appear in spec.versions

Copy to Clipboard

Toggle word wrap

回避策

既存の AppWrapper CRD を削除します。
```
oc delete crd appwrappers.workload.codeflare.dev
```
```
$ oc delete crd appwrappers.workload.codeflare.dev
```
Copy to Clipboard Toggle word wrap

約 20 秒待ってから、次の例に示すように、新しい AppWrapper CRD が自動的に適用されることを確認します。

oc get crd appwrappers.workload.codeflare.dev

$ oc get crd appwrappers.workload.codeflare.dev
NAME                                 CREATED AT
appwrappers.workload.codeflare.dev   2024-11-22T18:35:04Z

Copy to Clipboard

Toggle word wrap

RHOAIENG-7716 - パイプライン条件グループのステータスが更新されない

ループ (dsl.ParallelFor) または条件グループ (dsl.lf) を含むパイプラインを実行すると、パイプラインの実行が完了した後でも、UI にループとグループの実行ステータスが表示されます。

回避策

アクティブな子タスクがないことを確認することで、パイプラインがまだ実行中かどうかを確認できます。

OpenShift AI ダッシュボードから、Data Science Pipelines Runs をクリックします。
Project リストから、データサイエンスプロジェクトをクリックします。
Runs タブから、ステータスを確認する必要があるパイプライン実行をクリックします。
条件グループを展開し、子タスクをクリックします。
子タスクに関する情報を含むパネルが表示されます。
パネルで、Task 詳細タブをクリックします。
Status フィールドに、子タスクの正しいステータスが表示されます。

RHOAIENG-6409 - 実行が成功しても、パイプラインログに Cannot save parameter というエラーが表示される

Data Science Pipelines 2.0 を使用してパイプラインを複数回実行すると、パイプラインの実行が成功してもパイプラインログに Cannot save parameter エラーが表示されます。これらのエラーは無視しても問題ありません。

回避策: なし。

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

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

回避策: なし。

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

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

回避策: なし。

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

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

回避策: なし。

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

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

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

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-133 - 既存のワークベンチは、ワークベンチの再起動後に Elyra パイプラインを実行できない

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

回避策

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

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

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

Copy to Clipboard

Toggle word wrap

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

回避策: なし。

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

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

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

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

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

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

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

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

Request invalid against a username that does not exist.

Request invalid against a username that does not exist.

Copy to Clipboard

Toggle word wrap

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

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 ドライバーがデプロイされるまで、これらのノードを準備ができていないと見なします。

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/"

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

Copy to Clipboard

Toggle word wrap

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

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

回避策: なし。

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

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

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

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

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

回避策: なし。

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

IBM Watson Studio は、OpenShift AI が OpenShift Dedicated 4.9 以降にインストールされている場合は使用できません。これは、OpenShift Dedicated のこれらのバージョンと互換性がないためです。

回避策: OpenShift Dedicated 4.9 以降で Watson Studio を手動で設定する場合のサポートについては、Red Hat カスタマーポータルにお問い合わせください。

第7章既知の問題

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第7章 既知の問題

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第7章既知の問題