第 7 章已知问题

这部分论述了 Red Hat OpenShift AI 中已知的问题，以及这些问题的已知方法。

使用硬件配置集时，RHOAIENG-35623 - Model 部署会失败

使用硬件配置集的模型部署失败，因为 Red Hat OpenShift AI Operator 在手动创建 InferenceService 资源时，不会将来自硬件配置集 的容限、nodeSelector 或 标识符 注入到底层的 InferenceService 中。因此，模型部署 pod 无法调度到适当的节点，部署无法进入就绪状态。使用相同的硬件配置集的工作台将继续成功部署。

临时解决方案: 运行脚本，从硬件配置集手动将 容限、nodeSelector 或 标识符 注入到底层的 InferenceService 中，如使用硬件配置集时模型部署失败的知识库解决方案中所述。

RHOAIENG-33995 - 部署 Phi 和 Mistral 模型的 inference 服务失败

由于与 CPU 后端相关的错误，在带有 {openshift-platform-url} 4.19 的 IBM Power 集群中使用 vLLM 运行时为 Phi 和 Mistral 模型创建 inference 服务会失败。因此，部署这些模型会受到影响，从而导致服务创建失败。

临时解决方案: 要解决这个问题，如果为 CPU 和 Phi 模型启用了，在服务运行时中禁用 sliding_window 机制。V1 目前不支持 sliding 窗口。

RHOAIENG-33914 - LM-Eval Tier2 任务测试失败

LM-Eval Tier2 任务测试可能存在一些故障，因为 Massive Multitask Language Understanding Symbol Replacement (MMLUSR)任务会被破坏，如果您使用旧版本的 trustyai-service-operator。

临时解决方案: 确保安装了最新版本的 trustyai-service-operator。

RHOAIENG-33795 - 为 IBM Z 上的 Triton Inference Server 的 gRPC 端点验证需要手动路由创建

当验证带有 gRPC 端点的 Triton Inference Server 时，路由不会自动创建。这是因为 Operator 目前默认为 REST 创建边缘终止路由。

临时解决方案

要解决这个问题，在 IBM Z 上为 Triton Inference Server 的 gRPC 端点验证需要手动路由创建。

当模型部署 pod 启动并运行时，在 YAML 文件中定义带有以下内容的 edge-terminated 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

要发送 inference 请求，请输入以下命令：

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-3369 7- Unable to Edit or Delete model，除非状态为"Started"

当您在 NVIDIA NIM 或单型号服务平台上部署模型时，操作菜单中的 Edit 和 Delete 选项不适用于 Starting 或 Pending 状态中的模型。这些选项仅在成功部署模型后可用。

临时解决方案: 等待模型处于 Started 状态，以便进行任何更改或删除模型。

RHOAIENG-336 45- LM-Eval Tier1 测试失败

LM-Eval Tier1 测试可能会失败，因为在运行作业时不会作为参数传递 confirm_run_unsafe_code，如果您使用 trustyai-service-operator 的旧版本。

临时解决方案: 确保您使用最新版本的 trustyai-service-operator，并且启用了 AllowCodeExecution。

RHOAIENG-32942 - 当管道存储设置为 Kubernetes 时，Elyra 管道会失败

当管道存储配置为使用 Kubernetes 时，Elyra 需要 REST API 不支持的相等性(eq)过滤器。此模式中只支持子字符串过滤器。因此，通过 Elyra 从工作台创建并提交的管道无法成功运行。提交失败并显示以下错误：

Invalid input error: Filter eq is not implemented for Kubernetes pipeline store.

Invalid input error: Filter eq is not implemented for Kubernetes pipeline store.

Copy to Clipboard

Toggle word wrap

临时解决方案

将管道服务器配置为使用数据库而不是 Kubernetes 来存储管道：

在创建管道服务器时，将管道存储设置为 数据库。
如果服务器已创建好，请通过将 .spec.pipelineStore 设置为 database 来更新 DataSciencePipelinesApplication 自定义资源。这会触发重新创建 dspa pod。

