搜索
支持控制台（Console）开发人员开始试用联系人

第 8 章 已知问题

download PDF

本节介绍了 Red Hat OpenShift AI 2.10.1 中已知的问题，以及任何已知问题的方法。

RHOAIENG-8819 - ibm-granite/granite-3b-code-instruct 模型无法在单模式服务平台上部署

如果您试图使用 vLLM ServingRuntime for KServe 运行时在单模式服务平台上部署 ibm-granite/granite-3b-code-instruct 模型，则模型会失败，并显示的错误。 

ValueError: Head size 80 is not supported by FlashAttention. Supported head sizes are: [32, 64, 96, 128, 160, 192, 224, 256]
临时解决方案

将以下参数添加到 vLLM ServingRuntime for KServe 运行时的 ServingRuntime 规格的 env 部分。 

VLLM_ATTENTION_BACKEND=XFORMERS

使用自定义镜像创建的 RHOAIENG-855 3- Workbench 显示 !Deleted 标记

如果您在 OpenShift Container Platform 集群上禁用内部镜像 registry，然后使用镜像标签导入的自定义镜像工作台，例如： quay.io/my-wb-images/my-image:tag，则会在 Data Science Projects 页面的 Workbenches 选项卡中显示一个 !Deleted 标志。如果停止工作台，则无法重启它。

  • OpenShift Container Platform 集群管理员可以确认集群中是否启用了内部镜像 registry。

  • OpenShift AI admin 用户可以使用标签表示法确认自定义镜像是否已导入。

    临时解决方案
    使用 SHA 摘要导入自定义镜像，如 quay.io/my-repo/my-image@sha256:xxxxxxxxxxxxx，然后使用自定义镜像创建工作台。

当将 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
临时解决方案

  1. 删除现有的 AppWrapper CRD。 

    $ oc delete crd appwrappers.workload.codeflare.dev

  2. 安装 AppWrapper CRD 的最新版本。 

    $ oc apply -f https://raw.githubusercontent.com/project-codeflare/codeflare-operator/main/config/crd/crd-appwrapper.yml

RHOAIENG-8218 - 无法登录到在没有 OCP 内部镜像 registry 的 OpenShift 4.15 集群上创建的工作台

当您在没有启用 OpenShift Container Platform 内部镜像 registry 的 OpenShift 4.15 集群上创建工作台时，工作台可以成功启动，但您无法登录到它。

授权服务器遇到意外条件，阻止它满足请求 错误。

临时解决方案

为您创建的每个工作台在 OCP 中手动创建服务帐户令牌 secret。

  1. 在 OpenShift CLI 中，使用以下命令来创建服务帐户令牌 secret。将 <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
—---
  2. 刷新浏览器中的页面并登录到您的工作台。

有关使用 Web 控制台创建服务帐户令牌 secret 的详情，请参考 创建服务帐户令牌 secret。

在 KServe 中的查询过程中，RHOAIENG- 7947- Model serving 会失败

如果您最初安装 ModelMesh 组件并启用多模式服务平台，但稍后安装 KServe 组件并启用单模式服务平台，则对在单模式服务平台上部署的模型的统计请求可能会失败。在这些情况下，inference 请求会返回 404 - Not Found 错误，odh-model-controller 部署对象的日志会显示 Reconciler 错误消息。

临时解决方案
在 OpenShift Container Platform 中，重启 odh-model-controller 部署对象。

RHOAIENG-788 7- Kue 无法监控 RayCluster 或 PyTorchJob 资源

当您创建启用了所有组件的 DataScienceCluster CR 时，Kueue 组件会在 Ray 组件和 training Operator 组件之前安装。因此，Kueue 组件不会监控 RayCluster 或 PyTorchJob 资源。

临时解决方案

执行以下操作之一：

  • 安装 Ray 组件和 Training Operator 组件后，重启 redhat-ods-applications 命名空间中的 Kueue 控制器 pod。
  • 或者，编辑 DataScienceCluster CR，将 kueue 组件标记为 Removed，等待 Kueue 被卸载，然后再次将 kueue 组件标记为 Managed。

RHOAIENG-7716 - Pipeline 条件组状态不会更新

