Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

第 8 章 已知问题

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

RHOAIENG-1971 6- 使用控制面板无法删除 system-authenticated 用户组

安装或升级 Red Hat OpenShift AI 后，system-authenticated 用户组可能会在 Data Science 用户组 下的 Settings > User management 中显示。如果您从 Data Science 用户组中删除这个用户组 并保存更改，则组会错误地添加。

临时解决方案

要删除 system-authenticated 用户组，请从 OdhDashboardConfig 自定义资源中删除 groupsConfig 键：

  1. 以集群管理员身份登录 OpenShift 控制台。
  2. 在 Administrator 视角中，点 Administration CustomResourceDefinitions。
  3. 搜索 OdhDashboardConfig，然后选择 OdhDashboardConfig 自定义资源定义(CRD)。
  4. 点 YAML 标签。
  5. 删除 groupsConfig 键以及其中的所有数据，如 adminGroups 和 allowedGroups。
  6. 点击 Save。

RHOAIENG-1971 1- Kueue-controller-manager 在从 2.16.0 升级到 2.17.0后使用旧的指标端口

升级后，Kueue Operator 继续使用旧端口(8080)而不是新端口(8443)作为指标。因此，OpenShift 控制台 Observe > Targets 页面显示 Kueue Operator 的状态为 Down。

临时解决方案
重启 Kue Operator Pod (kue-controller-manager)或删除 kueue-controller-manager 部署。Kueue Operator 状态更改为 Up。

RHOAIENG-18933 - increasedd workbench 镜像大小可能会延迟工作台启动

2024.2 workbench 镜像现在包含 kubeflow-training Python SDK，可让您与 Training Operator 交互以进行微调。这个添加会增加工作台镜像大小，这可能会在启动工作台时造成延迟。

临时解决方案
无。

RHOAIENG-1888 4- 启用 NIM 帐户设置不完整

当您尝试启用 NVIDIA NIM 模型服务平台时，odh-model-controller 部署会在 NIM 帐户设置完成前启动。因此，NIM 帐户设置不完整，且不会启用平台。

临时解决方案
重启 odh-model-controller 部署。

升级后 RHOAIENG-18675 - Workbenches 组件失败

当升级到 OpenShift AI 1 时，工作台组件无法正确升级。具体来说，BuildConfigs 和遵循它的资源（如 RStudio BuildConfigs 和 ROCm 镜像流）不会被更新，从而导致 DataScienceCluster 中的工作台组件协调失败。

临时解决方案
在升级前，删除集群中的现有 BuildConfig 对象以避免这些问题。

RHOAIENG-18590 - 禁用并启用 KServe 后 KnativeServing 资源失败

在 DataScienceCluster 中禁用并启用 kserve 组件后，KnativeServing 资源可能会失败。

临时解决方案

删除所有与 Knative 相关的 ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration Webhook：

  1. 获取 Webhook： 

    oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
  2. 确保禁用 KServe。

  3. 获取 Webhook： 

    oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
  4. 删除 webhook。
  5. 启用 KServe。
  6. 验证 KServe pod 可以成功生成，并且 knative-serving 命名空间中的 pod 是否活跃且可操作。

RHOAIENG-19261 - TrustyAI 安装可能会因为缺少自定义资源定义(CRD)而失败。

当安装或升级 OpenShift AI 时，TrustyAI 安装可能会因为缺少 InferenceService 和 ServingRuntime CRD 而失败。因此，Trusty AI 控制器进入 CrashLoopBackOff 状态。

临时解决方案
  1. 根据您的部署，在 DataScienceCluster 中启用 Kserve 或 ModelMesh 组件。
  2. 在 redhat-ods-applications 命名空间中重启 trustyai-service-operator-controller-manager pod。

RHOAIENG-182 38- Inference 端点在升级 Authorino Operator 后返回 403 错误

升级 Authorino Operator 后，可能无法重新应用自动 Istio sidecar 注入。如果没有 sidecar，则 Authorino 没有正确集成到服务网格中，从而导致 inference 端点请求失败，并显示 HTTP 403 错误。

临时解决方案
重启 OpenShift AI Operator pod。有关详细临时解决方案，请参阅 RHOAI Single-Model Serving Endpoints 在 Authorino Update 后返回 HTTP 403 Errors。

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

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

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

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

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

从模型 registry 部署模型时，RHOAIENG-161 46- Connection 有时不会预先选择

