第 7 章 已解决的问题


在 Red Hat OpenShift AI 中解决了以下显著的问题。

RHOAIENG-16900 - Space-separated 格式(service-runtime 参数)可能会导致部署失败

在以前的版本中,当部署模型时,使用空格分隔的格式来指定额外的服务运行时参数可能会导致 未识别的参数 错误。这个问题现已解决。

在检索集群对象的作业客户端时,RHOAIENG-16073 - Attribute 错误

在以前的版本中,当使用 get_cluster 方法初始化集群时,分配 client = cluster.job_client 有时会导致 AttributeError: 'Cluster' 对象没有属性 '_job_submission_client' 错误。这个问题现已解决。

RHOAIENG-15773 - 无法添加新模型 registry 用户

在以前的版本中,当管理模型 registry 的权限时,您无法添加新的用户、组或项目,如 管理模型 registry 权限 中所述。此时会显示 HTTP 请求失败 错误。这个问题现已解决。

RHOAIENG-14197 - CPU 和内存图形的 Tooltip 文本已损坏,因此不可读

在以前的版本中,当您将光标悬停在 分布式负载 Metrics 页面的 Project metrics 选项卡中的 Top resource-using distributed workload 部分的 CPU 和内存图形上时,工具提示文本被忽略,因此不可读。这个问题现已解决。

删除 opendatahub.io/managed 注解后,RHOAIENG-11024 - Resources 条目会擦除

在以前的版本中,从任何组件部署 YAML 文件中手动删除 opendatahub.io/managed 注解可能会导致文件中的 资源 条目值被清除。这个问题现已解决。

RHOAIENG-810 2- 当集群有多个集群队列时报告的资源

在以前的版本中,当集群有多个集群队列时,所有项目请求的资源会错误地报告为零,而不是 true 值。这个问题现已解决。

Gaudi 加速器的 RHOAIENG-1648 4- vLLM 服务器引擎会在一段时间不活跃后失败

在以前的版本中,当将 vLLM ServingRuntime 与 Gaudi Accelerators 搭配使用时,对带有 Gaudi 硬件的 KServe modelserving 运行时支持 vLLM ServingRuntime 时,vLLM 服务器可能会失败,并带有 TimeoutError 消息。这个问题不再发生。

RHOAIENG-15033 - Model registry 实例在升级 OpenShift AI 后不会重启或更新。

在以前的版本中,当您升级 OpenShift AI 时,模型 registry 组件的现有实例没有更新,这会导致实例 pod 使用比 Operator pod 引用的镜像旧的镜像。这个问题现已解决。

当从 CLI 创建无请求名称的 bias 指标时,RHOAIENG-1500 8- Error

在以前的版本中,如果没有设置 requestName 参数,用户界面有时会在查看 bias 指标时显示错误消息。如果您使用用户界面查看 bias 指标,但希望通过 CLI 配置它们,则必须在有效负载中指定 requestName 参数。这个问题现已解决。

RHOAIENG-14986 - Incorrect 软件包路径会导致 copy_demo_nbs 失败

在以前的版本中,因为 SDK 软件包的一个不正确的路径,CodeFlare SDK 的 copy_demo_nbs () 函数会失败。运行这个功能会导致 FileNotFound 错误。这个问题现已解决。

RHOAIENG-14552 - Workbench 或笔记本 OAuth 代理在 OCP 4.16 上使用 FIPS 失败

在以前的版本中,当在启用了 FIPS 的集群中使用 OpenShift 4.16 或更高版本时,连接到正在运行的工作台会失败,因为内部组件 oauth-proxy 和 OpenShift ingress 间的连接会失败,并显示 TLS 握手错误。在打开工作台时,浏览器会显示 "Application is not available" 屏幕,而无需任何额外的诊断。这个问题现已解决。

RHOAIENG-14095 - 安装 OpenShift AI Operator 后仪表板暂时不可用

在以前的版本中,在安装 OpenShift AI Operator 后,OpenShift AI 仪表板在大约三分钟内不可用。因此,有时会出现 未定义页面的 Cannot read 属性。这个问题现已解决。

RHOAIENG -13633- Cannot 为项目设置服务平台,而无需首先从模型 registry 外部部署模型

在以前的版本中,在没有从模型 registry 外部部署模型的情况下,您无法为项目设置服务平台。您无法将模型 registry 部署到项目,除非项目已经选择了单model或多模式服务。从 OpenShift AI UI 中选择单型号或多模式服务的唯一方法是首先从 registry 外部部署模型或型号服务器。这个问题现已解决。

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

在以前的版本中,当您在 JupyterLab IDE 管道编辑器中编辑 Elyra 管道时,点 PIPELINE PROPERTIES 选项卡,并滚动到 Generic Node Defaults 部分并编辑 Runtime Image 字段,您的更改不会被保存。这个问题现已解决。

RHOAIENG-145 71- Data Science Pipelines API Server 在受管 IBM Cloud OpenShift AI 安装中无法访问

在以前的版本中,当配置数据科学项目服务器时,阻止与管道服务器成功交互的通信错误。这个问题现已解决。

当使用已弃用的 head_memory 参数时,RHOAIENG-14195 - Ray 集群创建会失败

在以前的版本中,如果您在 Ray 集群配置中包含已弃用的 head_memory 参数,则 Ray 集群创建会失败。这个问题现已解决。

使用 |-配置自定义 CA 捆绑包时,RHOAIENG-11895 - Unable to clone a GitHub repo in JupyterLab in JupyterLab

在以前的版本中,如果您使用 |-DSCInitialization (DSCI)对象中配置了自定义证书颁发机构(CA)捆绑包,请从 JupyterLab 克隆存储库会失败。这个问题现已解决。

RHOAIENG-1132 (以前称为 RHODS-6383)- 在工作台创建过程中不需要时不会显示 ImagePullBackOff 错误消息

在以前的版本中,pod 从容器 registry 中拉取容器镜像时遇到问题。发生错误时,会进入 ImagePullBackOff 状态的相关 pod。在工作台创建过程中,如果发生 ImagePullBackOff 错误,则不会显示适当的消息。这个问题现已解决。

RHOAIENG-13327 - Importer 组件(dsl.importer)阻止管道运行

在使用数据科学管道导入程序组件 dsl.importer 组件时,管道无法运行。这个问题现已解决。

RHOAIENG-14652 - kfp-client 无法与 OCP 4.16 及之后的版本上的管道服务器连接

在 OpenShift 4.16 及更新的版本中,可以通过 OpenShift AI Dashboard 访问数据科学管道。但是,因为 TLS 握手错误,从 KFP SDK 连接到管道 API 服务器会失败。这个问题现已解决。

RHOAIENG-10129 - Notebook 和带有匹配名称的 Ray 集群会导致 secret 解析失败

在以前的版本中,如果您创建了与同一命名空间中名称匹配的笔记本和 Ray 集群,则一个控制器无法解析其 secret,因为 secret 已经有所有者。这个问题现已解决。

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