将管道存储切换到 数据库后，可以从工作台成功提交 Elyra 管道。

RHOAIENG-32897 - Pipelines 使用 Kubernetes API 定义，无效的 platformSpec 不会出现在 UI 或运行时

使用 Kubernetes API 定义的管道版本包含空或无效的 spec.platformSpec 字段（如 {} 或缺少 kubernetes 键），系统会错误地将字段确认为管道规格。因此，REST API 省略 pipelineSpec，这可防止在 UI 中显示管道版本并运行。

临时解决方案: 从 PipelineVersion 对象中删除 spec.platformSpec 字段。删除字段后，管道版本会在 UI 中正确显示，REST API 会如预期返回 pipelineSpec。

RHOAIENG-31386 - 使用 authenticationRef部署 Inference Service 时出错

当在外部指标下部署带有 authenticationRef 的 InferenceService 时，在第一个 oc apply 后会删除 authenticationRef 字段。

临时解决方案: 重新应用资源以保留字段。

RHOAIENG-30493 - 在启用了 Kueue 的项目中创建工作台时出错

当使用仪表板在启用了 Kue-enabled 的项目中创建工作台时，如果集群中禁用了 Kueue，或者所选硬件配置集没有与 LocalQueue 关联，则创建会失败。在这种情况下，无法引用所需的 LocalQueue，准入 Webhook 验证会失败，并显示以下出错信息：

Error creating workbench
admission webhook "kubeflow-kueuelabels-validator.opendatahub.io" denied the request: Kueue label validation failed: missing required label "kueue.x-k8s.io/queue-name"

Error creating workbench
admission webhook "kubeflow-kueuelabels-validator.opendatahub.io" denied the request: Kueue label validation failed: missing required label "kueue.x-k8s.io/queue-name"

Copy to Clipboard

Toggle word wrap

临时解决方案

以具有 cluster-admin 权限的用户在集群中启用 Kueue 和 hardware 配置集：

使用 oc 客户端登录到集群。
运行以下命令在 redhat-ods-applications 命名空间中修补 OdhDashboardConfig 自定义资源：

oc patch OdhDashboardConfig odh-dashboard-config -n redhat-ods-applications --type=merge -p '{"spec": {"dashboardConfig": {"disableKueue": false, "disableHardwareProfiles": false}}}'

oc patch OdhDashboardConfig odh-dashboard-config -n redhat-ods-applications --type=merge -p '{"spec": {"dashboardConfig": {"disableKueue": false, "disableHardwareProfiles": false}}}'

Copy to Clipboard

Toggle word wrap

创建 DSCInitialization 时启用 RHOAIENG -31238- New observability 堆栈

当您删除 DSCInitialization 资源并使用 OpenShift AI 控制台表单视图创建新资源时，它启用了技术预览可观察性堆栈。这会导致在重新创建 DSCInitialization 资源时部署不需要的可观察性堆栈。

临时解决方案

要解决这个问题，请使用表单视图重新创建 DSCInitiliazation 资源时手动删除 "metrics" 和 "traces" 字段。

如果要使用技术预览可观察性堆栈，则不需要此项。

RHOAIENG-321 45- Llama Stack Operator 部署失败（在早于 4.17 的 OpenShift 版本中）

当在 4.17 之前的版本上安装 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 - Failure，为 OpenShift 版本 4.15 和 4.16 创建 NetworkPolicies

在运行 4.15 或 4.16 的 OpenShift 集群上安装 OpenShift AI 时，某些 NetworkPolicy 资源的部署可能会失败。当 llamastackoperator 或相关组件试图在受保护的命名空间中创建 NetworkPolicy 时（如 redhat-ods-applications ），会出现这种情况。准入 Webhook networkpolicies-validation.managed.openshift.io 可以阻止请求，这会限制对某些命名空间和资源的修改，即使 cluster-admin 用户也是如此。这个限制适用于自我管理的和由红帽管理的 OpenShift 环境。

