发行注记
与本发行版本相关的功能、增强功能、已解决的问题
摘要
第 1 章 OpenShift AI 概述 复制链接链接已复制到粘贴板!
Red Hat OpenShift AI 是人工智能和机器学习(AI/ML)应用程序的数据科学家和开发人员的平台。
OpenShift AI 提供了一个环境,可在内部或云中开发、培训、服务、测试和监控 AI/ML 模型和应用程序。
对于数据科学家,OpenShift AI 包括 Jupyter 和默认笔记本镜像集合,使用模型开发所需的工具和库优化,以及 TensorFlow 和 PyTorch 框架。部署并托管您的模型、将模型集成到外部应用程序中,并在任何混合云环境中导出模型以托管它们。您还可以使用图形处理单元(GPU)和 Habana Gaudi 设备来加快数据科学试验。
对于管理员,OpenShift AI 在现有 Red Hat OpenShift 或 ROSA 环境中启用数据科学工作负载。使用您现有的 OpenShift 身份提供程序来管理用户,并管理可供笔记本服务器使用的资源,以确保数据科学家具有创建、培训和主机模型所需的内容。使用加速器降低成本并允许数据科学家使用图形处理单元(GPU)和 Habana Gaudi 设备提高其端到端数据科学工作流的性能。
OpenShift AI 提供两个发行版本:
Red Hat OpenShift Dedicated 的受管云服务附加组件 (具有 AWS 或 GCP 的客户云订阅)或 Red Hat OpenShift Service on Amazon Web Services (ROSA)。
有关红帽管理环境中的 OpenShift AI 的详情,请参考 Red Hat OpenShift AI 产品文档。
您可以在自管理的环境中(如 OpenShift Container Platform)安装内部或公有云中的自我管理软件。
有关在连接或断开连接的环境中的 OpenShift 集群上将 OpenShift AI 作为自我管理的软件的详情,请参考 Red Hat OpenShift AI Self-Managed 的产品文档。
有关 OpenShift AI 支持的软件平台、组件和依赖项的详情,请参考 支持的配置。
有关 2.8 发行生命周期的详细视图,包括完全支持阶段窗口,请参阅 Red Hat OpenShift AI Self-Managed 生命周期。
第 2 章 新功能及功能增强 复制链接链接已复制到粘贴板!
本节论述了 Red Hat OpenShift AI 2.8 中的新功能和增强。
2.1. 新功能 复制链接链接已复制到粘贴板!
- 支持自签名证书
现在,您可以在 OpenShift Container Platform 集群中的 Red Hat OpenShift AI 部署和 Data Science 项目中使用自签名证书。
有些 OpenShift AI 组件为自签名证书有额外的选项或所需的配置,如 使用证书(断开连接的环境,请参阅使用证书) 中所述。https://access.redhat.com/documentation/zh-cn/red_hat_openshift_ai_self-managed/2.8/html/installing_and_uninstalling_openshift_ai_self-managed/working-with-certificates_certs
2.2. 功能增强 复制链接链接已复制到粘贴板!
- 升级的 OpenVINO Model Server
- OpenVINO Model Server 已升级至 2023.3 版本。有关更改和增强的详情,请参考 OpenVINO™ Model Server 2023.3。
- 支持单型号服务平台上的 gRPC 协议
- 单模式服务平台现在在 REST 之外还支持 gRPC API 协议。这个支持意味着,当您在平台中添加自定义模型服务运行时时,您可以指定运行时使用的协议。
- 新的发行频道延长支持
从 OpenShift AI 2.8 开始,除了
fast、stable和alpha频道外,红帽还为 Red Hat OpenShift AI Operator 提供了生产环境的更新和支持:-
stable-2.8频道允许您保留最新的 2.8.z 版本,完全支持 7 个月。 -
eus-2.8频道允许您保持最新的 2.8.z 版本,完全支持 7 个月,然后延长的更新支持时间甚至几个月。
有关订阅频道的更多信息,请参阅安装 Red Hat OpenShift AI Operator。
-
第 3 章 技术预览功能 复制链接链接已复制到粘贴板!
本节论述了 Red Hat OpenShift AI 2.8 中的技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
- 分布式工作负载
分布式工作负载使数据科学家可以并行使用多个集群节点,以获得更快速、高效的数据处理和模型培训。CodeFlare 框架简化了任务编配和监控,并提供与高级 GPU 支持的自动化资源扩展和最佳节点利用率的无缝集成。
CodeFlare 框架专为数据科学家设计,支持从 Jupyter Notebook 或 Python 代码直接工作负载配置,确保采用低障碍、简化且不间断的工作流。分布式工作负载显著降低任务完成时间,并启用使用更大的数据集和更复杂的模型。分布式工作负载功能目前在 Red Hat OpenShift AI 2.8 中作为技术预览功能提供。此功能最初在 OpenShift AI 2.4 中引入。
- code-server 笔记本镜像
Red Hat OpenShift AI 现在包括
code-server笔记本镜像。如需更多信息,请参阅 GitHub 中的 code-server。使用
code-server工作台镜像,您可以使用各种扩展来添加新的语言、主题、调试器并连接到其他服务来自定义工作台环境。您还可以提高数据科学工作的效率,语法突出显示、自动和括号匹配。
基于 Elyra 的管道在 code-server 笔记本镜像中不可用。
code-server 笔记本镜像目前在 Red Hat OpenShift AI 2.8 中作为技术预览功能提供。此功能最初在 OpenShift AI 2.6 中引入。
第 4 章 支持删除 复制链接链接已复制到粘贴板!
本节介绍了对 Red Hat OpenShift AI 中面向用户的功能的支持的主要变化。
4.1. OpenShift AI 2.8 EUS 不支持数据科学管道 v1 复制链接链接已复制到粘贴板!
OpenShift AI 2.8 及更早的版本中的数据科学管道基于 KubeFlow Pipelines v1。从 OpenShift AI 2.9 开始,数据科学管道基于 KubeFlow Pipelines v2,它使用不同的工作流引擎。
OpenShift AI 2.8 稳定版本支持数据科学管道 1.0,直到对这个版本的支持于 2024 年 10 月 14 日结束。在 OpenShift AI 2.8 Extended Update Support (EUS)版本中,数据科学管道 1.0 资源继续运行,但红帽不再支持。有关 2.8 发行生命周期的详细视图,包括完全支持阶段窗口,请参阅 Red Hat OpenShift AI Self-Managed 生命周期。
OpenShift AI 不会自动将现有数据科学管道 1.0 实例迁移到 2.0。如果升级 OpenShift AI,您必须手动迁移现有数据科学管道 1.0 实例。如需更多信息,请参阅 迁移到数据科学管道 2.0。
4.2. 不再使用嵌入式订阅频道 复制链接链接已复制到粘贴板!
从 OpenShift AI 2.8 开始,不再使用 嵌入的 订阅频道。您无法为 Operator 的新安装选择 嵌入式 频道。有关订阅频道的更多信息,请参阅安装 Red Hat OpenShift AI Operator。
4.3. 删除 bias 检测(TrustyAI) 复制链接链接已复制到粘贴板!
从 OpenShift AI 2.7 开始,bias 检测(TrustyAI)功能已被删除。如果您之前启用了这个功能,升级到 OpenShift AI 2.7 或更高版本会删除该功能。默认 TrustyAI 笔记本镜像仍被支持。
4.4. 不再支持用于工作台的版本 1.2 笔记本镜像 复制链接链接已复制到粘贴板!
在创建工作台时,您可以指定一个与工作台搭配使用的笔记本镜像。从 OpenShift AI 2.5 开始,当您创建新的工作台时,无法选择版本 1.2 笔记本容器镜像。已使用版本 1.2 笔记本镜像运行的工作台继续正常工作。但是,红帽建议您更新工作台以使用最新的笔记本容器镜像。
4.5. 不再使用 beta 订阅频道 复制链接链接已复制到粘贴板!
从 OpenShift AI 2.5 开始,不再使用 beta 订阅频道。您无法为 Operator 的新安装选择 beta 频道。有关订阅频道的更多信息,请参阅安装 Red Hat OpenShift AI Operator。
第 5 章 已解决的问题 复制链接链接已复制到粘贴板!
以下显著问题在 Red Hat OpenShift AI 2.8.5 中解决。
Red Hat OpenShift AI 2.8 的安全更新、程序错误修正和增强将会以异步勘误的形式发布。所有 OpenShift AI 勘误公告都会 在红帽客户门户网站中 发布。
要接收 OpenShift AI 2.8 的最新更新,您的 Red Hat OpenShift AI Operator 的安装必须配置为使用 eus-2.8 更新频道。
有关 2.8 发行生命周期的最新信息,包括完全支持阶段窗口,请参阅 Red Hat OpenShift AI Self-Managed Life Cycle。
5.1. 容器等级发行版本,Red Hat OpenShift AI 2.8.5 (November 2024) 复制链接链接已复制到粘贴板!
此发行版本为在 Red Hat Container Catalog 中列出的一个或多个 Red Hat OpenShift AI 容器镜像提供更新,该镜像是 Red Hat Ecosystem Catalog 的一部分。
有关容器健康等级的信息,请参阅 Red Hat Container Catalog 中使用的容器健康指数等级。
有关发行版本中更新的完整列表,请查看相关的勘误。所有 OpenShift AI 勘误公告都会 在红帽客户门户网站中 发布。
5.2. 在 Red Hat OpenShift AI 2.8.4 中解决的问题(August 2024) 复制链接链接已复制到粘贴板!
RHOAIENG -8898- Cannot upgrade between OpenShift AI 2.8.z
在以前的版本中,当 OpenShift 集群达到其资源容量限制时,您无法在 OpenShift AI 2.8.z 版本间升级。出现这个问题的原因是,部署 pod 无法确定 OpenShift AI Operator 是否在自助管理集群或受管云服务集群中安装。这个问题现已解决。
5.3. 在 Red Hat OpenShift AI 2.8.3 中解决的问题(2024 年 6 月) 复制链接链接已复制到粘贴板!
有关更新的完整列表,请参阅 RHBA-2024:3930 公告。
RHOAIENG-6817 (以前称为 RHOAIENG-5025)- 自签名证书不适用于第一个创建的工作台
在以前的版本中,在集中配置自签名证书后,证书不适用于数据科学项目中创建的第一个工作台。这个问题现已解决。
从 Jupyter 标题创建的 RHOAIENG-645 5- Workbenches 会在重启后丢失自签名证书
在以前的版本中,在 rhods-notebooks 命名空间中,如果您重启了使用自签名证书配置的 OpenShift AI 仪表板上的 Jupyter 标题创建的工作台,则重启后证书不再附加到工作台中。这个问题现已解决。
RHOAIENG-3378 - 内部镜像 Registry 是 Jupyter 笔记本生成过程的不决定的硬依赖项
在以前的版本中,在启动 OpenShift AI 笔记本和工作台前,您必须在 OpenShift Container Platform 中启用了内部集成的容器镜像 registry。在不首先启用镜像 registry 时尝试启动笔记本或工作台会失败,并显示 "InvalidImageName" 错误。这个问题现已解决。
5.4. 在 Red Hat OpenShift AI 2.8.2 中解决的问题(24 年 5 月) 复制链接链接已复制到粘贴板!
有关更新的完整列表,请参阅 RHBA-2024:2745 公告。
RHOAIENG-6433 - 启用 kue 组件错误地创建一个命名空间
在以前的版本中,如果您在默认 DataScienceCluster 对象中启用了 kueue 组件,则 opendatahub 命名空间会被错误地创建。这个问题现已解决,因此这个组件不再创建 opendatahub 命名空间。
RHOAIENG-6276 - 启用 kue 和 ray 组件会导致协调循环
在以前的版本中,如果您在默认的 DataScienceCluster 对象中启用了 kueue 和 ray 组件,DataScienceCluster 对象会持续协调组件。这个问题现已解决。
RHOAIENG-5575 - 启用 kueue 组件会离开应用程序不需要的命名空间
在以前的版本中,如果您在默认的 DataScienceCluster 对象中启用了 kueue 或 ray 组件,则 opendatahub 命名空间会被错误地创建。这个问题现已解决,在这些组件不再创建 opendatahub 命名空间时,如果没有用户 pod 运行,则命名空间会在升级到 OpenShift AI 2.8.2 后删除。
5.5. 在 Red Hat OpenShift AI 2.8.1 中解决的问题(April 2024) 复制链接链接已复制到粘贴板!
有关更新的完整列表,请参阅 RHBA-2024:1748 公告。
RHOAIENG-4937 (以前记录的为 RHOAIENG-4572)- 在某些情况下,无法运行数据科学项目管道
在以前的版本中,在以下情况下,在安装或升级 OpenShift AI 后您无法运行数据科学管道:
-
已安装 OpenShift AI,并且具有有效的 CA 证书。在 default-dsci 对象中,您将
trustedCABundle字段的managementState字段更改为Removed安装后。 - 您已将 OpenShift AI 从 2.6 升级到 2.8 版本,并且具有有效的 CA 证书。
- 您已将 OpenShift AI 从 2.7 升级到 2.8 版本,并且具有有效的 CA 证书。
这个问题现已解决。
RHOAIENG-4327 - Workbenches 不使用集中配置的捆绑包中的自签名证书
在 OpenShift AI、ca-bundle.crt 和 odh-ca-bundle.crt 中包含自签名证书有两个捆绑包选项。在以前的版本中,工作台不会自动使用来自集中配置的捆绑包的自签名证书,您必须定义指向证书路径的环境变量。这个问题现已解决。
RHOAIENG-673 (之前记录的为 RHODS-12946)- 无法在断开连接的环境中从 PyPI 镜像安装或使用私有证书
在断开连接的环境中,Red Hat OpenShift AI 无法连接到面向公共的 PyPI 存储库,因此您必须在网络中指定存储库。在以前的版本中,如果您使用私有 TLS 证书,且数据科学管道被配置为安装 Python 软件包,则管道运行会失败。这个问题现已解决。
RHOAIENG-637 (之前记录的为 RHODS-12904)- 使用私有证书时,从 Elyra 提交的 Pipeline 可能会失败
如果您使用私有 TLS 证书并从 Elyra 提交管道,则之前管道可能会失败,并显示 certificate verify failed 错误信息。这个问题现已解决。
5.6. 在 Red Hat OpenShift AI 2.8.0 中解决的问题(March 2024) 复制链接链接已复制到粘贴板!
有关更新的完整列表,请参阅 RHBA-2024:1371 公告。
RHOAIENG-3355 - KServe 上的 OVMS 无法正确使用加速器
在以前的版本中,当使用单模式服务平台部署模型并选择了 OpenVINO Model Server serving 运行时,如果您请求了加速器来附加到模型服务器,则会检测到加速器硬件,但在响应查询时不会被模型使用。这个问题现已解决。
RHOAIENG-2869 - 无法编辑现有模型框架和模型路径
在以前的版本中,当您尝试使用 Deploy model 对话框编辑多型号项目中的模型时,模型框架和 路径 值不会更新。这个问题现已解决。
RHOAIENG-2724 - 型号部署失败,因为字段会在对话框中自动重置
在以前的版本中,当部署模型或编辑部署模型时,"Deploy model"对话框中的 Model servers 和 Model 框架 字段可能会重置为默认状态。Deploy 按钮可能会保持启用状态,即使这些强制字段不再包含有效的值。这个问题现已解决。
RHOAIENG-2099 - 数据科学管道服务器无法在新集群中部署
在以前的版本中,当您在新集群中创建数据科学项目管道服务器时,用户界面会保持在加载状态,管道服务器不会启动。这个问题现已解决。
RHOAIENG-1199 (之前记录的为 ODH-DASHBOARD-1928)- 自定义服务运行时创建错误消息不方便
在以前的版本中,当尝试创建或编辑自定义 model-serving 运行时并出现错误时,错误消息没有指定错误。改进了错误消息。
RHOAIENG-675 (之前记录的为 RHODS-12906)- 无法使用带有私有证书的对象存储的 ModelMesh
在以前的版本中,当您将模型存储在使用私有 TLS 证书的对象存储供应商中时,模型服务 pod 无法从对象存储中拉取文件,并显示 签名 by unknown authority 错误消息。这个问题现已解决。
RHOAIENG-556 - 无论错误是什么,都为 KServe 模型创建 ServingRuntime
在以前的版本中,当您试图部署 KServe 模型并出现错误时,Infe renceService 自定义资源(CR)仍然被创建,且在 Data Science Project 页面中显示模型,但状态始终保持未知。KServe 部署过程已更新,以便在出现错误时不会创建 ServingRuntime。
RHOAIENG-548 (之前记录的为 ODH-DASHBOARD-1776)- 用户没有项目管理员权限时的错误消息
在以前的版本中,如果您没有项目的管理员权限,则无法访问一些功能,且错误消息没有解释原因。例如,当您在只能访问单个命名空间的环境中创建了模型服务器时,会出现 Error create model server 错误消息。但是,模型服务器仍然成功创建。这个问题现已解决。
RHOAIENG-66 - 由 CodeFlare SDK 部署 Ray 仪表板路由公开自签名证书,而不是集群证书
在以前的版本中,当您使用带有 openshift_oauth=True 选项的 CodeFlare SDK 部署 Ray 集群时,Ray 集群生成的路由会使用 passthrough 方法进行保护,因此会公开 OAuth 代理使用的自签名证书。这个问题现已解决。
RHOAIENG-12 - 从一些浏览器无法访问 Ray 仪表板
在某些浏览器中,分布式工作负载功能的用户可能无法访问 Ray 仪表板,因为浏览器会自动将仪表板 URL 的前缀从 http 改为 https。这个问题现已解决。
rhoDS-6216 - ModelMesh oauth-proxy 容器不稳定
在以前的版本中,由于 ModelMesh oauth-proxy 容器失败,ModelMesh pod 无法正确部署。此问题会间歇性发生,只有在 ModelMesh 运行时环境中启用了身份验证时才发生。这个问题现已解决。
第 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 Life Cycle。
RHOAIENG-1059 6- Model serving 堆栈错误地处理 DSCInitialization 对象中的自定义 CA 捆绑包
将自定义证书颁发机构(CA)捆绑包添加到 DSCInitialization 对象时,对于不是自定义 CA 捆绑包的端点,模型 Serving 堆栈(ModelMesh 和 KServe)中的所有 SSL 验证都会失败。这会影响单模式服务堆栈和多模式服务堆栈。
- 临时解决方案
- 如果需要,避免使用自定义 CA 捆绑包。如果您的部署需要自定义 CA 捆绑包,请为可能需要从 Model Serving 堆栈连接到的任何端点添加自签名证书。
RHOAIENG-10129 - Notebook 和带有匹配名称的 Ray 集群会导致 secret 解析失败
如果您创建一个笔记本和在同一命名空间中具有匹配名称的 Ray 集群,则一个控制器将无法解析其 secret,因为 secret 已具有所有者。
- 临时解决方案
- 更改 Ray 集群的名称,使其名称与命名空间中的对应笔记本名称不同。
当有大量工作台镜像可用时,可用工作台镜像的 RHOAIENG-7806 列表部分模糊处理
当您试图在 Data Science Projects 页面的 Workbenches 选项卡中创建工作台时,如果您的部署包含大量工作台镜像,则用户界面会部分模糊处理可用的工作台镜像列表。因此,您无法从列表中选择 obscured workbench 镜像。
- 临时解决方案
- 减少部署中的可用工作台镜像数量,以便每个工作台镜像不会由用户界面混淆。
使用自定义镜像创建的 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,然后使用自定义镜像创建工作台。
RHOAIENG-8218 - 无法登录到在没有 OCP 内部镜像 registry 的 OpenShift 4.15 集群上创建的工作台
当您在没有启用 OpenShift Container Platform 内部镜像 registry 的 OpenShift Container Platform 4.15 集群上创建工作台时,工作台可以成功启动,但您无法登录到它。授权服务器遇到意外条件,阻止它满足请求 错误。
- 临时解决方案
为您创建的每个工作台在 OpenShift Container Platform 中手动创建服务帐户令牌 secret。
在 OpenShift CLI 中,使用以下命令来创建服务帐户令牌 secret。将
<workbench-name> 替换为您的工作台的名称,<project-name> 替换为数据科学项目的名称。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 刷新浏览器中的页面并登录到您的工作台。
有关使用 Web 控制台创建服务帐户令牌 secret 的详情,请参考 创建服务帐户令牌 secret。
rhoAIENG-6711 - ODH-model-controller 覆盖 ServiceMeshMemberRoll 对象中的 spec.memberSelectors 字段
如果您使用 ServiceMeshMemberRoll 资源的 spec.memberSelectors 字段将项目或命名空间添加到 ServiceMeshMemberRoll 资源中,ODH-model-controller 会覆盖字段。
- 临时解决方案
使用
spec.members字段明确将命名空间添加到ServiceMeshMemberRoll资源中,如下例所示:spec: members: - <namespace 1> - <namespace 2>
spec: members: - <namespace 1> - <namespace 2>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 时,非保留命名空间不包含 odh-trusted-ca-bundle ConfigMap。这些问题很少发生。
- 临时解决方案
- 重启 Red Hat OpenShift AI Operator pod。
RHOAIENG-4524 - RStudio 镜像的 BuildConfig 定义包含错误的分支
RStudio 和 CUDA - RStudio 工作台镜像的 BuildConfig 定义指向 OpenShift AI 中错误的分支。BuildConfig 定义错误地指向 main 分支,而不是 rhoai-2.8 分支。
- 临时解决方案
- 要在 OpenShift AI 中使用 RStudio 和 CUDA - RStudio 工作台镜像,请按照 RStudio 镜像 BuildConfig 定义知识库文章的 Branch 临时解决方案 操作。
RHOAIENG-4497 - 带有自签名证书的多模型服务平台上的模型在升级到 2.8 后停止工作
在以前的版本中,如果您在多型号服务平台上提供模型时使用自签名证书,则必须手动配置数据连接用来指定证书颁发机构(CA)捆绑包的 storage-config secret。
如果您升级了一个与最新版本相关的 OpenShift AI 版本,则多模式服务平台将不再提供模型。
- 临时解决方案
- 要将自签名证书与多模式服务平台一起使用,请按照 添加 CA 捆绑包 中的步骤操作。
rhoAIENG-4430 - CA Bundle 不适用于没有数据连接的 KServe
如果您在 OpenShift 集群中安装了证书颁发机构(CA)捆绑包以使用自签名证书,然后使用 OpenShift AI 仪表板创建数据连接来提供模型,OpenShift AI 会自动将证书存储在名为 storage-config 的 secret 中。但是,如果您绕过 OpenShift AI 仪表板并配置底层 InferenceService 资源来指定不同的 secret 名称或服务帐户,OpenShift AI 无法验证到模型的 SSL 连接,模型状态包括 [SSL: CERTIFICATE_VERIFY_FAILED] 证书验证失败: self signed certificate。
- 临时解决方案
-
使用 OpenShift AI 仪表板为您的模型创建数据连接。不要手动修改
InferenceService资源,以指定不同的 secret 名称或服务帐户。
RHOAIENG-4252 - 数据科学管道服务器删除过程无法删除 ScheduledWorkFlow 资源
管道服务器删除过程不会删除 ScheduledWorkFlow 资源。因此,新的 DataSciencePipelinesApplications (DSPA)无法识别冗余的 ScheduledWorkFlow 资源。
- 临时解决方案
- 删除管道服务器。如需更多信息,请参阅 删除管道服务器。
在 OpenShift 命令行界面(CLI)中,以集群管理员身份登录到集群,并执行以下命令删除冗余的
ScheduledWorkFlow资源。oc -n <data science project name> delete scheduledworkflows --all
$ oc -n <data science project name> delete scheduledworkflows --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow
RHOAIENG-4240 - 作业无法在未安全的环境中提交到 Ray 集群
当从一个不安全的 OpenShift 集群中从笔记本运行分布式数据科学工作负载时,可能会显示 ConnectionError: Failed to connect to Ray 错误消息。
- 临时解决方案
-
在笔记本的
ClusterConfiguration部分中,将openshift_oauth选项设置为True。
RHOAIENG-3981 - 在不安全的环境中,等待 Ray 集群处于卡住状态的功能
当从未安全的 OpenShift 集群中的笔记本运行分布式数据科学工作负载时,在继续(cluster.wait_ready())前,在 Ray 集群就绪前等待 Ray 集群就绪的功能,即使 Ray 集群就绪。
- 临时解决方案
执行以下操作之一:
-
在笔记本的
ClusterConfiguration部分中,将openshift_oauth选项设置为True。 -
您可以通过打开 Ray 集群路由 URL 来手动检查 Ray_ready () 功能,而不必使用
cluster.wait_ready ()功能。当 URL 上有 Ray 仪表板时,集群就已就绪。
-
在笔记本的
rhoAIENG-3963 - Unnecessary 受管资源警告
当您编辑并保存 redhat-ods-applications 项目的 OdhDashboardConfig 自定义资源时,系统会错误地显示以下 Managed 资源 警告消息。
This resource is managed by DSC default-doc and any modifications may be overwritten. Edit the managing resource to preserve changes.
This resource is managed by DSC default-doc and any modifications may be overwritten. Edit the managing resource to preserve changes.
您可以安全地忽略此消息。
- 临时解决方案
- 点 Save 关闭警告信息并应用您的编辑。
RHOAIENG-3372 - Pipeline 在断开连接的环境中运行,因为镜像 URL 会失败
Data Science 管道运行引用 registry.access.redhat.com/ubi8/ubi-micro 镜像 URL,而不是 registry.redhat.io/ubi8/ubi-micro 镜像 URL。在断开连接的环境中,这种差异会导致管道运行失败。
- 临时解决方案
创建一个包含以下代码的新自定义资源(CR),其中
my-disconnected-registry.com:8443是您的镜像 registry URL:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 再次运行管道。
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/目录指定为路径的一部分。
-
如果您使用 OpenShift AI 仪表板来部署模型,请在数据连接的 Path 字段中使用 /<
-
在 S3 兼容存储桶中,将模型文件放在名为
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-2542 - Inference 服务 pod 并不总是获得 Istio sidecar
当您使用单一模型服务平台(使用 KServe)部署模型时,生成的 pod 中可能会缺少 istio-proxy 容器,即使 inference 服务具有 sidecar.istio.io/inject=true 注解。
在 OpenShift AI 2.7 中,缺少的 istio-proxy 容器可能不会出现问题。但是,如果 pod 出现连接问题,则它们可能是缺少容器造成的。
- 临时解决方案
- 删除有故障的 pod。OpenShift AI 会自动创建一个新的 pod,它应该有缺少的容器。
RHOAIENG-2759 - 当项目中存在安全和常规模型服务器时,模型部署会失败
当您在使用令牌身份验证的项目中创建第二模型服务器时,而其他服务器不使用身份验证,则第二个模型的部署可能无法启动。
- 临时解决方案
- 不提供。
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-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命令:
RHOAIENG-2468 - 与 KServe 位于同一项目中的服务可能会在 OpenShift 中无法访问
如果您在包含在单个模型服务平台上部署的模型的数据科学项目中部署非 OpenShift AI 服务(使用 KServe),则服务可访问性可能会受 OpenShift 集群的网络配置的影响。特别是当您将 OVN-Kubernetes 网络插件 与主机网络命名空间结合使用时,这特别有用。
- 临时解决方案
执行以下操作之一:
- 在另一个数据科学项目中部署服务,其中不包含在单一模型服务平台上部署的模型。或者,将服务部署到另一个 OpenShift 项目中。
在服务的数据科学项目中,添加一个 网络策略 来接受应用程序 pod 的入口流量,如下例所示:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
RHOAIENG-2312 - 导入 numpy 在 code-server 工作台中失败
在 code-server 工作台中导入 numpy 会失败。
- 临时解决方案
在
code-serverworkbench 中,从 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)显示在 Status bar 上。如果工作台停止并再次启动,所选解释器会保留,因此每个工作台只需要执行一次临时解决方案。
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
Failed to get endpoint for this deployed model. routes.rout.openshift.io"<model_name>" not found
- 临时解决方案
- 刷新浏览器页面。
RHOAIENG-1452 - Red Hat OpenShift AI Add-on 会卡住
Red Hat OpenShift AI Add-on 卸载在通过 OCM API 触发后不会删除 OpenShift AI 组件。
- 临时解决方案
手动删除剩余的 OpenShift AI 资源,如下所示:
-
删除
DataScienceClusterCR。 -
等待所有 Pod 从
redhat-ods-applications命名空间中删除。 -
如果在
DataScienceClusterCR 中将 Serverless 设置为Managed,请等待所有 pod 都从knative-serving命名空间中删除。 -
删除
DSCInitializationCR。 -
如果在
DSCInitializationCR 中将 Service Mesh 设置为Managed,请等待所有 pod 都从istio-system命名空间中删除。 - 卸载 Red Hat OpenShift AI Operator。
-
等待所有 Pod 从
redhat-ods-operator命名空间和redhat-ods-monitoring命名空间删除。
-
删除
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()from codeflare_sdk.cluster.auth import TokenAuthentication auth = TokenAuthentication( token=openshift_token, server=openshift_server, skip_tls=True ) auth_return = auth.login()Copy to Clipboard Copied! Toggle word wrap Toggle overflow
RHOAIENG-404 - 在 OpenShift AI 仪表板中随机显示没有组件发现页面而不是 Enabled 页面
当您访问 Red Hat OpenShift AI 仪表板时,可能会出现 No Components Found 页面。
- 临时解决方案
- 刷新浏览器页面。
RHOAIENG-234 - 不可查看 Insecured 集群中的 VSCode 中的 .ipynb 文件
当您在不安全的集群中使用 Google Chrome 上的 code-server 笔记本镜像时,您无法查看 .ipynb 文件。
- 临时解决方案
- 使用不同的浏览器。
RHOAIENG-2541 - KServe 控制器 pod 遇到 OOM,因为集群中的 secret 数量太多
如果您的 OpenShift 集群有大量 secret,KServe 控制器 pod 可能会因为内存不足(OOM)错误而持续崩溃。
- 临时解决方案
- 减少 OpenShift 集群中的 secret 数量,直到 KServe 控制器 pod 变得稳定。
RHOAIENG-1128 - 当尝试增加未连接到工作台的持久性卷(PV)的大小时,会显示 Unclear 错误消息
当尝试增大没有连接到工作台的持久性卷(PV)的大小时,会显示不明确的错误消息。
- 临时解决方案
- 在尝试增大大小前,验证您的 PV 已连接到工作台。
RHOAIENG-545 - 在 JupyterLab 管道编辑器中无法指定通用默认节点运行时镜像
当您在 JupyterLab IDE 管道编辑器中编辑 Elyra 管道时,您单击 PIPELINE PROPERTIES 选项卡,并滚动到 Generic Node Defaults 部分并编辑 Runtime Image 字段,您的更改不会保存。
- 临时解决方案
- 为每个节点明确定义所需的运行时镜像。单击 NODE PROPERTIES 选项卡,然后在 Runtime Image 字段中指定所需的镜像。
RHOAIENG-497 - 在 OpenShift Service Mesh CR 中删除 DSCI 结果,在没有用户通知的情况下删除
如果您删除 DSCInitialization 资源,OpenShift Service Mesh CR 也会被删除。不显示警告消息。
RHOAIENG-307 - 删除 DataScienceCluster 会删除所有 OpenShift Serverless CR
如果您删除 DataScienceCluster 自定义资源(CR),则所有 OpenShift Serverless CR (包括 knative-serving、Deployment、gateway 和 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 出口和入口 pod 的内存限值。
RHOAIENG-130 - 刚刚启动模型时同步问题
当 KServe 容器的状态为 Ready 时,即使 TGIS 容器未就绪,也会接受请求。
- 临时解决方案
- 等待几秒钟,以确保所有初始化都已完成,并且 TGIS 容器实际就绪,然后查看请求输出。
RHOAIENG-88 - 无法登录到 Red Hat OpenShift AI 仪表板
有时,当您尝试登录到 Red Hat OpenShift AI 时,会显示 500 内部错误消息。
- 临时解决方案
-
在
DataScienceCluster对象中禁用和重新启用仪表板组件。
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-1204 (之前记录在 ODH-DASHBOARD-1771)- JavaScript 错误,在 Pipeline 步骤初始化过程中
有时,管道运行 详情页面 会在运行启动时停止工作。
- 临时解决方案
- 刷新页面。
RHOAIENG-1203 (之前记录的为 ODH-DASHBOARD-1781)- Missing tooltip for Started Run status
Data Science 管道运行有时不会显示显示的状态图标的工具提示文本。
- 临时解决方案
- 如需更多信息,查看管道运行 详情页面 并查看运行输出。
RHOAIENG-1201 (以前称为 ODH-DASHBOARD-1908)- 无法创建带有空环境变量的工作台
在创建工作台时,如果您点击 Add 变量,但没有从列表中选择环境变量类型,则无法创建工作台。该字段未标记为必需,不显示任何错误消息。
RHOAIENG-1196 (之前记录的为 ODH-DASHBOARD-2140)- 仪表板中显示的软件包版本与已安装的版本不匹配
仪表板可能会显示不准确的软件包版本号,如 JupyterLab 和 Notebook。如果手动更新软件包,则镜像中的软件包版本号可能会有所不同。
- 临时解决方案
要查找软件包的真正版本号,请运行
pip list命令并搜索软件包名称,如下例所示:pip list | grep jupyterlab pip list | grep notebook
$ pip list | grep jupyterlab jupyterlab 3.5.3 $ pip list | grep notebook notebook 6.5.3Copy to Clipboard Copied! Toggle word wrap Toggle overflow
RHOAIENG-582 (之前记录的为 ODH-DASHBOARD-1335)- Rename Edit permissions to Contributor
术语 Edit is not accurate:
- 对于大多数 资源,具有 Edit 权限的用户不能编辑资源,他们也可以创建和删除资源。
- 具有 Edit 权限的用户无法编辑项目。
术语 Contributor 可以更准确地描述此权限授予的操作。
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权限的用户完成以下步骤:-
使用
oc客户端登录到集群。 输入以下命令更新
redhat-ods-applications应用程序命名空间中的OdhDashboardConfig自定义资源:oc patch OdhDashboardConfig odh-dashboard-config -n redhat-ods-applications --type=merge -p '{"spec": {"dashboardConfig": {"notebookController.enabled": true}}}'$ oc patch OdhDashboardConfig odh-dashboard-config -n redhat-ods-applications --type=merge -p '{"spec": {"dashboardConfig": {"notebookController.enabled": true}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
使用
RHOAIENG-133 - 在笔记本重启后无法运行 Elyra 管道
如果您使用 Elyra JupyterLab 扩展在 JupyterLab 中创建并运行数据科学管道,且您在工作台中创建工作台并在工作台中指定笔记本镜像 后,您无法执行管道,即使在重启笔记本后也是如此。
- 临时解决方案
- 停止正在运行的笔记本。
- 编辑工作台以做一个小的修改。例如,添加新的 dummy 环境变量,或删除现有的不必要的环境变量。保存您的更改。
- 重启笔记本。
- 在 JupyterLab 的左侧边栏中,单击 Runtimes。
- 确认选择了默认运行时。
RHOAIENG-52 - Token 身份验证在带有自签名证书的集群中失败
如果您使用自签名证书,且您在笔记本中使用 Python codeflare-sdk,或者在管道的一部分中使用 Python codeflare-sdk,则令牌身份验证将失败。
RHOAIENG-11 - 9 月安装的 CodeFlare Operator 实例不被支持
在 Red Hat OpenShift AI 中,codeFlare Operator 包含在基本产品中,而不包含在一个单独的 Operator 中。不支持独立于红帽或社区安装 CodeFlare Operator 实例。
- 临时解决方案
- 删除任何已安装的 CodeFlare Operator,并安装并配置 Red Hat OpenShift AI,如红帽知识库解决方案 如何从数据科学集群中单独安装的 CodeFlare Operator 迁移 中所述。
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"}
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"错误
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
- 临时解决方案
-
增加
net.core.bpf_jit_limit的值,如 红帽知识库解决方案 Pod 失败,并将 error seccomp 过滤器加载到 kernel: errno 524 in OpenShift 4。
KUBEFLOW-177 - 来自应用程序的 Bearer 令牌不是由 OAuth-proxy 转发
如果应用程序的内部身份验证机制基于 bearer 令牌,则无法将应用程序用作自定义工作台镜像。OAuth-proxy 配置从标头中删除 bearer 令牌,应用程序无法正常工作。
RHOAIENG-642 (之前记录的为 RHODS-12903)- Successfully-submitted Elyra 管道无法运行
如果您使用私有 TLS 证书,且您成功向数据科学管道服务器提交 Elyra-generated 管道,管道步骤将无法执行,并显示以下出错信息:
- 临时解决方案
- 请联系红帽支持以获取解决这个问题的详细步骤。
RHOAIENG-1666 (之前记录的是 DATA-SCIENCE-PIPELINES-OPERATOR-349)- 导入管道按钮被预先访问
当您将管道导入到属于数据科学项目的工作台时,可以在管道服务器完全可用前访问 Import Pipeline 按钮。
- 临时解决方案
- 刷新浏览器页面并再次导入管道。
RHOAIENG-5646 (之前记录为 NOTEBOOKS-218)- Elyra 管道编辑器保存的数据科学管道引用不兼容的运行时
当您在 Elyra 管道编辑器中使用 OpenShift AI 版本 1.31 或更早版本的 .pipeline 格式保存管道时,管道会引用与 OpenShift AI 版本 1.32 或更高版本不兼容的运行时。
因此,在将 OpenShift AI 升级到 1.32 或更高版本后,管道无法运行。
- 临时解决方案
- 升级到 OpenShift AI 升级到 1.32 或更高版本后,再次选择相关的运行时镜像。
注意BOOKS-210 - 笔记本无法在 Jupyter 中导出为 PDF 文件
当您将笔记本导出为 Jupyter 中的 PDF 文件时,导出过程会失败并显示错误。
RHOAIENG-1210 (之前记录的为 ODH-DASHBOARD-1699)- Workbench 不会为所有配置更改自动重启
当您编辑工作台的配置设置时,会出现一条警告消息,表示当您对配置设置进行任何更改时,工作台将重新启动。这个警告是误导,因为在以下情况下,工作台不会自动重启:
- 编辑名称
- 编辑描述
- 编辑、添加或删除现有环境变量的键和值
- 临时解决方案
- 手动重启工作台。
RHOAIENG-1208 (之前记录的为 ODH-DASHBOARD-1741)- 无法创建一个以数字开头的工作台
如果您试图创建名称以数字开头的工作台,则工作台不会启动。
- 临时解决方案
- 删除工作台,创建一个以字母开头的名称的新工作台。
RHOAIENG-1205 (之前记录的为 RHODS-11791)- 升级后会启用使用数据收集
如果您之前有 Allow collection usage data 选项(即禁用),则在升级 OpenShift AI 时此选项将变为选择(启用)。
- 临时解决方案
手动重置
Allow collection usage data选项。要做到这一点,请执行以下操作:在 OpenShift AI 仪表板中,在左侧菜单中点击 Settings → Cluster settings。
Cluster Settings 页面将打开。
-
在 Usage data collection 部分中,取消选择
Allow collection usage data。 - 点 Save Changes。
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 管道。
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
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.
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 - 在笔记本选择过程中显示正确的软件包版本
启动一个笔记本服务器 页面显示 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-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/"
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 没有被安装。
RHOAIENG-1135 (之前记录的为 RHODS-3985)- 仪表板不会在 ISV operator 卸载后显示已启用的页面内容
卸载 ISV 操作器后,仪表板的 Enabled 页没有显示任何内容。相反,会显示以下错误:
Error loading components HTTP request failed
Error loading components
HTTP request failed
- 临时解决方案
- 等待 30-40 秒,然后在浏览器中刷新页面。
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 的帮助。
第 7 章 产品特性 复制链接链接已复制到粘贴板!
Red Hat OpenShift AI 为数据科学家和 IT 操作管理员提供一组丰富的功能。如需更多信息,请参阅 Red Hat OpenShift AI 简介。