从模型 registry 部署模型时，对象存储 连接 （以前称为 数据连接）可能无法预先选中。此行为取决于目标项目中与所注册模型版本位置匹配的 S3 兼容对象存储连接。

  • 如果项目没有匹配的连接：系统会提示您创建连接时，不会预先填充位置字段，且不会显示解释预填充行为的警报。
  • 如果项目有多个匹配连接：在连接列表中，匹配的连接不会标记为 Recommended。

如果只有一个匹配的连接，则不会出现这个问题，因为连接已被正确地选选。

临时解决方案

临时解决方案取决于匹配的连接数量，如下所示：

  • 如果项目没有匹配的连接：手动重新输入模型位置详情。
  • 如果项目有多个匹配连接：在项目的 Connections 视图中检查您的连接，然后选择与您的首选模型位置匹配的连接。

RHOAIENG-1137 1- 使用 ExitHandler 报告运行状态

使用管道退出处理程序(dsl.ExitHandler)时，如果句柄中的某个任务失败，但退出任务成功，则整个管道运行状态不准确报告为 Succeeded，而不是 Failed。

临时解决方案
无。

RHOAIENG-15123 （也称为 RHOAIENG-10790 和 RHOAIENG-14265）- 升级后管道调度可能会失败

当您升级到 OpenShift AI 1 时，数据科学管道会调度在升级无法执行前存在的数据科学管道，从而导致任务 pod 出现错误消息。

临时解决方案
按照 升级到 Red Hat OpenShift AI 2.16.0 知识库解决方案后如何解决调度的管道运行失败。

当在带有 Jupyter 笔记本的 Ray 集群中使用不同的 Python 版本时，会出现 RHOAIENG-14271 - 兼容性错误

当您在 Jupyter 笔记本中使用 Python 版本 3.11 时，然后创建一个 Ray 集群，集群默认为包含 Ray 版本 2.35 和 Python 版本 3.9 的工作台镜像。这个不匹配可能会导致兼容性错误，因为 Ray Python 客户端需要与您的工作台配置匹配的 Python 版本。

临时解决方案
将工作台镜像与您的 Ray 集群一起使用，其中包含与 ClusterConfiguration 参数匹配的 Python 版本。

RHOAIENG-12233 - 使用 /v1/chat/completions 端点时需要 chat_template 参数

当为 KServe 运行时配置 vLLM ServingRuntime 并使用 /v1/chat/completions 端点查询模型时，模型会失败并显示以下错误： 

As of transformers v4.44, default chat template is no longer allowed, so you must provide a chat template if the tokenizer does not define one

vLLM v0.5.5 提供了 transformers v4.44.2。从 vLLM v0.5.5 开始，您必须在使用 /v1/chat/completions 端点查询模型时提供 chat 模板。

临时解决方案

如果您的模型不包含预定义的 chat 模板，您可以使用 chat-template 命令行参数在自定义 vLLM 运行时中指定 chat 模板，如示例所示。将 <CHAT_TEMPLATE > 替换为模板的路径。 

containers:
  - args:
      - --chat-template=<CHAT_TEMPLATE>

您可以使用 https://github.com/opendatahub-io/vllm/tree/main/examples 中作为 .jinja 文件提供的 chat 模板，或者使用 /apps/data/template 下的 vLLM 镜像。如需更多信息，请参阅 Chat 模板。

当将 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. 等待大约 20 秒，然后确保自动应用新的 AppWrapper CRD，如下例所示： 

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

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

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

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

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-6486 - 使用带有 TensorFlow 2024.1 笔记本镜像的 Elyra JupyterLab 扩展时，无法配置 Pod 标签、注解和容限

当在 TensorFlow 2024.1 笔记本镜像中使用 Elyra JupyterLab 扩展时，您无法从执行的管道配置 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 部分时，所有项目 值都当前排除了尚未接受到队列的分布式工作负载的资源。

临时解决方案
无。

RHOAIENG-6409 - 在管道日志中出现无法保存参数 错误，以便成功运行

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

临时解决方案
无。

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

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

临时解决方案
无。

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

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

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

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

如果您在 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-3025 - OVMS 预期目录布局与 KServe StoragePuller 布局冲突