临时解决方案: 在运行 4.17 或更高版本的 OpenShift 集群上部署 OpenShift AI。对于强制实施 webhook 限制的集群，请联络您的 OpenShift 管理员或红帽支持来确定替代部署模式或批准对受影响的命名空间的更改。

RHOAIENG-32599 - 在 IBM Z 集群上创建服务失败

当您试图在 IBM Z 集群上使用 vLLM 运行时创建 inference 服务时，会失败并显示以下错误：ValueError : 'aimv2' 已被 Transformers 配置使用，选择另一个名称。

临时解决方案: 无。

RHOAIENG-29731 - Inference 服务创建在带有 OpenShift 4.19 的 IBM Power 集群上失败

当您试图在 OpenShift Container Platform 版本 4.19 上的 IBM Power 集群上使用 vLLM 运行时创建 inference 服务时，它会失败，因为与 Non-Uniform Memory Access (NUMA)相关的错误。

临时解决方案: 当您创建 inference 服务时，请将环境变量 VLLM_CPU_OMP_THREADS_BIND 设置为 所有。

由于使用统计目录访问，RHOAIENG-29292 - vLLM 会在 IBM Z 上记录权限错误

在 IBM Z 架构上运行 vLLM 时，inference 服务可以成功启动，但在与用量统计报告相关的后台线程中记录错误。这是因为服务试图将使用量数据写入一个受限位置(/.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

临时解决方案: 要防止这个错误并阻止使用统计日志记录，请在 inference 服务部署中设置 VLLM_NO_USAGE_STATS=1 环境变量。这会禁用自动使用报告，避免在写入系统目录时的权限问题。

从 2.16 升级到 2.19 或更高版本后，RHOAIENG-289 10- Unmanaged KServe 资源会被删除

在从 OpenShift AI 2.16 升级到 1 的过程中，在所有者引用从关联的 KServe 相关资源中完全删除 FeatureTracker 自定义资源(CR)。因此，最初由 Red Hat OpenShift AI Operator 创建的资源，其状态为 Managed，之后在 DataScienceCluster (DSC)自定义资源(CR)中更改为 Unmanaged 可能会被有意删除。这个问题可能会破坏模型服务功能，直到手动恢复资源为止。

如果在 2.16 中将以下资源改为 Unmanaged，则资源可能会在 1 中删除：

Expand

Kind	Namespace	Name
`KnativeServing`	`knative-serving`	`knative-serving`
`ServiceMeshMember`	`knative-serving`	`default`
`网关`	`istio-system`	`kserve-local-gateway`
`网关`	`knative-serving`	`knative-ingress-gateway`
`网关`	`knative-serving`	`knative-local-gateway`

临时解决方案

如果您已经从 OpenShift AI 2.16 升级到 1，请执行以下操作之一：

如果您有现有的备份，请手动重新创建已删除的资源，而不引用 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 - Runtime 镜像在第一次启动后不会出现在工作台中

运行时镜像列表无法正确填充命名空间中的第一个运行工作台实例，因此 Elyra pipeline 编辑器中没有显示镜像进行选择。

临时解决方案: 重启工作台。重启工作台后，运行时镜像列表会填充工作台和 Elyra 管道编辑器的选择框。

当禁用模型注册选项时，RHOAIENG-25090 - InstructLab prerequisites-check-op 任务会失败

当您在没有选择 Add model to <model registry name> 复选框的情况下启动 LAB-tuning 运行时，InstructLab 管道启动，但 prerequisites-check-op 任务会失败，并显示 pod 日志中的以下错误：

failed: failed to resolve inputs: the resolved input parameter is null: output_model_name

failed: failed to resolve inputs: the resolved input parameter is null: output_model_name

Copy to Clipboard

Toggle word wrap

临时解决方案: 在配置 LAB-tuning 运行时，选择 Add model to <model registry name > 复选框。

当请求的资源超过阈值时，不会显示 RHOAIENG-2020 9- Warning 信息

当您点 Distributed workloads Project metrics 并查看 Requested resources 部分时，图表会显示请求的资源值以及每个资源(CPU 和内存)的总共享配额值。但是，当 Requested by all projects 值超过该资源的 Warning 阈值时，不会显示预期的警告信息。

临时解决方案: 无。

SRVKS-1301 （以前称为 RHOAIENG-18590）- KnativeServing 资源在禁用并启用 KServe 后会失败

在 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 命名空间中的 pod 是否活跃且可操作。

从 OpenShift AI 仪表板启动时，RHOAIENG-16247 - Elyra pipeline run 输出会被覆盖

当管道创建并从 Elyra 运行时，管道运行生成的输出存储在对象存储的文件夹 bucket-name/pipeline-name-timestamp 中。

当从 Elyra 创建管道并且管道运行从 OpenShift AI 仪表板启动时，不会更新时间戳值。这可能导致管道运行覆盖之前同一管道运行创建的文件。

此问题不会影响使用 OpenShift AI 仪表板编译和导入的管道，因为 runid 始终添加到对象存储中使用的文件夹中。有关数据科学管道中使用的存储位置的更多信息，请参阅使用数据科学管道存储数据。

临时解决方案: 将文件存储在 Elyra 管道中时，在每个管道运行上使用不同的子文件夹名称。

当将 OpenShift AI 2.8 升级到 2.10 或更高版本时，RHOAIENG-8294 - CodeFlare 错误

如果您试图将 OpenShift AI 2.8 升级到 2.10 或更高版本，则 CodeFlare 组件会显示以下出错信息，因为 AppWrapper 自定义资源定义(CRD)版本不匹配。

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 - Pipeline 条件组状态不会更新

当您运行具有循环(dsl.ParallelFor)或条件组(dsl.lf)的管道时，UI 会为循环和组显示一个 Running 状态，即使在管道执行完成后也是如此。

临时解决方案

您可以通过检查没有子任务保持活动状态来确认管道是否仍在运行。

在 OpenShift AI 仪表板中点 Data Science Pipelines Runs。
在 Project 列表中点击您的数据科学项目。
在 Runs 选项卡中，点您要检查状态的管道运行。
展开 condition 组，再单击子任务。
此时会显示包含子任务信息的面板
在面板中点 Task details 选项卡。
Status 字段显示子任务的正确状态。

RHOAIENG-6409 - Cannot save 参数 错误会出现在管道日志中成功运行

当您使用数据科学管道 2.0 多次运行管道时，Cannot save 参数 错误会出现在管道日志中成功运行。您可以安全地忽略这些错误。

临时解决方案: 无。

RHOAIENG-12294 （以前称为 RHOAIENG-4812））- 分布式工作负载指标排除 GPU 指标

在这个 OpenShift AI 发行版本中，分布式工作负载指标排除 GPU 指标。

临时解决方案: 无。

RHOAIENG-4570 - 现有 Argo 工作流安装与安装或升级冲突

Data Science pipelines 2.0 包含 Argo 工作流的安装。红帽不支持直接客户使用这个 Argo 工作流实例。要安装或升级带有数据科学管道 2.0 的 OpenShift AI，请确保在集群中没有 Argo 工作流安装。如需更多信息，请参阅迁移到数据科学管道 2.0。

临时解决方案: 删除现有的 Argo 工作流安装或将 datasciencepipelines 设置为 Removed，然后继续安装或升级。

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 兼容存储中的 /& lt;s3_storage_bucket>/models/1/ 目录中拉取模型文件。

RHOAIENG-3018 - OVMS on KServe 不会在仪表板中公开正确的端点

当您使用 OpenVINO Model Server (OVMS)运行时在单型号服务平台上部署模型时，部署模型的 Inference 端点 字段中的 URL 不会被完成。

临时解决方案: 要将查询发送到模型，您必须将 /v2/models/_<model-name>_/infer 字符串添加到 URL 的末尾。将 _<model-name>_ 替换为部署模型的名称。

RHOAIENG-260 2- "Average response time" 服务器指标图显示了因为 ModelMesh pod 重启导致多行

如果 ModelMesh pod 被重启，Average 响应时间 服务器指标图会显示多行。

临时解决方案: 无。

RHOAIENG-222 8- 当间隔设置为 15 秒时，性能指标图会持续变化

在模型指标屏幕的 Endpoint performance 选项卡中，如果您将 Refresh interval 设为 15 秒，并且 时间范围 设为 1 小时，图形结果会持续变化。

临时解决方案: 无。

RHOAIENG-2183 - 端点性能图可能会显示不正确的标签

在模型指标屏幕的 Endpoint performance 选项卡中，图形工具提示可能会显示不正确的标签。

临时解决方案: 无。

在 InferenceService 报告为 Loaded 后，RHOAIENG-131 - gRPC 端点没有正确响应

当生成了大量 InferenceService 实例时，Service Mesh Control Plane (SMCP)将变为无响应。InferenceService 实例的状态为 Loaded，但调用 gRPC 端点会返回错误。

临时解决方案: 编辑 ServiceMeshControlPlane 自定义资源(CR)以增加 Istio egress 和 ingress pod 的内存限值。

RHOAIENG-1619 （以前称为 DATA-SCIENCE-PIPELINES-165））- S3 存储桶不可写入时的 Poor 错误消息

当您设置数据连接时，且 S3 存储桶不可写入，而您尝试上传管道时，错误消息 Failed to store pipelines 并不有用。

临时解决方案: 验证您的数据连接凭证是否正确，并且您具有对您指定的存储桶的写权限。

RHOAIENG-1207 （以前称为 ODH-DASHBOARD-1758）- 多次复制 OOTB 自定义服务运行时错误

如果您多次重复模型保留运行时，重复会失败，并显示 Serving 运行时名称 "<name>" already exists 错误信息。

临时解决方案: 将 metadata.name 字段更改为一个唯一值。

RHOAIENG-133 - 现有工作台无法在工作台重启后运行 Elyra 管道

如果您使用 Elyra JupyterLab 扩展在 JupyterLab 中创建并运行数据科学管道，并在创建了工作台后配置管道服务器，并在工作台中指定工作台镜像后，您无法执行管道，即使重启工作台后，也无法执行管道。

临时解决方案

停止正在运行的工作台。
编辑工作台以进行小修改。例如，添加新的 dummy 环境变量，或删除现有的不必要的环境变量。保存您的更改。
重启工作台。
在 JupyterLab 左侧边栏中，单击 Runtimes。
确认选择了默认运行时。

RHODS-12798 - Pod 失败并显示 "unable to init seccomp" 错误

Pod 会失败，并显示 CreateContainerError 状态或 Pending 状态而不是 Running 状态，因为已知内核错误引入了 seccomp 内存泄漏。当您检查 pod 失败的命名空间中的事件时，或运行 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

临时解决方案: 增加 net.core.bpf_jit_limit 的值，如红帽知识库解决方案 Pod 失败，并将 seccomp 过滤器错误加载到 OpenShift 4 中的 kernel: errno 524。

KUBEFLOW-177 - Bearer 令牌来自没有由 OAuth-proxy 转发的应用程序

如果应用程序基于 bearer 令牌，则无法将应用程序用作自定义工作台镜像。OAuth-proxy 配置从标头中删除 bearer 令牌，应用程序无法正常工作。

临时解决方案: 无。

如果您已经从 OpenShift AI 仪表板注销，KUBEFLOW-157 - logging out of JupyterLab 无法正常工作

如果您在从 JupyterLab 注销前注销 OpenShift AI 仪表板，则注销 JupyterLab 将无法成功。例如，如果您知道 Jupyter 笔记本的 URL，您可以在浏览器中再次打开它。

临时解决方案: 在从 OpenShift AI 仪表板注销前，先从 JupyterLab 注销。

RHODS- 7718- 没有仪表板权限的用户可以无限期地使用其正在运行的工作台

当 Red Hat OpenShift AI 管理员撤销用户权限时，用户可以无限期地继续使用其正在运行的工作台。

临时解决方案: 当 OpenShift AI 管理员撤销用户权限时，管理员还应停止该用户的任何正在运行的工作台。

RHOAIENG-1152 （以前称为 RHODS-6356）- 对于从未登录到仪表板的用户，基本工作流创建过程会失败

仪表板的基本工作台的 Administration 页面显示属于 OpenShift 中用户组和 admin 组的用户。但是，如果管理员尝试代表永远不会登录到仪表板的用户启动基本工作台，则 basic-workbench 创建过程会失败，并显示以下出错信息：

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-554 3- 使用 NVIDIA GPU Operator 时，Node Autoscaler 创建的节点数量要多

当因为可用资源不足而无法调度 pod 时，Node Autoscaler 将创建一个新节点。在新创建的节点接收相关 GPU 工作负载前会有一个延迟。因此，pod 无法调度，Node Autoscaler 会不断创建额外的新节点，直到其中一个节点准备好接收 GPU 工作负载。有关此问题的更多信息，请参阅红帽知识库解决方案使用 NVIDIA GPU Operator 时，超过 Node Autoscaler 创建的节点数量。

临时解决方案: 在 machineset.spec.template.spec.metadata 中应用 cluster-api/accelerator 标签。这会导致自动扩展将这些节点视为未就绪，直到部署了 GPU 驱动程序。

RHODS-4799 - Tensorboard 需要手动步骤才能查看

当用户有 TensorFlow 或 PyTorch workbench 镜像，并希望使用 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-47 18- Intel® oneAPI AI Analytics Toolkits 快速开始引用不存在的示例笔记本

Intel® OneAPI AI Analytics Toolkits 快速开始（位于仪表板上的 Resources 页面中），要求用户以指令步骤的一部分加载示例笔记本，但引用相关存储库中不存在的笔记本。

临时解决方案: 无。

RHODS-3984 - Incorrect 软件包版本在笔记本选择过程中显示

在 OpenShift AI 界面中，启动笔记本服务器页面 显示 oneAPI AI Analytics Toolkit 笔记本镜像中包含的 JupyterLab 和 Notebook 软件包的不正确的版本号。该页面还可能显示此镜像使用的 Python 版本的错误值。

临时解决方案: 当您启动 oneAPI AI Analytics Toolkit 笔记本服务器时，您可以在笔记本服务器上安装哪些 Python 软件包，以及在笔记本单元中运行 !pip list 命令。

RHOAING-1147 （以前称为 RHODS-2881）- 在仪表板上的操作没有明确可见

仪表板操作重新验证禁用的应用程序许可证，并删除禁用的应用程序标题对用户没有明确可见。当用户点击应用程序标题的 Disabled 标签时，会出现这些操作。因此，预期的工作流可能对用户并不明确。

临时解决方案: 无。

RHODS-2096 - IBM Watson Studio 不在 OpenShift AI

当在 OpenShift Dedicated 4.9 或更高版本上安装 OpenShift AI 时，IBM Watson Studio 不可用，因为它与这些版本的 OpenShift Dedicated 不兼容。

临时解决方案: 联系 Marketplace 支持，以获取在 OpenShift Dedicated 4.9 及更高版本上手动配置 Watson Studio 的帮助。

RHODS-1888 - OpenShift AI hyperlink 在卸载后仍然可见

从 OpenShift Dedicated 集群卸载 OpenShift AI Add-on 时，应用程序启动程序菜单中可以看到到 OpenShift AI 界面的链接。点击此链接会导致 "Page Not Found" 错误，因为 OpenShift AI 不再可用。

临时解决方案: 无。

第 7 章已知问题

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第 7 章 已知问题

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第 7 章已知问题