在以前的版本中,当创建一个启用了所有组件的 DataScienceCluster CR 时,Kueue 组件会在 Ray 组件和 training Operator 组件之前安装。因此,Kueue 组件不会监控 RayClusterPyTorchJob 资源。当用户创建 RayClusterPyTorchJob 资源时,Kue 不会控制这些资源的准入。这个问题现已解决。

RHOAIENG-583 (之前记录的为 RHODS-8921RHODS-6373)- 您无法创建管道服务器,或者在超过累积字符限制时启动工作台

当数据科学项目名称和管道服务器名称超过 62 个字符的累积字符限制时,您将无法成功创建管道服务器。同样,当数据科学项目名称和工作台名称超过 62 个字符的累积字符限制时,工作台无法启动。这个问题现已解决。

升级后仪表板上不正确的徽标

在以前的版本中,在从 OpenShift AI 2.11 升级到 OpenShift AI 2.12 后,仪表板可能会错误地显示 Open Data Hub 徽标而不是 Red Hat OpenShift AI 徽标。这个问题现已解决。

管道运行后 RHOAIENG-11297 - Authentication 失败

在以前的版本中,在执行管道运行过程中,可能会因为证书身份验证失败而出现连接错误。此证书身份验证失败可能是由对 default-dsci 对象中的 customCABundle 使用多行字符串分隔符造成的,这不受数据科学管道的支持。这个问题现已解决。

RHOAIENG-112 32- Distributed 工作负载:假定警报不提供 runbook 链接

当一个 Kue 警报触发后,集群管理员可以点击 Observe Alerting Alerts,然后点击警报的名称来打开其 Alert 详情页面。在 Alert details 页面中,Runbook 部分现在提供了一个指向适当的 runbook 的链接,以帮助诊断和解决触发警报的问题。在以前的版本中,缺少 runbook 链接。

RHOAIENG-10665 - Unable to query Speculating with a draft model for granite model

在以前的版本中,您无法对 granite-7b 模型和 granite-7b -accelerator 草案模型使用规范解码。在查询这些模型时,查询会失败并显示内部错误。这个问题现已解决。

RHOAIENG-948 1- Pipeline 在点操作菜单时运行菜单

在以前的版本中,当点在 Experiments > Experiments > Experiment s and run 页面运行的管道 旁的操作菜单(active)时,出现的菜单没有被完全可见,您必须滚动以查看所有菜单项。这个问题现已解决。

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

在以前的版本中,如果您在 OpenShift 集群上禁用了内部镜像 registry,然后使用镜像标签创建了自定义镜像的工作台,例如: quay.io/my-wb-images/my-image:tag,则在 Data Science Projects 页面的 Workbenches 标签页中会显示一个 !Deleted 标志。如果您停止工作台,则无法重启它。这个问题现已解决。

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

在以前的版本中,当您创建管道并将 pip_index_urls 值设置为包含端口号和路径的 URL 时,编译管道代码,然后创建管道运行可能会导致错误。这个问题现已解决。

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

在以前的版本中,当在不安全的 OpenShift 集群中从笔记本运行分布式数据科学工作负载时,可能会显示 ConnectionError: Failed to connect to Ray 错误消息。这个问题现已解决。

RHOAIENG-9670 - vLLM 容器在处理请求时崩溃

在以前的版本中,如果您在单模式服务平台上使用 vLLM ServingRuntime for KServe 运行时部署了模型,且根据您使用的硬件平台,kserve-container 容器也会崩溃。这个问题现已解决。

使用 mixtral-8x7b 生成过程中 RHOAIENG-804 3- vLLM 错误

在以前的版本中,一些模型(如 Mixtral-8x7b)可能会因为 triton 问题而遇到 sporadic 错误,如 FileNotFoundError:No such file 或 directory。这个问题现已解决。

在没有关联的初始化对象的情况下,无法删除 RHOAIENG-297 4- Data Science 集群

在以前的版本中,如果关联的 DSCInitialization 对象(DSCI)不存在,则无法删除 DataScienceCluster (DSC)对象。这个问题现已解决。

RHOAIENG-1205 (之前记录的为 RHODS-11791)- 升级后会启用使用数据收集

在以前的版本中,允许集合使用数据 选项会在您升级 OpenShift AI 时激活。现在,升级时,不再需要手动取消选择 Allow collection usage data 选项。

RHOAIENG-1204 (之前记录在 ODH-DASHBOARD-1771)- JavaScript 错误,在 Pipeline 步骤初始化过程中

在以前的版本中 ,管道运行详情页面 会在运行时停止工作。这个问题现已解决。

RHOAIENG-582 (之前记录的为 ODH-DASHBOARD-1335)- Rename Edit permissions to Contributor

在项目的 Permissions 选项卡上,术语 Edit 已被 Contributor 替代,以更准确地描述此权限授予的操作。

有关更新的完整列表,请查看 勘误公告

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

在以前的版本中,如果您试图使用 vLLM ServingRuntime for KServe 运行时在单模式服务平台上部署 ibm-granite/granite-3b-code-instruct 模型,则模型部署会失败。这个问题现已解决。

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

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

这是 OpenShift 4.15.x 版本早于 4.15.15 的一个已知问题。要解决这个问题,升级到 OpenShift 4.15.15 或更高版本。

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

在以前的版本中,如果您试图升级到 OpenShift AI 2.10,如果仅在管道中创建集群,分布式工作负载将不再从现有管道运行。这个问题现已解决。

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

在以前的版本中,如果您尝试使用数据科学管道 SDK 或 OpenShift AI 用户界面设置默认管道根,则会出现错误。这个问题现已解决。

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

在以前的版本中,如果您尝试使用 ServiceMeshMemberRoll 资源的 spec.memberSelectors 字段将项目或命名空间添加到 ServiceMeshMemberRoll 资源中,ODH-model-controller 将会覆盖该字段。这个问题现已解决。

RHOAIENG-6649 - 在没有定义外部路由的模型上查看模型时会显示错误

在以前的版本中,如果您尝试使用仪表板在没有启用外部路由的模型服务器上部署模型,则模型创建过程中会出现 t.components 为未定义的 错误消息。这个问题现已解决。

RHOAIENG-3981 - 在不安全的环境中,等待 Ray 集群处于卡住状态的功能

在以前的版本中,当在不安全的 OpenShift 集群中从笔记本运行分布式数据科学工作负载时,在继续(cluster.wait_ready ())之前,等待 Ray 集群就绪的功能也会卡住。这个问题现已解决。

RHOAIENG-2312 - 导入 numpy 在 code-server 工作台中失败

在以前的版本中,如果您尝试导入 numpy,则 code-server workbench 将失败。这个问题现已解决。

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

在以前的版本中,如果您尝试使用 Firefox 在 Linux 上使用 Firefox 创建调度运行的管道,启用 End Date 参数会导致日期和时间 不是数字 (Nan)值。这个问题现已解决。

RHOAIENG-1196 (之前记录的为 ODH-DASHBOARD-2140)- 仪表板中显示的软件包版本与已安装的版本不匹配

在以前的版本中,仪表板会显示不正确的软件包版本号,如 JupterLab 和 Notebook。这个问题现已解决。

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