当您运行具有条件组的管道（如 dsl.lf ）时，UI 会显示组的 Running 状态，即使管道执行完成后也是如此。

临时解决方案

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

  1. 在 OpenShift AI 仪表板中点 Data Science Pipelines Runs。
  2. 在 Project 下拉菜单中选择您的数据科学项目。
  3. 在 Runs 选项卡中，点您要检查状态的管道运行。

  4. 展开 condition 组，再单击子任务。

    此时会显示包含子任务信息的面板

  5. 在面板中点 Task details 选项卡。

    Status 字段显示子任务的正确状态。

升级后，RHOAIENG-7346 - 分布式工作负载不再从现有管道运行

升级到 OpenShift AI 2.10 后，如果仅在管道中创建集群，则分布式工作负载不再从现有管道运行。管道停止工作，Ray 集群不会启动。

临时解决方案
在分布式工作负载的每个现有管道的 Python 代码中，将 cluster.wait_ready 替换为 time.sleep (180)，并重新编译代码。导入管道并调度管道运行。

RHOAIENG -1197- 因为管道运行创建页面中的 End date picker 在 Linux 上使用 Firefox 时，无法创建管道

当您尝试使用 Linux 上的 Firefox 创建带有调度的重复运行的管道时，启用 End Date 参数会导致日期和时间 不是 Number (NaN)值，您无法创建管道。

临时解决方案
在 Linux 上，使用不同的受支持的浏览器来创建调度的管道运行。如需有关 OpenShift AI 支持的浏览器的更多信息，请参阅 Red Hat OpenShift AI 支持的配置。

RHOAIENG-7209 - 设置默认管道 root 时显示错误

当使用 Data Science Pipelines SDK 或 OpenShift AI 用户界面设置默认管道 root 时，会出现类似如下的错误： 

F0513 18:25:25.155794 28 main.go:49] failed to execute component: Failed to open bucket "mlpipeline": Failed to retrieve credentials for bucket mlpipeline: Failed to get Bucket credentials from secret name="" namespace="dspa1": resource name may not be empty44
临时解决方案
无。

rhoAIENG-6711 - ODH-model-controller 覆盖 ServiceMeshMemberRoll 对象中的 spec.memberSelectors 字段

如果您使用 ServiceMeshMemberRoll 资源的 spec.memberSelectors 字段将项目或命名空间添加到 ServiceMeshMemberRoll 资源中，ODH-model-controller 会覆盖字段。

临时解决方案

使用 spec.members 字段明确将命名空间添加到 ServiceMeshMemberRoll 资源中，如下例所示： 

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

RHOAIENG-6649 - 在模型服务器上查看未定义外部路由的模型时显示错误

如果您使用仪表板在未启用外部路由的模型服务器上部署模型，则在模型创建过程中可能会显示 t.components is undefined 错误消息。

临时解决方案
无。

在升级过程中查看 Model Serving 页面时显示 RHOAIENG-66 46- An 错误

如果您在升级 OpenShift AI 的过程中尝试使用仪表板部署模型，则可能会显示 t.status is undefined 错误信息。

临时解决方案
等待升级的 OpenShift AI Operator 就绪，然后在浏览器中刷新页面。

当使用带有 TensorFlow 2024.1 笔记本镜像的 Elyra JupyterLab 扩展时，无法配置 RHOAIENG-64 86- Pod 标签、注解和容限。

当将 Elyra JupyterLab 扩展与 TensorFlow 2024.1 笔记本镜像搭配使用时，您无法从执行的管道配置 pod 标签、注解或容限。这是因为依赖项与 kfp 和 tf2onnx 软件包冲突。

临时解决方案

如果您在完成工作后使用 TensorFlow 2024.1 笔记本镜像，请将分配的工作台笔记本镜像改为 Standard Data Science 2024.1 笔记本镜像。

在 Elyra JupyterLab 扩展中的 Pipeline 属性 选项卡中，将 Tensorflow 运行时镜像设置为管道节点的默认运行时镜像，以及每个管道节点的相关 pod 标签、注解或容限。

RHOAIENG-6435 分布式工作负载资源没有包括在项目指标中

当您点 Distributed Workloads Metrics > Project metrics 并查看 Requested resources 部分时，Requested by all projects 值当前排除了尚未接受到队列的分布式工作负载的资源。

