红帽全球峰会第 2 章 发行信息 RHOSO 18.0
本发行注记重点介绍在 OpenShift (RHOSO)组件的一些或所有红帽服务中所选的更新。当您部署此 RHOSO 发行版本时，请考虑这些更新。本节中的每个备注都引用用于跟踪更新的 JIRA 问题。如果 Jira issue 安全级别是公共的，您可以点击链接来查看 JIRA 问题。如果安全级别受到限制，则 JIRA 问题 ID 没有 JIRA 问题的链接。
2.1. 发行信息 RHOSO 18.0.8
2.1.1. 公告列表
此 Red Hat OpenStack Services on OpenShift (RHOSO)发行版本包括以下公告：
- RHBA-2025:8036
- RHOSO 18.0.8 的 control plane Operator
- RHBA-2025:8037
- RHOSO 18.0.8 的数据平面 Operator
- RHBA-2025:8038
- RHOSO 18.0.8 的容器发行版本
- RHBA-2025:8039
- RHOSO 18.0.8 组件发布
2.1.2. Compute
2.1.2.1. 已知问题
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中已知的问题。
默认禁用计算服务电源管理功能
默认情况下，计算服务(nova)电源管理功能被禁用。您可以使用以下 nova-compute 配置启用它：
[libvirt] cpu_power_management = true cpu_power_management_strategy = governor
[libvirt]
cpu_power_management = true
cpu_power_management_strategy = governor
目前不支持默认的 cpu_power_management_strategy cpu_state。重启 nova-compute 会导致该主机上的所有专用 PCPU 都已关机，包括供实例使用的 PCPU。如果使用 cpu_state 策略，则这些实例的 CPU 将变为 unpinned。
2.1.3. 数据平面
2.1.3.1. 程序错误修复
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中修复的、对用户有严重影响的错误。
默认策略可确保在部署结束时重新加载 nftables
在此次更新之前，iptables 默认表被添加到 nftables 中，以确保向后兼容。但是，有一个默认的 ALLOW INPUT 规则而不是默认的 DROP 规则，且 nftables 在部署结束时不会被重新加载。在这个版本中，会应用正确的规则，以确保在部署结束时重新载入 nftables。
2.1.3.2. 已知问题
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中已知的问题。
手动将 redhat 服务添加到 data plane 服务的默认列表中
redhat 服务已从默认 data plane 服务列表中删除。因此，当将订阅或存储库附加到 Compute 节点时，在创建 data plane secret 时，节点不会被注册，data plane 部署会失败。
临时解决方案： 覆盖 OpenStackDataPlaneNodeSet CR 中的服务列表，并确保将 redhat 服务添加为列表中的第一个服务。您可以复制 Data plane 服务中 显示的默认列表，如 自定义 OpenShift 部署中的 Red Hat OpenStack Services。
2.1.4. 硬件置备
2.1.4.1. 程序错误修复
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中修复的、对用户有严重影响的错误。
带有多路径块存储的裸机数据平面节点在置备后引导
在此次更新之前，预构建的整个磁盘镜像不包括 device-mapper-multipath 软件包，这会阻止对引导 ramdisk 支持多路径块存储。这会导致带有多路径块存储的裸机节点在部署后无法引导，而是停留在紧急 shell 中。在这个版本中，预构建的整个磁盘镜像包含 device-mapper-multipath 软件包，并部署裸机节点，在部署后不再进入紧急 shell。
2.1.5. 网络
2.1.5.1. 程序错误修复
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中修复的、对用户有严重影响的错误。
现在，FRR 服务可用的日志
在此次更新之前，当 RHOSO 配置为使用带有 BGP 的动态路由时，没有可用于自由范围路由(FRR)服务的日志，该服务会在数据平面节点上部署。在这个版本中，这些日志可用。
传统的 tripleo 网络服务会在使用后移除
在此次更新之前，edpm_tripleo_cleanup 任务后有传统的 tripleo Networking 服务(neutron)服务，需要手动删除它。这些服务在采用后停止，因此 RHOSO 服务不受影响。在这个版本中，所有 tripleo Networking 服务都会在 data plane 节点上采用后移除。
2.1.5.2. 已知问题
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中已知的问题。
当外部 MTU 大于内部 MTU 时，数据包会静默丢弃
当外部 MTU 大于内部 MTU 时，RHOSO 不会按预期分段南北数据包。相反，在没有通知的情况下丢弃入口数据包。
此外，碎片不适用于租户网络之间的 east/west 流量。
在解决这些问题之前，请确保外部 MTU 设置小于或等于内部 MTU 设置，并且 east/west 路径上的所有 MTU 设置都相等。
临时解决方案：
在解决这些问题之前，请执行以下步骤以确保外部 MTU 设置小于或等于内部 MTU 设置，并且 east/west 路径上的所有 MTU 设置都相等。
-
将
ovn_emit_need_to_frag设置为true。 -
将
global_physnet_mtu设置为至少大于外部网络 MTU 的 58 字节的大小，以适应生成的隧道封装开销。 -
设置
physical_network_mtus值对，以描述每个物理网络的 MTU。 - 确保外部网络中的每个设备上的 MTU 设置小于内部 MTU 设置。
- 要将更改应用到现有的路由器，请删除路由器并重新创建它。
Example
例如，假设外部网络 datacentre MTU 是 1500。
在 OpenStackControlPlane CR 中输入以下 neutron 设置：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 确保外部网络中的每个设备上的 MTU 设置小于内部 MTU 设置。
- 确保所有使用 OVN 路由器的租户网络具有相同的 MTU。
- 要将更改应用到现有的路由器，请删除路由器并重新创建它。
端口更新删除 VLAN 或扁平网络端口的 QoS 信息
任何带有出口 QoS 策略规则（最大和/或最小带宽）的 VLAN 或扁平网络端口将此信息存储在 Logical_Switch_Port. 选项 字典中。此端口上的任何更新都会从端口名称更改为实时迁移，将删除此 QoS 信息。
临时解决方案： 要恢复 QoS 信息，您必须删除此端口的 QoS 策略，然后再次设置它。
2.1.6. 网络功能虚拟化
2.1.6.1. 已知问题
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中已知的问题。
当物理功能附加到虚拟机实例时，采用会失败
当物理功能(PF)附加到实例时，如果重新运行 os-net-config，则 os-net-config 无法找到主机中的 SR-IOV PF，因此部署、更新或采用会失败。
临时解决方案： 在执行采用或网络更新之前，请将实例迁移到另一个计算主机上。
启用 SELinux 时 NetworkManager-dispatcher 脚本无法运行
os-net-config 配置工具使用 NetworkManager-dispatcher 脚本进行驱动程序绑定。启用 SELinux 后，这些脚本无法运行，os-net-config 网络部署会失败。
临时解决方案： 目前没有临时解决方案。
2.1.7. Control plane（控制平面）
2.1.7.1. 程序错误修复
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中修复的、对用户有严重影响的错误。
部署状态准确反映失败的服务更新
在此次更新之前，当对服务配置更新失败时，失败不会反映在部署的条件状态中。相反，Ready 条件显示为 "True"，因为检查部署就绪状态时不会考虑更新创建的新 pod。在这个版本中，在配置更新期间创建的任何新 pod 都会在评估部署就绪状态时考虑。如果推出新 pod 失败，则部署会反映它一直处于 Deployment 中。
2.1.7.2. 已知问题
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中已知的问题。
control plane 在次版本更新过程中临时不可用
在次版本更新过程中，RHOSO control plane 临时不可用。API 请求可能会失败并显示 HTTP 错误代码，如错误 500。或者，API 请求可能会成功，但底层生命周期操作会失败。例如，在次要更新期间使用 openstack server create 命令创建的虚拟机(VM)永远不会达到 ACTIVE 状态。control plane 中断是临时的，并在次要更新完成后自动恢复。control plane 中断不会影响已在运行的工作负载。
临时解决方案： 要防止这种中断，请参阅红帽知识库文章 如何在 OpenShift 上的 Red Hat Openstack Services 中启用镜像队列。
2.1.8. 安全与强化
2.1.8.1. 程序错误修复
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中修复的、对用户有严重影响的错误。
生成的 CA 捆绑包安装在 data plane 节点上
在此次更新之前，由 RHOSO control plane 生成的 CA 捆绑包部署在 data plane 节点上，用于部署或运行服务，但它没有作为 CA 捆绑包安装到 data plane 节点本身。CA 捆绑包可以包含自定义第三方 CA 文件，例如访问 satellite。在这个版本中，CA 捆绑包安装在 data plane 节点上。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}