在以前的版本中,您无法使用默认管道服务帐户创建 Ray 集群。这个问题现已解决。

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

在以前的版本中,如果您使用自签名证书,且您在笔记本或 Python 脚本中使用 Python codeflare-sdk,则令牌身份验证将失败。这个问题现已解决。

rhoAIENG-7312 - 模型服务在带有 KServe 中的令牌身份验证查询过程中失败

在以前的版本中,如果您在 DataScienceCluster 对象中同时启用了 ModelMesh 和 KServe 组件,并添加了 Authorino 作为授权供应商,则可能会出现导致 odh-model-controller pod 处于 ModelMesh 状态但不适用于 KServe 和 Authorino 的竞争条件。在这种情况下,如果您向使用 KServe 部署的运行模型发出推测请求,您会看到 404 - Not Found 错误。另外,odh-model-controller 部署对象的日志会显示 Reconciler 错误消息。这个问题现已解决。

RHOAIENG-7181 (以前称为 RHOAIENG-6343)- 安装 OpenShift AI 后一些组件被设置为 Removed

在以前的版本中,安装 OpenShift AI 后,codeflaremanagementState 字段、kueueray 组件被错误地设置为 Removed,在 DataScienceCluster 自定义资源中被错误地设置为 Removed。这个问题现已解决。

RHOAIENG-7079 (以前称为 RHOAIENG-6317)- Pipeline 任务状态和日志有时不会在 OpenShift AI 仪表板中显示

在以前的版本中,当使用 Elyra 运行管道时,OpenShift AI 仪表板可能无法显示管道任务状态和日志,即使相关的 pod 没有被修剪,且信息仍在 OpenShift 控制台中可用。这个问题现已解决。

RHOAIENG-7070 (以前称为 RHOAIENG-6709)- 当指定不同的环境变量时,Jupyperbook 创建可能会失败

在以前的版本中,如果您启动并停止 Jupyter 笔记本,并在 OpenShift AI workbench 中编辑其环境变量,笔记本无法重启。这个问题现已解决。

rhoAIENG-6853 - 在 Elyra 管道 pod 中无法设置 pod 容限

在以前的版本中,如果您为 Elyra pipeline pod 设置 pod 容限,则容限不会生效。这个问题现已解决。

RHOAIENG-5314 - 由于网络策略,数据科学管道服务器无法在全新的集群中部署

在以前的版本中,如果您在新集群中创建了数据科学管道服务器,用户界面会保持在加载状态,且管道服务器没有启动。这个问题现已解决。

RHOAIENG-4252 - 数据科学管道服务器删除过程无法删除 ScheduledWorkFlow 资源

在以前的版本中,管道服务器删除过程不会删除 ScheduledWorkFlow 资源。因此,新的 DataSciencePipelinesApplications (DSPAs)无法识别冗余的 ScheduledWorkFlow 资源。这个问题现已解决

RHOAIENG-3411 (以前记录的为 RHOAIENG-3378)- 内部镜像 Registry 是 Jupyter 笔记本生成的未决定性依赖项

在以前的版本中,在启动 OpenShift AI 笔记本和工作台前,您必须在 OpenShift 中启用了内部集成的容器镜像 registry。在不首先启用镜像 registry 时尝试启动笔记本或工作台会失败,并显示 "InvalidImageName" 错误。现在,您可以在 OpenShift AI 中创建和使用工作台,而无需启用内部 OpenShift 镜像 registry。如果更新集群以启用或禁用内部镜像 registry,则必须重新创建现有的工作台才能使 registry 生效。

RHOAIENG-2541 - KServe 控制器 pod 遇到 OOM,因为集群中的 secret 数量太多

在以前的版本中,如果您的 OpenShift 集群有大量 secret,KServe 控制器 pod 可能会因为内存不足(OOM)错误而持续崩溃。这个问题现已解决。

RHOAIENG-1452 - Red Hat OpenShift AI Add-on 会卡住

在以前的版本中,当安装通过 OCM API 触发时,Red Hat OpenShift AI Add-on 卸载不会删除 OpenShift AI 组件。这个问题现已解决。

RHOAIENG-307 - 删除 DataScienceCluster 会删除所有 OpenShift Serverless CR

在以前的版本中,如果您删除了 DataScienceCluster 自定义资源(CR),则所有 OpenShift Serverless CR (包括 knative-serving、Deployment、gateway 和 pod)也会被删除。这个问题现已解决。

RHOAIENG-6709 - 当指定不同的环境变量时,Jupyter 笔记本创建可能会失败

在以前的版本中,如果您启动并停止 Jupyter 笔记本,并在 OpenShift AI workbench 中编辑其环境变量,笔记本无法重启。这个问题现已解决。

RHOAIENG-6701 - 没有集群管理员特权的用户无法访问 Ray 仪表板的作业提交端点

在以前的版本中,没有 OpenShift 的集群管理员特权的分布式工作负载功能用户可能无法访问或使用 Ray 仪表板的作业提交端点。这个问题现已解决。

RHOAIENG-6578 - 在默认情况下没有令牌到受保护的 inference 点的请求

在以前的版本中,如果您将 Authorino 添加为单型号服务平台的授权供应商,并且为部署的模型启用了令牌授权,那么仍然可以在没有指定令牌的情况下查询模型。这个问题现已解决。

RHOAIENG-6343 - 安装 OpenShift AI 后,一些组件被设置为 Removed

在以前的版本中,安装 OpenShift AI 后,codeflaremanagementState 字段、kueueray 组件被错误地设置为 Removed,在 DataScienceCluster 自定义资源中被错误地设置为 Removed。这个问题现已解决。

RHOAIENG-5067 - 基于 ModelMesh 组件的模型服务器加载模型服务器

在以前的版本中,包含大写字母或空格的数据科学项目名称可能会导致基于 ModelMesh 组件的模型服务器指标页面出现问题。指标页面可能无法正确接收数据,从而导致 400 Bad Request 错误,并阻止页面加载。这个问题现已解决。

rhoAIENG-4966 - 自定义 CA 捆绑包中的自签名证书可能缺少在 odh-trusted-ca-bundle 配置映射中

在以前的版本中,如果您添加了自定义证书颁发机构(CA)捆绑包以使用自签名证书,有时 odh-trusted-ca-bundle ConfigMap 中缺少自定义证书,或者在 ConfigMap 设置为 受管 时不包含 odh-trusted-ca-bundle ConfigMap。这个问题现已解决。

RHOAIENG-4938 (之前记录的为 RHOAIENG-4327)- Workbenches 不使用集中配置的捆绑包中的自签名证书

在 OpenShift AI、ca-bundle.crtodh-ca-bundle.crt 中包含自签名证书有两个捆绑包选项。在以前的版本中,工作台不会自动使用来自集中配置的捆绑包的自签名证书,您必须定义指向证书路径的环境变量。这个问题现已解决。

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-4524 - RStudio 镜像的 BuildConfig 定义包含错误的分支