临时解决方案
无。

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

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

临时解决方案
无。

在管道组件中将 pip_index_urls 设置为包含端口号和路径的 URL 后，RHOAIENG -6376- Pipeline 运行会失败

当您创建管道，并将组件的 pip_index_urls 值设置为包含端口号和路径的 URL 时，编译管道代码，然后创建管道运行会导致以下错误： 

ValueError: Invalid IPv6 URL
临时解决方案
  1. 仅使用 protocol://hostname 创建一个新的 pip 服务器，并使用新的服务器更新组件的 pip_index_urls 值。
  2. 重新编译管道代码。
  3. 创建新的管道运行。

RHOAIENG-481 2- 分布式工作负载指标排除 GPU 指标

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

临时解决方案
无。

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

Data Science Pipelines (DSP) 2.0 包含 Argo 工作流的安装。OpenShift AI 不支持将这个 Argo 工作流安装的用户使用。要使用 DSP 2.0 安装或升级 OpenShift AI，请确保集群中没有 Argo 工作流安装。如需更多信息，请参阅启用 Data Science Pipelines 2.0。

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

RHOAIENG-3913 - Red Hat OpenShift AI Operator 错误地显示 False 的 Degraded 条件并带有错误

如果您在 OpenShift AI Operator 使用的 DataScienceCluster (DSC)对象中启用了 KServe 组件，但没有安装依赖的 Red Hat OpenShift Service Mesh 和 Red Hat OpenShift Serverless Operator，则 DSC 对象中的 kserveReady 条件会显示 KServe 未就绪。但是，Degraded 条件会错误地显示 False 的值。

临时解决方案
安装 Red Hat OpenShift Serverless 和 Red Hat OpenShift Service Mesh Operator，然后重新创建 DSC。

RHOAIENG-4240 - 作业无法在不安全的环境中提交到 Ray 集群

当在不安全的 OpenShift 集群中从笔记本运行分布式数据科学工作负载时，可能会显示 ConnectionError: Failed to connect to Ray 错误消息。

临时解决方案
在笔记本的 ClusterConfiguration 部分中，将 openshift_oauth 选项设置为 True。

RHOAIENG-3981 - 在不安全的环境中，等待 Ray 集群就绪的功能卡住

当在不安全的 OpenShift 集群中从笔记本运行分布式数据科学工作负载时，在继续(cluster.wait_ready （)）之前，等待 Ray 集群就绪的功能也会卡住。

临时解决方案

执行以下操作之一：

  • 在笔记本的 ClusterConfiguration 部分中，将 openshift_oauth 选项设置为 True。
  • 您可以通过打开 Ray 集群 Route URL，而不是使用 cluster.wait_ready （） 功能，来手动检查 Ray 集群可用性。当 URL 上有 Ray 仪表板时，集群就已就绪。

RHOAIENG-3025 - OVMS 预期目录布局与 KServe StoragePuller 布局冲突

当您使用 OpenVINO 模型服务器(OVMS)运行时在单模式服务平台（使用 KServe）上部署模型时，OVMS 预期的目录布局与 KServe 使用的目录布局之间不匹配。具体来说，OVMS 要求模型文件位于 /< mnt>/models/1/ 目录中，而 KServe 则将它们放置在 /< mnt>/models/ 目录中。

临时解决方案

执行以下操作：

  1. 在 S3 兼容存储桶中，将您的模型文件放在名为 1/ 的目录中，例如 /< s3_storage_bucket>/models/1/<model_files >。

  2. 要使用 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/ 目录中拉取模型文件。

KServe 上的 RHOAIENG-30 18- OVMS 在仪表板中不会公开正确的端点

当您使用 OpenVINO 模型服务器(OVMS)运行时在单模式服务平台上部署模型时，部署模型的 Inference endpoint 字段中显示的 URL 不完整。

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

当项目中同时存在安全和常规模型服务器时，RHOAIENG-2759 - Model 部署会失败

当您在一个服务器使用令牌身份验证的项目中创建第二个模型服务器时，另一个服务器不使用身份验证，第二个模型的部署可能无法启动。

临时解决方案
无。

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

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