当您使用 OpenVINO Model Server (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/ 目录中拉取模型文件。

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

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

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

RHOAIENG-2602 - "Average 响应时间"服务器指标图因为 ModelMesh pod 重启而显示多行

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

临时解决方案
无。

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

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

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

RHOAIENG-2555 - 在更改 Serving 运行时时，模型框架选择器不会重置

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

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

RHOAIENG-2468 - 与 KServe 位于同一项目中的服务可能会在 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-2228 - 性能指标图形在间隔设置为 15 秒时持续更改

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

临时解决方案
无。

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

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

临时解决方案
无。

RHOAIENG-1919 - 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-404 - 在 OpenShift AI 仪表板中随机显示没有组件发现页面而不是 Enabled 页面

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

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

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

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

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

RHOAIENG-497 - 在 OpenShift Service Mesh CR 中删除 DSCI 结果，在没有用户通知的情况下删除

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

临时解决方案
无。

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 出口和入口 pod 的内存限值。

RHOAIENG-130 - 刚刚启动模型时同步问题

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

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

RHOAIENG-3115 - 在模型显示为 ready 后无法查询模型

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

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

RHOAIENG-1619 （之前记录的是 DATA-SCIENCE-PIPELINES-165）- S3 存储桶无法写入时的 Poor 错误消息

当您设置数据连接时，S3 存储桶无法写入，并且您尝试上传管道，错误消息 Failed to store pipelines is not helpful。

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

RHOAIENG-1207 （之前记录的为 ODH-DASHBOARD-1758）- Error duplicating OOTB 自定义运行时几次

如果您复制了 model-serving 运行时多次，则重复会失败，并显示 Serving 运行时名称 "<name>" already exists 错误信息。

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

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

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

临时解决方案
无。

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

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

临时解决方案
无。

RHOAIENG-226 （之前记录的为 RHODS-12432）- 删除 notebook-culler ConfigMap 会导致仪表板中出现 Permission Denied

如果您在 redhat-ods-applications 命名空间中删除 notebook-controller-culler-config ConfigMap，则无法将更改保存到 OpenShift AI 仪表板上的 Cluster Settings 页面。保存操作失败并显示 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 - 在笔记本重启后无法运行 Elyra 管道

如果您使用 Elyra JupyterLab 扩展在 JupyterLab 中创建并运行数据科学管道，且您在工作台中创建工作台并在工作台中指定笔记本镜像 后，您无法执行管道，即使在重启笔记本后也是如此。

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

RHOAIENG-11 - 9 月安装的 CodeFlare Operator 实例不被支持

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

临时解决方案

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

如需有关 Red Hat OpenShift AI Operator 依赖项的更多信息，请参阅 Red Hat OpenShift AI 支持的配置。

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 失败，并将 error seccomp 过滤器加载到 kernel: errno 524 in OpenShift 4。

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

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

临时解决方案
无。

RHOAIENG-16568 （以前称为 NOTEBOOKS-210）- 笔记本无法在 Jupyter 中导出为 PDF 文件

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

临时解决方案
无。

RHOAIENG-1210 （之前记录的为 ODH-DASHBOARD-1699）- Workbench 不会为所有配置更改自动重启

当您编辑工作台的配置设置时，会出现一条警告消息，表示当您对配置设置进行任何更改时，工作台将重新启动。这个警告是误导，因为在以下情况下，工作台不会自动重启：

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

RHOAIENG-1208 （之前记录的为 ODH-DASHBOARD-1741）- 无法创建一个以数字开头的工作台

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

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

KUBEFLOW-157 - 如果您已从 OpenShift AI 仪表板注销 JupyterLab 时无法正常工作

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

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

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

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

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

RHOAIENG-580 （之前记录的为 RHODS-9412）- 如果具有编辑权限的用户创建工作台，Slyra 管道将无法运行

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

  • 在工作台创建过程中，用户会看到与创建 Kubernetes 角色绑定相关的 Error create workbench 消息。
  • 虽然前面的错误消息，OpenShift AI 仍然会创建工作台。但是，错误消息意味着用户无法使用工作台来运行 Elyra 数据科学管道。

  • 如果用户尝试使用工作台运行 Elyra 管道，Jupyter 会显示一个 Error making request 消息。

    临时解决方案
    具有管理员权限（如项目所有者）的用户必须代表具有编辑权限的用户创建工作台。然后，用户可以使用工作台运行 Elyra 管道。

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-1152 （之前记录的为 RHODS-6356）- 笔记本创建过程对于从未登录到仪表板的用户失败

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

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

rhODS-5763 - 在笔记本选择过程中显示正确的软件包版本

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

临时解决方案
无。

rhODS-5543 - 使用 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-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-4718 - Intel® oneAPI AI Analytics Toolkits 快速启动引用不存在的示例笔记本

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

临时解决方案
无。

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

负责验证 Anaconda 专业版许可证的 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 没有被安装。

临时解决方案
无。

rhODS-3984 - 在笔记本选择过程中显示正确的软件包版本

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

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

RHODS-2956 - 创建笔记本实例时可能会出现错误

在 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 的帮助。

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

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

临时解决方案
无。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.