在以前的版本中,RStudioCUDA - RStudio 工作台镜像的 BuildConfig 定义指向 OpenShift AI 中错误的分支。这个问题现已解决。

rhoAIENG-3963 - Unnecessary 受管资源警告

在以前的版本中,当编辑并保存 redhat-ods-applications 项目的 OdhDashboardConfig 自定义资源时,系统会错误地显示 Managed 资源 警告消息。这个问题现已解决。

rhoAIENG-2542 - Inference 服务 pod 并不总是获得 Istio sidecar

在以前的版本中,当使用单模式服务平台(它使用 KServe)部署模型时,生成的 pod 中可能会缺少 istio-proxy 容器,即使 inference 服务具有 sidecar.istio.io/inject=true 注解。这个问题现已解决。

RHOAIENG-1666 - 导入管道按钮被预先访问

在以前的版本中,当您将管道导入到属于数据科学项目的工作台时,可以在管道服务器完全可用前访问 Import Pipeline 按钮。这个问题现已解决。

RHOAIENG-673 (之前记录的为 RHODS-12946)- 无法在断开连接的环境中从 PyPI 镜像安装或使用私有证书

在断开连接的环境中,Red Hat OpenShift AI 无法连接到面向公共的 PyPI 存储库,因此您必须在网络中指定存储库。在以前的版本中,如果您使用私有 TLS 证书,且数据科学管道被配置为安装 Python 软件包,则管道运行会失败。这个问题现已解决。

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-556 - 无论错误是什么,都为 KServe 模型创建 ServingRuntime

在以前的版本中,当您试图部署 KServe 模型并出现错误时,Infe renceService 自定义资源(CR)仍然被创建,且在 Data Science Projects 页面中显示模型,但状态始终会保持未知。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 运行时环境中启用了身份验证时才发生。这个问题现已解决。

RHOAIENG-535 - 如果没有 HTTP 请求,显示已部署模型的 HTTP 请求的指标图不正确

在以前的版本中,如果部署的模型没有为每个数据类型(成功和失败)都至少收到一个 HTTP 请求,则显示 HTTP 请求性能指标(用于模型服务器或特定模型的所有模型)的图表错误地呈现,直接代表失败请求的数量。这个问题现已解决。

RHOAIENG-1467 - Serverless net-istio 控制器 pod 可能达到 OOM

在以前的版本中,Knative net-istio-controller pod (这是 KServe 的依赖项)可能会因为内存不足(OOM)错误而持续崩溃。这个问题现已解决。

RHOAIENG-1899 (之前记录的为 RHODS-6539)- Anaconda 专业版无法验证并启用

在以前的版本中,您无法启用 Anaconda 专业版,因为仪表板的密钥验证是不可操作的。这个问题现已解决。

RHOAIENG-2269 -(Single-model) Dashboard 无法显示正确的模型副本数

在以前的版本中,在单型号服务平台上,数据科学项目的 Models 和 model servers 部分没有显示正确的模型副本数量。这个问题现已解决。

RHOAIENG-2270 -(Single-model)用户无法更新模型部署设置

在以前的版本中,您无法编辑使用单模式服务平台部署的模型的部署设置(如副本数)。这个问题现已解决。

rhoDS-8865 - 管道服务器无法启动,除非您指定了 Amazon Web Services (AWS) Simple Storage Service (S3)存储桶资源

在以前的版本中,当您为数据科学项目创建数据连接时,AWS_S3_BUCKET 字段不会被指定为必需的字段。但是,如果您试图使用 AWS_S3_BUCKET 字段没有填充的数据连接配置管道服务器,管道服务器将无法成功启动。这个问题现已解决。Configure pipeline server 对话框已更新,将 Bucket 字段包含为必填字段。

rhoDS-12899 - OpenVINO 运行时缺少 NVIDIA GPU 注解

在以前的版本中,如果用户选择了 OpenVINO 模型服务器(支持 GPU) 运行时并在模型服务器用户界面中选择了 NVIDIA GPU 加速器,则系统可能会显示与所选运行时不兼容的不必要的警告。警告将不再显示。

RHOAIENG-84 - 无法使用带有 KServe 的自签名证书

在以前的版本中,单模式服务平台不支持自签名证书。这个问题现已解决。要将自签名证书与 KServe 一起使用,请按照 使用证书 中介绍的步骤 操作

RHOAIENG-164 - 从仪表板中无法正确应用 Kserve 的模型服务器副本数

在以前的版本中,当您设置与默认的(1)不同的多个模型服务器副本时,模型(server)仍然使用 1 个副本部署。这个问题现已解决。

RHOAIENG-288 - 有两个版本显示了工作台的建议镜像版本标签

OpenShift AI 中提供的大多数工作台镜像都在多个版本中都提供了。唯一推荐的版本是最新版本。在 Red Hat OpenShift AI 2.4 和 2.5 中,对于镜像的多个版本,推荐的 标签被错误地显示。这个问题现已解决。

RHOAIENG-293 - 从 2.4 升级到 2.5 后不会删除已弃用的 ModelMesh 监控堆栈

在 Red Hat OpenShift AI 2.5 中,以前的 ModelMesh 监控堆栈不再被用户工作负载监控替代。但是,在升级到 OpenShift AI 2.5 的过程中不会删除以前的监控堆栈。有些组件保留并使用集群资源。这个问题现已解决。

RHOAIENG-343 - OpenShift Service Mesh 的手动配置,OpenShift Serverless 无法用于 KServe

如果安装了 OpenShift Serverless 和 OpenShift Service Mesh,然后安装了启用了 KServe 的 Red Hat OpenShift AI,则不会部署 KServe。这个问题现已解决。

RHOAIENG-517 - 具有编辑权限的用户无法看到创建模型

具有编辑权限的用户无法看到任何创建的模型,除非他们是项目所有者或具有项目的 admin 权限。这个问题现已解决。

RHOAIENG-804 - 无法在启用了 FIPS 的集群上使用 KServe 部署大型语言模型

在以前的版本中,Red Hat OpenShift AI 还没有完全为 FIPS 设计。您不能在启用了 FIPS 的集群中使用 KServe 部署大语言模型(LLMs)。这个问题现已解决。

rhOAIENG-908 - 如果之前启用了 KServe,则无法使用 ModelMesh,然后删除

在以前的版本中,当在 DataScienceCluster 对象中启用 ModelMesh 和 KServe 时,您随后删除了 KServe,则无法使用 ModelMesh 部署新模型。您可以继续使用之前使用 ModelMesh 部署的模型。这个问题现已解决。

RHOAIENG-2184 - 无法创建 Ray 集群或分布式工作负载

在以前的版本中,用户无法在具有 adminedit 权限的命名空间中创建 Ray 集群或分布式工作负载。这个问题现已解决。

ODH-DASHBOARD-1991 - ovms-gpu-ootb 缺少推荐的加速器注解

在以前的版本中,当您在项目中添加模型服务器时,Serving 运行时 列表不会显示 NVIDIA GPU 的推荐服务运行时 标签。这个问题现已解决。

RHOAIENG-807 - 重启工作台时删除加速器配置集容限