临时解决方案
无。

当集群中未启用 UWM 时，RHOAIENG -2585- UI 不会显示错误/警告

如果集群中 禁用了 用户工作负载监控(UWM)，Red Hat OpenShift AI 无法正确警告用户。对于模型指标的正确功能，UWM 是必需的。

临时解决方案
手动确保在集群中启用了 UWM，如 为用户定义的项目启用监控 中所述。

在以表单更改 Serving Runtime 时，RHOAIENG-255 5- Model 框架选择器不会重置

当您使用 Deploy model 对话框在单模式服务平台上部署模型时，如果您选择运行时和支持的框架，则不会重置现有的框架选择。这意味着，可以使用所选运行时不支持的框架部署模型。

临时解决方案
在部署模型时，如果您更改了所选运行时，请再次点击 Select a framework 列表并选择受支持的框架。

与 KServe 相同的项目中的 RHOAIENG-2468 - Services 可能无法在 OpenShift 中访问

如果您在一个数据科学项目中部署了一个非 OpenShift AI 服务，其中包含在单模式服务平台（使用 KServe）上部署的模型，则服务的可访问性可能会受 OpenShift 集群的网络配置的影响。特别是当您使用 OVN-Kubernetes 网络插件 和主机网络命名空间时。

临时解决方案

执行以下操作之一：

  • 在另一个数据科学项目中部署服务，它们不包含在单模式服务平台上部署的模型。或者，在另一个 OpenShift 项目中部署该服务。

  • 在服务的数据科学项目中，添加一个 网络策略 来接受应用程序 pod 的入口流量，如下例所示： 

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-to-myapp
spec:
  podSelector:
    matchLabels:
      app: myapp
  ingress:
     - {}

RHOAIENG-231 2- 在 code-server workbench 中导入 numpy 失败

在您的 code-server workbench 中导入 numpy 会失败。

临时解决方案

  1. 在您的 code-server workbench 中，从 Activity 栏中选择 菜单图标( The Menu icon )> View > Command && amp; 来打开 Command Dashboards。

    在 Firefox 中，您可以使用 F1 键盘快捷键打开命令面板。

  2. 输入 python：s。
  3. 从下拉列表中选择 Python: Select interpreter 操作。
  4. 在 Select Interpreter 对话框中，选择 Enter interpreter path…。
  5. 输入 /opt/app-root/bin/python3 作为解释器路径，然后按 Enter 键。
  6. 从下拉列表中选择新的 Python 解释器。
  7. 确认新解释器(app-root)显示在 Status bar 中。如果工作台已停止并再次启动，则所选解释器会保留，因此只有每个工作台都需要执行一次临时解决方案。

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

在模型指标屏幕的 Endpoint 性能 选项卡中，如果您将 Refresh interval 设为 15 秒，且 Time range 设为 1 小时，则图形结果会持续更改。

临时解决方案
无。

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

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

临时解决方案
无。

RHOAIENG-191 9- Model Serving 页面无法在部署后获取或报告模型路由 URL

从 OpenShift AI 仪表板部署模型时，系统会显示以下警告信息，而模型的 Status 列则表示成功并显示 OK/green checkmark。 

Failed to get endpoint for this deployed model. routes.rout.openshift.io"<model_name>" not found
临时解决方案
刷新浏览器页面。

RHOAIENG-880 - 默认管道服务帐户无法创建 Ray 集群

您不能使用默认管道服务帐户创建 Ray 集群。

临时解决方案

通过在管道代码中添加以下行，使用 CodeFlare SDK 进行身份验证： 

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

如果您的集群使用自签名证书，请在 TokenAuthentication 参数列表中包含 ca-cert-path=<path >。

RHOAIENG-404 - No Components Found 页面随机显示，而不是 OpenShift AI 仪表板中的 Enabled 页面

当您访问 Red Hat OpenShift AI 仪表板时，可能会出现 No Components Found 页面。

临时解决方案
刷新浏览器页面。

RHOAIENG-234 - 在 Insecured 集群中查看 VSCode 中的 .ipynb 文件

当您在不安全的集群中的 Google Chrome 上使用 code-server 笔记本镜像时，您无法查看 .ipynb 文件。

临时解决方案
使用其他浏览器。

当尝试增加没有连接到工作台的持久性卷(PV)的大小时，会显示 RHOAIENG-1 128- Unclear 错误消息

当尝试增加没有连接到工作台的持久性卷(PV)的大小时，会显示不清晰的错误消息。

临时解决方案
在尝试增大大小前，验证您的 PV 是否已连接到工作台。

RHOAIENG-545 - 在 JupyterLab 管道编辑器中指定通用默认节点运行时镜像

当您在 JupyterLab IDE 管道编辑器中编辑 Elyra 管道，并且点 PIPELINE PROPERTIES 选项卡，并滚动到 Generic Node Defaults 部分，并编辑 Runtime Image 字段。

临时解决方案
为每个节点明确定义所需的运行时镜像。单击 NODE PROPERTIES 选项卡，然后在 Runtime Image 字段中指定所需的镜像。

RHOAIENG-497 - removing DSCI 结果 in OpenShift Service Mesh CR Being Deleted Without User Notification

如果您删除了 DSCInitialization 资源，则也会删除 OpenShift Service Mesh CR。不显示警告消息。

临时解决方案
无。

如果所需资源不可用，则不应分配 RHOAIENG-282 - Workload

有时，即使单个机器实例没有足够的资源来成功置备 RayCluster，工作负载也会被分配。AppWrapper CRD 处于 Running 状态，相关的 pod 无限期处于 Pending 状态。

临时解决方案
在集群中添加额外资源。

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

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

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

当模型刚刚启动时，RHOAIENG-130 - Synchronization 问题

当 KServe 容器的状态为 Ready 时，即使 TGIS 容器未就绪，也会接受请求。

临时解决方案
等待几秒钟，以确保所有初始化都已完成，并且 TGIS 容器实际上已就绪，然后查看请求输出。

在显示为就绪后的几秒内无法查询 RHOAIENG-311 5- Model

使用多模式服务平台部署的模型可能会没有响应查询，尽管仪表板中显示为 Ready。在查询模型端点时，您可能会看到 "Application is not available" 响应。

临时解决方案
等待 30-40 秒，然后在浏览器中刷新页面。

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-1204 （以前称为 ODH-DASHBOARD-1771）- Pipeline 步骤初始化过程中的 JavaScript 错误

有时 ，管道运行详情页面 会在运行时停止工作。

临时解决方案
刷新页面。

RHOAIENG-1203 （以前称为 ODH-DASHBOARD-1781）- Missing tools for Started Run status

数据科学管道运行有时不会显示显示状态图标的工具提示文本。

临时解决方案
如需更多信息，请参阅管道运行 详情页面 并查看运行输出。

RHOAIENG-1201 （以前称为 ODH-DASHBOARD-1908）- 无法创建具有空环境变量的工作台

在创建工作台时，如果您点 Add 变量，但没有从列表中选择环境变量类型，则无法创建工作台。该字段未标记为必填，不显示任何错误消息。

临时解决方案
无。

RHOAIENG-1196 （以前称为 ODH-DASHBOARD-2140）- 仪表板中显示的软件包版本与已安装的版本不匹配

仪表板可能会显示软件包的不准确版本号，如 JupyterLab 和 Notebook。如果手动更新软件包，则软件包版本号在镜像中可能会有所不同。

临时解决方案

要查找软件包的 true 版本号，请运行 pip list 命令并搜索软件包名称，如下例所示： 

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

RHOAIENG-582 （以前称为 ODH-DASHBOARD-1335）- Rename Edit permission to Contributor

术语 Edit 并不准确：

  • 对于大多数 资源，具有 Edit 权限的用户只能编辑资源，它们也可以创建和删除资源。
  • 具有 Edit 权限的用户无法编辑项目。

术语 Contributor 更准确地描述了此权限所授予的操作。

临时解决方案
无。

RHOAIENG-432 （以前称为 RHODS-12928）- 使用不支持的字符可以生成具有多个短划线的 Kubernetes 资源名称

当您创建资源并在名称中指定不支持的字符时，每个空格都会被一个短划线替换，并删除了其他不支持的字符，这会导致无效的资源名称。

临时解决方案
无。