在以前的版本中,如果您创建了一个工作台,它使用一个包括容限的加速器配置集,重启工作台会删除容限信息,这意味着重启无法完成。新创建的启用了 GPU 的工作台可能会首次启动,但永远不会成功重启,因为生成的 pod 会一直处于待处理状态。这个问题现已解决。

DATA-SCIENCE-PIPELINES-OPERATOR-294 - Scheduled 管道运行(使用 data-passing)可能无法在步骤间传递数据,或者完全失败步骤

使用 S3 对象存储来存储管道工件的调度管道运行可能会失败,并显示以下错误:

Bad value for --endpoint-url "cp": scheme is missing. Must be of the form http://<hostname>/ or https://<hostname>/

出现这个问题的原因是 S3 对象存储端点没有成功传递给调度的管道运行的 pod。这个问题现已解决。

RHODS-4769 - 具有不支持污点的节点上的 GPU 无法分配给笔记本服务器

在创建笔记本服务器时,无法选择带有除 supported nvidia.com/gpu 污点的节点上的 GPU。这个问题现已解决。

RHODS-6346 - 使用无效字符创建数据科学项目时会显示 Unclear 错误消息

当使用无效特殊字符创建数据科学项目的数据连接、工作台或存储连接时,会显示以下出错信息:

the object provided is unrecognized (must be of type Secret): couldn't get version/kind; json parse error: unexpected end of JSON input ({"apiVersion":"v1","kind":"Sec ...)

错误消息未能明确指示问题。错误消息现在表示输入无效字符。

RHODS-6950 - 使用集群中的所有 GPU 时无法缩减工作台 GPU

在早期版本中,如果使用集群中的所有 GPU,则无法缩减工作台 GPU。这个问题适用于一个工作台使用的 GPU,以及由多个工作台使用的 GPU。现在,您可以通过从 Accelerators 列表中选择 None 来缩减 GPU。

rhODS-8939 - 上一发行版本中创建的 Jupyter 笔记本的默认共享内存会导致运行时错误

从版本 1.31 开始,这个问题已被解决,任何新笔记本的共享内存被设置为节点的大小。

对于在早于 1.31 的发行版本中创建的 Jupyter 笔记本,Jupyter 笔记本的默认共享内存被设置为 64 MB,您无法在笔记本配置中更改此默认值。

要解决这个问题,您必须重新创建笔记本,或按照知识库文章 如何更改 Red Hat OpenShift AI 中的 Jupyter 笔记本的共享内存

rhoDS-9030 - 删除 kfdefs 资源时 OpenShift AI 的卸载过程可能会卡住

卸载 OpenShift AI 托管服务的步骤请参考 卸载 OpenShift AI

但是,即使您遵循本指南,您可能已经看到卸载过程没有成功完成。相反,进程会保留在删除 Kubeflow Operator 使用的 kfdefs 资源的步骤。如以下示例所示,kfdefs 资源可能存在于 redhat-ods-applications, redhat-ods-monitoring, 和 rhods-notebooks 命名空间中:

$ oc get kfdefs.kfdef.apps.kubeflow.org -A

NAMESPACE                  NAME                                   AGE
redhat-ods-applications    rhods-anaconda                         3h6m
redhat-ods-applications    rhods-dashboard                        3h6m
redhat-ods-applications    rhods-data-science-pipelines-operator  3h6m
redhat-ods-applications    rhods-model-mesh                       3h6m
redhat-ods-applications    rhods-nbc                              3h6m
redhat-ods-applications    rhods-osd-config                       3h6m
redhat-ods-monitoring      modelmesh-monitoring                   3h6m
redhat-ods-monitoring      monitoring                             3h6m
rhods-notebooks            rhods-notebooks                        3h6m
rhods-notebooks            rhods-osd-config                       3h5m

删除 kfdefs 资源失败可能会阻止以后安装 OpenShift AI。这个问题不再发生。

rhoDS-9764 - 编辑工作台时数据连接详情会被重置

当您编辑了具有现有数据连接的工作台,然后选择 Create new data connection 选项时,编辑页面可能会在指定新的连接详情前恢复到 Use existing data connection 选项。这个问题现已解决。

rhoDS-9583 - Data Science 仪表板没有检测到现有的 OpenShift Pipelines 安装

当 OpenShift Pipelines Operator 作为全局 Operator 安装在集群中时,OpenShift AI 仪表板不会检测到它。OpenShift Pipelines Operator 现在可以成功检测到。

ODH-DASHBOARD-1639 - 在仪表板路由中 Wrong TLS 值

在以前的版本中,当在 OpenShift 上为 OpenShift AI 仪表板创建路由时,tls.termination 字段具有无效的默认值 Reencrypt。这个问题现已解决。新值为 reencrypt

ODH-DASHBOARD-1638 - Triggered Runs 选项卡中的 Name placeholder shows Scheduled run name

在以前的版本中,当点 Pipelines > Runs,然后选择 Triggered 选项卡来配置触发的运行时,Name 字段中显示的示例值为 Scheduled run 名称。这个问题现已解决。

ODH-DASHBOARD-1547 - "We could't find that page" 消息在后台安装管道 operator 时显示在仪表板中

在以前的版本中,当使用仪表板的 Data Science Pipelines 页面安装 OpenShift Pipelines Operator 时,当 Operator 安装完成后,刷新的页面以显示 我们无法找到该页面 信息。这个问题现已解决。Operator 安装完成后,仪表板会将您重定向到 Pipelines 页面,您可以在其中创建管道服务器。

ODH-DASHBOARD-1545 - 当 Models 选项卡扩展时,仪表板会保持滚动到项目底部

在以前的版本中,在仪表板的 Data Science Projects 页面中,如果您点击 Deployed models 选项卡来扩展它,然后尝试对页面执行其他操作,页面会自动滚动到 Deployed models 部分。这会影响您执行其他操作的能力。这个问题现已解决。

注意BOOKS-156 - Elyra 包括一个称为 Test 的示例运行时

在以前的版本中,Elyra 包括一个示例运行时配置,称为 Test。如果在运行数据科学项目时选择了此配置,您可能会看到错误。Test 配置现已被删除。

rhODS-9622 - Duplicating a scheduled 管道运行不会复制现有的 period 和 pipeline 输入参数值

在以前的版本中,当复制带有定期触发器的调度的管道运行时,重复过程不会为重复运行或指定的管道输入参数复制配置的执行频率。这个问题现已解决。

rhoDS-8932 - 在调度重复管道运行时默认会显示不正确的 cron 格式

当您通过配置 cron 任务调度周期性管道运行时,OpenShift AI 接口默认显示不正确的格式。它现在显示正确的格式。

RHODS-9374 - 带有非唯一名称的管道不会出现在数据科学项目用户界面中

如果您从支持 Elyra 的 Jupyter 应用程序启动笔记本,或者提交一个工作台时,带有非唯一名称的管道不会出现在相关数据科学项目页面的 Pipelines 部分或 data Science 管道标题的 Pipelines 标题中。这个问题现已解决。

RHODS-9329 - 部署自定义 model-serving 运行时可能会导致错误消息