RHOAIENG-226 （以前记录在 RHODS-12432）- 删除 notebook-culler ConfigMap 会导致 Permission Denied on dashboard

如果您删除 redhat-ods-applications 命名空间中的 notebook-controller-culler-config ConfigMap，则无法将更改保存到 OpenShift AI 仪表板上的 Cluster Settings 页面。save 操作失败，并显示 HTTP 请求失败的错误。

临时解决方案

以具有 cluster-admin 权限的用户身份登录的步骤：

  1. 使用 oc 客户端登录到集群。

  2. 输入以下命令更新 redhat-ods-applications 应用程序命名空间中的 OdhDashboardConfig 自定义资源： 

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

RHOAIENG-133 - Existing workbench 在笔记本重启后无法运行 Elyra 管道

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

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

在带有自签名证书的集群中 RHOAIENG-52 - Token 身份验证失败

如果您使用自签名证书，且您在笔记本或 Python 脚本中使用 Python codeflare-sdk，作为管道的一部分，令牌身份验证将失败。

临时解决方案
无。

RHOAIENG -11- Separately installed instance of CodeFlare Operator 不支持

在 Red Hat OpenShift AI 中，CodeFlare Operator 包含在基本产品中，而不是包含在单独的 Operator 中。不支持将 CodeFlare Operator 实例单独安装红帽或社区。

临时解决方案
删除任何已安装的 CodeFlare Operator，并安装和配置 Red Hat OpenShift AI，如红帽知识库解决方案 如何从数据科学集群中的单独安装的 CodeFlare Operator 中迁移。

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

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

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

临时解决方案
无。

RHOAIENG-5646 （以前称为 NOTEBOOKS-218）- 从 Elyra 管道编辑器保存的数据科学管道引用不兼容的运行时

当您在 Elyra 管道编辑器中保存管道时，格式为 OpenShift AI 版本 1.31 或更早版本，管道会引用与 OpenShift AI 版本 1.32 或更高版本不兼容的运行时。

因此，在将 OpenShift AI 升级到 1.32 或更高版本后，管道无法运行。

临时解决方案
升级到 OpenShift AI 升级到 1.32 或更高版本后，再次选择相关的运行时镜像。

NoteBOOKS-210 - 笔记本无法在 Jupyter 中导出为 PDF 文件

当您将笔记本导出为 Jupyter 中的 PDF 文件时，导出过程会失败并显示错误。

临时解决方案
无。

RHOAIENG-1210 （以前称为 ODH-DASHBOARD-1699）- Workbench 不会自动重启所有配置更改

当您编辑工作台的配置设置时，会显示警告信息，表示工作台将在其配置设置进行任何更改时重启。这个警告有误导，因为在以下情况下，工作台不会自动重启：

  • 编辑名称
  • 编辑描述
  • 编辑、添加或删除现有环境变量的键和值
临时解决方案
手动重启工作台。

RHOAIENG-1208 （以前称为 ODH-DASHBOARD-1741）- 无法创建名称以数字开头的工作台

如果您试图创建名称以数字开头的工作台，则工作台不会启动。

临时解决方案
删除工作台，并使用以字母开头的名称创建一个新工作台。

RHOAIENG-1205 （以前称为 RHODS-11791）- 升级后启用了使用数据收集

如果您之前已取消选择 Allow collection usage data 选项（即 disabled），当您升级 OpenShift AI 时此选项就会变为选择（已启用）。

临时解决方案

手动重置 Allow collection usage data 选项。要做到这一点，请执行以下操作：

  1. 在 OpenShift AI 仪表板中，在左侧菜单中点击 Settings Cluster settings。

    此时会打开 Cluster Settings 页面。

  2. 在 Usage data collection 部分中，取消选择 Allow collection of usage data。
  3. 点 Save Changes。

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

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

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

如果 RHODS-9789 - Pipeline 服务器包含在数据库名称或用户名字段中包含短划线的自定义数据库，则 RHODS-9789- Pipeline 服务器无法启动

当您创建一个使用自定义数据库的管道服务器时，如果您为 dbname 字段或 username 字段设置的值中包含短划线，则管道服务器无法启动。

临时解决方案
编辑管道服务器，从受影响的字段中省略短划线。