在以前的版本中,如果您使用 OpenShift AI 仪表板部署自定义 model-serving 运行时,部署过程可能会失败,并显示 Error retrieve Serving Runtime 信息。这个问题现已解决。

rhODS-9064 - 升级后,OpenShift AI 仪表板中没有启用 Data Science Pipelines 选项卡

当您从 OpenShift AI 1.26 升级到 OpenShift AI 1.28 时,OpenShift AI 仪表板中没有启用 Data Science Pipelines 选项卡。这个问题已在 OpenShift AI 1.29 中解决。

RHODS-9443 - 导出 Elyra 管道以纯文本形式公开 S3 存储凭证

在 OpenShift AI 1.28.0 中,当您以 Python DSL 格式或 YAML 格式从 JupyterLab 导出 Elyra 管道时,生成的输出以纯文本形式包含 S3 存储凭证。这个问题已在 OpenShift AI 1.28.1 中解决。但是,在升级到 OpenShift AI 1.28.1 后,如果您的部署包含带有管道服务器和数据连接的数据科学项目,您必须执行以下附加操作才能使修复生效:

  1. 刷新浏览器页面。
  2. 停止部署中运行的工作台,然后重新启动它们。

另外,要确认您的 Elyra 运行时配置包含该修复,请执行以下操作:

  1. 在 JupyterLab 的左侧边栏中,点 Runtimes ( The Runtimes icon )。
  2. 将光标悬停在您要查看的运行时配置上,并点击 Edit 按钮( Edit runtime configuration )。

    Data Science Pipelines 运行时配置页面将打开。

  3. 确认 KUBERNETES_SECRET 定义为 Cloud Object Storage Authentication Type 字段中的值。
  4. 关闭运行时配置而不更改它。

RHODS-8460 - 编辑共享项目详情时,用户界面会一直处于加载状态,而不会报告错误

当具有编辑项目权限的用户试图编辑其详情时,用户界面会保持在加载状态,且没有显示适当的错误消息。具有编辑项目权限的用户无法编辑项目中的任何字段,如描述。这些用户只能编辑属于项目的组件,如其工作台、数据连接和存储。

用户界面现在显示适当的错误消息,且不会尝试更新项目描述。

rhoDS-8482 - Data Science pipeline 图没有显示运行管道的节点边缘

如果您在其 YAML 代码中运行不包含 Tekton 格式的参数或 when 表达式的管道,OpenShift AI 用户界面不会显示与图形节点的连接边缘。例如,如果您使用包含 runAfter 属性或 Workspaces 的管道,用户界面在没有边缘连接的情况下显示所执行管道的图形。OpenShift AI 用户界面现在显示连接到图形节点的边缘。

RHODS-8923 - 当您试图创建管道服务器时不会检测到新创建的数据连接

如果您在 Data Science 项目中创建了数据连接,然后尝试创建管道服务器,则 Configure a pipeline server 对话框不会检测到您创建的数据连接。这个问题现已解决。

rhoDS-8461 - 当与其他用户共享项目时,OpenShift AI 用户界面文本是误导

当您试图与另一个用户共享 Data Science 项目时,用户界面文本会错误地表示用户可以编辑其所有详情,如描述。但是,用户只能编辑属于某一项目的组件,如其工作台、数据连接和存储。这个问题现已解决,用户界面文本不再有误导,这意味着用户可以编辑所有详情。

rhoDS-8462 - 具有"Edit"权限的用户无法创建模型服务器

具有 "Edit" 权限的用户现在可以创建一个没有令牌授权的 Model Server。用户必须具有"Admin"权限,才能创建具有令牌授权的 Model Server。

rhODS-8796 - OpenVINO Model Server 运行时没有强制 GPU 使用所需的标记

OpenShift AI 默认包括 OpenVINO Model Server (OVMS)模型运行时。当您配置新的模型服务器并选择这个运行时时,配置模型服务器 对话框可让您指定要与模型服务器一起使用的 GPU 数。但是,当您完成配置模型服务器并从中部署模型时,模型服务器实际上没有使用任何 GPU。这个问题现已解决,模型服务器使用 GPU。

rhoDS-8861 - 在创建管道运行时更改主机项目会导致可用管道列表不准确

如果您在创建管道运行时更改了主机项目,接口将无法使新主机项目的管道可用。相反,接口会显示属于您最初在 Data Science Pipelines > Runs 页面中选择的项目的管道。这个问题现已解决。您不再从 Create run 页面中选择一个管道。当您点 Create run 按钮(基于当前项目及其管道)时,管道选择会自动更新。

RHODS-8249 - 作为 ConfigMap 上传的环境变量被存储在 Secret 中

在以前的版本中,在 OpenShift AI 界面中,当您通过上传 ConfigMap 配置将环境变量添加到工作台时,变量会改为存储在 Secret 对象中。这个问题现已解决。

RHODS-7975 - Workbenches 可以有多个数据连接

在以前的版本中,如果您更改了工作台的数据连接,则现有数据连接不会被释放。因此,工作台可能会保持连接到多个数据源。这个问题现已解决。

rhoDS-7948 - 上传包含环境变量的 secret 文件会导致双编码值

在以前的版本中,当在数据科学项目中创建工作台时,如果您上传了一个包含环境变量的基于 YAML 的 secret 文件,则环境变量值不会被解码。然后,在由此过程创建的生成的 OpenShift 机密中,编码的值会再次编码。这个问题现已解决。

RHODS-6429 - 使用 Intel OpenVINO 或 Anaconda 专业版镜像创建工作台时会显示一个错误

在以前的版本中,当使用 Intel OpenVINO 或 Anaconda 专业版镜像创建工作台时,创建过程中会出现一个错误。但是,工作台仍然成功创建。这个问题现已解决。

rhODS-6372 - Idle notebook culler 没有考虑活跃的终端

在以前的版本中,如果笔记本镜像有一个正在运行的终端,但没有活跃的、运行内核,空闲的 notebook culler 会将笔记本检测到为不活跃并停止终端。这个问题现已解决。

RHODS-5700 - 创建工作台时无法创建或连接到数据连接

在创建工作台时,用户无法创建新数据连接,或者连接到现有数据连接。

RHODS-6281 - 如果从集群中删除了 admin 组,则 OpenShift AI 管理员无法访问 Settings 页面

在以前的版本中,如果从集群中删除 Red Hat OpenShift AI 管理员组,OpenShift AI 管理员用户无法访问 OpenShift AI 仪表板中的 Settings 页面。特别是,可以看到以下行为:

  • 当 OpenShift AI 管理员用户试图访问 Settings User management 页面时,会出现 "Page Not Found" 错误。
  • 集群管理员 不会丢失 对 OpenShift AI 仪表板上的 Settings 页面的访问。当集群管理员访问 Settings User Management 页面时,会出现警告消息,表示 OpenShift 中不再存在已删除的 OpenShift AI 管理员组。然后,删除的管理员组已从 OdhDashboardConfig 中删除,并且恢复了管理员访问权限。

这个问题现已解决。