RHOAIENG-580 （以前称为 RHODS-9412）- 如果具有编辑权限的用户创建了工作台，Elyra pipeline 将无法运行

如果被授予项目的编辑权限的用户创建了项目工作台，该用户会看到以下行为：

  • 在工作台创建过程中，用户会看到与创建 Kubernetes 角色绑定相关的 Error create 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 可能会遇到从容器 registry 中拉取容器镜像的问题。如果发生错误，相关的 pod 会进入 ImagePullBackOff 状态。在工作台创建过程中，如果发生 ImagePullBackOff 错误，则不会显示适当的信息。

临时解决方案
检查事件日志以了解有关 ImagePullBackOff 错误的更多信息。为此，可在其启动时点工作台状态。

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

仪表板的笔记本管理页面显示属于 OpenShift 中用户组和 admin 组的用户。但是，如果管理员尝试代表从未登录到仪表板的用户启动笔记本服务器，服务器创建过程会失败，并显示以下出错信息： 

Request invalid against a username that does not exist.
临时解决方案
请求相关的用户登录到仪表板。

RHODS-57 63- 在笔记本选择过程中显示的软件包版本

启动一个笔记本服务器 页面显示 Anaconda 笔记本镜像的版本号。

临时解决方案
无。

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 驱动程序。

RHOAIENG-1149 （以前称为 RHODS-5216）） - 应用程序启动程序菜单错误地显示到 OpenShift Cluster Manager 的链接

Red Hat OpenShift AI 错误地从应用程序启动程序显示 OpenShift Cluster Manager 的链接。点此链接会导致 "Page Not Found" 错误，因为 URL 无效。

临时解决方案
无。

RHOAIENG-1137 （以前称为 RHODS-5251）） - 笔记本服务器管理页面显示丢失权限的用户

如果以前在 Jupyter 中启动笔记本服务器的用户丢失了其权限，例如，如果 OpenShift AI 管理员更改了用户组设置，或者将用户从允许的组中删除，则管理员将继续查看服务器管理页面中用户的笔记本服务器。因此，管理员可以重启属于撤销权限的用户的笔记本服务器。

临时解决方案
无。

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

当用户有 TensorFlow 或 PyTorchbook 镜像，并希望使用 TensorBoard 显示数据，需要手动步骤在笔记本环境中包含环境变量，并在您的代码中导入这些变量。

临时解决方案

当您启动笔记本服务器时，使用以下代码来设置 TENSORBOARD_PROXY_URL 环境变量的值，以使用您的 OpenShift AI 用户 ID。 

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

RHODS-47 18- Intel® oneAPI AI Analytics Toolkits 快速开始引用不存在的示例笔记本

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

临时解决方案
无。

RHODS-4627 - 负责验证 Anaconda 专业版许可证的 CronJob 已暂停，且不会每天运行

负责验证 Anaconda Professional Edition 许可证的 CronJob 由 OpenShift AI 操作器自动暂停。因此，CronJob 不会每日运行。另外，当 Anaconda 专业版的许可证过期时，Anaconda 专业版不会在 OpenShift AI 控制面板中显示禁用。

临时解决方案
无。

RHOAIENG-1141 （以前称为 RHODS-4502）- 仪表板中的 NVIDIA GPU Operator 标题显示不必要的按钮

安装 NVIDIA GPU Operator 后，Jupyter 中会自动提供 GPU。因此，在 Explore 页面中的 NVIDIA GPU Operator 标题中 Enable 按钮是多余的。另外，点 Enable 按钮会将 NVIDIA GPU Operator 标题移到 Enabled 页面，即使 Operator 没有被安装。

临时解决方案
无。

RHOAIENG-1135 （以前称为 RHODS-3985）- 仪表板不会在 ISV operator 卸载后显示 Enabled 页面内容

卸载 ISV 操作器后，仪表板的 Enabled 页没有显示任何内容。相反，会显示以下错误： 

Error loading components
HTTP request failed
临时解决方案
等待 30-40 秒，然后在浏览器中刷新页面。

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

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

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

RHODS- 2956- Error 在创建 notebook 实例时可能会出现

在 Jupyter 中创建 notebook 实例时，有时会出现未找到目录错误。单击 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

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

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

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.