rhODS-1968 - 删除的用户会一直登录,直到刷新仪表板为止

在以前的版本中,当用户撤销 Red Hat OpenShift AI 仪表板的权限时,用户只有在仪表板页面刷新后才会注意到更改。

这个问题现已解决。当用户的权限被撤销时,OpenShift AI 仪表板会在 30 秒内锁定用户,而无需刷新。

RHODS-6384 - 创建重复数据连接时,工作台数据连接被错误地更新

在创建包含与现有数据连接相同的数据连接时,数据连接创建会失败,但相关的工作台仍然会重启并连接到错误的数据连接。这个问题已解决。现在,工作台连接到正确的数据连接。

rhoDS-6370 - Workbenches 无法接收最新的容限

在以前的版本中,若要获取最新的容限,用户必须尝试编辑相关的工作台,不进行任何更改,然后再次保存工作台。现在,用户可以通过停止,然后重启其数据科学项目的工作台来应用最新的容限更改。

RHODS-6779 - 从 OpenShift AI 1.20 升级到 OpenShift AI 1.21 后模型无法提供

当从 OpenShift AI 1.20 升级到 OpenShift AI 1.21 时,modemesh-serving pod 会尝试拉取不存在的镜像,从而导致镜像拉取错误。因此,无法使用 OpenShift AI 中的模型服务功能提供模型。odh-openvino-servingruntime-container-v1.21.0-15 镜像现在可以成功部署。

RHODS-5945 - OpenShift AI 中无法启用 Anaconda 专业版

在 OpenShift AI 中无法启用 Anaconda 专业版。相反,关联的 pod 的 Events 页面中会显示 InvalidImageName 错误。Anaconda 专业版现在可以成功启用。

RHODS-5822 - 当数据科学项目创建的 PVC 超过 90% 和 100% 时,管理员用户不会被警告。

当 PVC 超过其容量的 90% 和 100% 时,未能向 admin 用户显示由数据科学项目创建的 PVC 的警告。管理员用户现在可以查看当 PVC 超过 90% 和从仪表板中其容量的 100% 时的警告。

RHODS-5889 - 如果数据科学笔记本处于"pending"状态,则不会显示 Error 信息

如果无法创建笔记本 pod,OpenShift AI 接口不会显示错误消息。现在,如果无法生成数据科学笔记本,则会显示错误消息。

rhODS-5886 - 从数据科学工作台返回 Hub Control Panel 仪表板失败

如果您试图通过点 File Log Out,从工作台 Jupyter 笔记本返回仪表板,您将被重定向到仪表板并保持在"Logging out"页面。同样,如果您尝试通过点 File Hub Control Panel 以返回仪表板,则您会错误地重定向到 启动笔记本服务器页面。从数据科学工作台返回 Hub Control Panel 仪表板现在可以按预期工作。

rhoDS-6101 - 管理员无法停止所有笔记本服务器

OpenShift AI 管理员无法同时停止所有笔记本服务器。管理员现在可以使用 Stop all servers 按钮停止所有笔记本服务器,并通过从相关用户旁的操作菜单中选择 Stop server 来停止单个笔记本。

RHODS-5891 - Workbench 事件日志没有明确可见

在创建工作台时,用户无法在 OpenShift AI 界面中轻松找到事件日志窗口。现在,当您将鼠标悬停在其中时,Status 列下的 Starting 标签是下划线的,这表示您可以点它来查看笔记本状态和事件日志。

rhODS-6296 - 使用 Google Chrome 以外的浏览器时,ISV 图标不会被显示

当使用 Google Chrome 以外的浏览器时,不会呈现 ExploreResources 页面下的所有 ISV 图标。ISV 图标现在在所有支持的浏览器中正确显示。

rhODS-3182 - Jupyter 中显示了可用 GPU 的数量

当用户试图在 Jupyter 中创建 notebook 实例时,不会更新用于调度的最大 GPU 数,因为分配了 GPU。Jupyter 现在显示可用 GPU 的正确数量。

RHODS-5890 - 当多个持久性卷挂载到同一目录中时,工作台无法启动

当在同一工作台中将多个持久性卷 (PV) 挂载到同一工作台中的同一挂载文件夹时,创建笔记本 pod 会失败且没有显示错误来指示问题。

RHODS-5768 - Data Science 项目对 Red Hat OpenShift AI 中的用户不可见

在项目的 Display Name 属性末尾删除 [DSP] 后缀会导致相关的数据科学项目不再可见。用户无法再删除此后缀。

rhoDS-5701 - 数据连接配置详情被覆盖

当数据连接添加到工作台时,这些数据连接的配置详情会保存在环境变量中。添加第二个数据连接时,配置详情使用相同的环境变量保存,这意味着覆盖第一个数据连接的配置。目前,用户可以为每个工作台添加一个数据连接。

RHODS-5252 - 笔记本管理页面没有为用户提供笔记本服务器的管理员访问权限

从 OpenShift AI 仪表板访问的笔记本管理页面没有提供管理员访问用户笔记本服务器的方法。管理员仅限于启动或停止用户笔记本服务器。

RHODS-2438 - 升级时PyT 和 TensorFlow 镜像不可用

当从 OpenShift AI 1.3 升级到更新的版本时,PyTorch 和 TensorFlow 镜像在大约 30 分钟不可用。因此,在升级过程中,用户无法在 Jupyter 中启动 PyTorch 和 TensorFlow 笔记本。这个问题现已解决。

rhODS-5354 - 启动笔记本服务器时环境变量名称不会被验证

启动笔记本服务器页面中不会验证环境变量名称。如果添加了无效的环境变量,用户无法成功启动笔记本。环境变量名称现在会实时检查。如果输入了无效的环境变量名称,则会显示错误消息表示有效环境变量名称必须包含字母字符、数字、_, -, 或 .,且不得以数字开头。

rhoDS -4617 - 只有在 GPU 可用时才会看到 GPU 数

在以前的版本中,只有 GPU 节点可用时,在 启动笔记本服务器页面 中才会显示 GPU 数。现在,当一个自动扩展集群池在集群中定义,即使当前还没有 GPU 节点可用(这可能会在集群中置备新的 GPU 节点),GPU 的数量 下拉菜单也会正确显示,。

RHODS-5420 - 如果集群管理员是集群中唯一用户,则不会获得管理员访问权限

在以前的版本中,当集群管理员是集群中唯一存在的用户时,它不会自动获得 Red Hat OpenShift 管理员访问权限。管理员访问权限现在可以正确地分配给管理员用户。

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

启动一个笔记本服务器页面为 CUDA 笔记本镜像显示了一个不正确的版本号(11.4 而不是 11.7)。在此页面中不再指定安装的 CUDA 版本。

rhODS-5001 - 管理员用户可以向笔记本 pod 添加无效的容限

admin 用户可以在 Cluster settings 页面中添加非合规容限,而无需触发错误。如果添加了非合规容限,用户无法成功启动笔记本。现在,容限键会实时检查。如果输入了无效的容限名称,则会显示错误消息表示有效容限名称由字母数字字符(-, _, 或 .)组成,必须以字母数字字符开头并以字母数字字符结尾。

RHODS-5100 - 组角色绑定没有应用到集群管理员

在以前的版本中,如果您为组而非特定用户分配了集群管理特权,控制面板无法识别管理组中的用户管理特权。现在,组角色绑定可以正确地应用到集群管理员。

rhoDS-4947 - Old Minimal Python 笔记本镜像在升级后保留

从 OpenShift AI 1.14 升级到 1.15 后,Minimal Python 笔记本的旧版本会保留,包括所有关联的软件包版本。升级后,Minimal Python 笔记本的旧版本不再保留。

rhoDS-4935 - Excessive "missing x-forwarded-access-token header" 错误信息显示在仪表板日志中

因为就绪度探测达到 /status 端点,rhods-dashboard pod 的日志中会包含大量的 "missing x-forwarded-access-token header" 错误消息。这个问题现已解决。

rhoDS-2653 - 在获取示例 Pachyderm 笔记本时出现错误

当用户尝试使用 Jupyter 中的示例 Pachyderm 笔记本获取镜像时会出现一个错误。指示镜像无法找到的错误。Pachyderm 解决了这个问题。

rhoDS-4584 - Jupyter 无法使用 OpenVINO 笔记本镜像启动笔记本服务器

Jupyter 的启动一个笔记本服务器页无法使用 OpenVINO 笔记本镜像启动笔记本服务器。Intel 已经为 OpenVINO 操作器提供了一个更新来更正此问题。

rhoDS-4923 - 禁用使用数据收集后显示的非标准复选框

Cluster settings 页面中禁用使用数据收集后,当用户访问 OpenShift AI 仪表板的另一个区域,然后返回到 Cluster settings 页面,允许收集使用数据 复选框应用了非标准类型,因此在选择或清除时不会与其他复选框相同。

rhoDS-4938 - 在 Notebook Images 页面中显示不正确的标题

在 OpenShift AI 仪表板上的 Settings 页面中访问 Notebook Images 页面,在用户界面中显示不正确的标题。Notebook image settings 的标题显示 BYON image settingsImport Notebook images 标题显示 Import BYON images。现在,正确的标题会显示如预期。

rhODS-4818 - Jupyter 在安装了 NVIDIA GPU 附加组件时无法显示镜像

在安装 NVIDIA GPU 附加组件后,启动笔记本服务器页面不会显示笔记本镜像。现在,镜像会被正确显示,可以从启动笔记本服务器页面中启动。

rhoDS-4797 - 当用量超过 90% 和 100% 时,PVC 使用限制警报不会被发送

当 PVC 超过容量的 90% 和 100% 时,未能触发和发送相关的警报。现在,这些警告会按预期触发并发送。

rhODS-4366 - 集群设置在 operator 重启时被重置

当 OpenShift AI operator pod 重启时,集群设置有时会重置为默认值,删除任何自定义配置。当发布新版本的 OpenShift AI 以及运行 Operator 的节点失败时,OpenShift AI operator 会被重启。出现这个问题的原因是 Operator 部署的 ConfigMap 不正确。Operator 部署已被更新,这个问题不再会发生。

rhoDS-4318 - OpenVINO 笔记本镜像无法成功构建

OpenVINO notebook 镜像未能成功构建并显示错误消息。这个问题现已解决。

RHODS-3743 - Starburst Galaxy 快速启动没有在指令步骤中提供下载链接

Starburst Galaxy 快速启动(位于仪表板上的 Resources 页面中),要求用户打开 explore-data.ipynb notebook,但无法提供指令步骤中的链接。相反,链接是在快速启动的介绍中提供的。

rhoDS-1974 - 更改警报通知电子邮件所需的 pod 重启

rhods-operator pod 和 prometheus114 pod 重启后,不会应用 Red Hat OpenShift AI Add-On 中的通知电子邮件 地址列表的更改。

RHODS-2738 - Red Hat OpenShift API Management 1.15.2 附加组件安装无法成功完成

对于与 Red Hat OpenShift API Management 1.15.2 附加组件集成的 OpenShift AI 安装,Red Hat OpenShift API Management 安装过程无法成功获取 SMTP 凭证 secret。因此,安装不会完成。

RHODS-3237 - 仪表板中没有显示 GPU 教程

位于 Gtc2018-numba 的 "GPU 计算"教程不会显示在仪表板上的 Resources 页面中。

RHODS-3069 - 当 GPU 节点不可用时 GPU 选择会保留

如果用户使用 GPU 支持置备笔记本服务器,而使用的 GPU 节点随后会从集群中移除,用户就无法创建笔记本服务器。这是因为最近一次用于附加 GPU 数的设置被默认使用。

RHODS-3181 - Pachyderm 现在与 OpenShift Dedicated 4.10 集群兼容

Pachyderm 最初与 OpenShift Dedicated 4.10 不兼容,因此在 OpenShift Dedicated 4.10 集群中运行的 OpenShift AI 中不可用。Pachyderm 现在提供与 OpenShift Dedicated 4.10 兼容的版本。

RHODS-2160 - 安装 OpenShift AI 和 OpenShift API Management 时卸载过程无法完成

当 OpenShift AI 和 OpenShift API 管理在同一集群中安装时,它们使用相同的虚拟私有集群(VPC)。这些附加组件的卸载过程会尝试删除 VPC。在以前的版本中,当同时安装 Add-ons 时,一个服务的卸载过程会被阻断,因为其他服务仍有 VPC 中的资源。清理过程已更新,不会发生此冲突。

RHODS-2747 - 升级 OpenShift AI 后镜像被错误地更新

升级 OpenShift AI 后,Jupyter 无法更新其笔记本镜像。这是因为镜像缓存机制存在问题。现在,在升级后镜像会被正确更新。

RHODS-2425 - 在笔记本选择过程中显示正确 TensorFlow 和 TensorBoard 版本

Start a notebook 服务器 页面显示 TensorFlow 和 TensorBoard 在 TensorFlow 笔记本镜像中显示不正确的版本号(2.4.0)。这些版本已被修正为 TensorFlow 2.7.0 和 TensorBoard 2.6.0。

rhoDS-24339 - 启用的应用程序没有显示快速启动链接

对于一些应用程序,Open quick start 链接无法在 Enabled 页面中的应用程序标题中显示。因此,用户无法直接访问相关应用程序的快速入门。

rhODS-2215 - 在笔记本选择过程中显示不正确的 Python 版本

Start a notebook server 页面显示 TensorFlow 和 PyTorch 笔记本电脑镜像的错误版本 Python。另外,现在不再显示软件包版本号的第三个整数。

rhoDS-1977 - 在笔记本服务器启动失败后等待十分钟

在启动笔记本服务器时,如果 Jupyter leader pod 失败,该用户将无法访问其笔记本服务器,直到 pod 重启前,这需要大约 10 分钟。这个进程已被改进,以便在选择新 leader pod 时将用户重定向到其服务器。如果此过程超时,用户会看到 504 网关超时错误,并且可以刷新以访问其服务器。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.