第 3 章 发行信息 RHOSO 18.0
本发行注记重点介绍在 OpenShift (RHOSO)组件的一些或所有红帽服务中所选的更新。当您部署此 RHOSO 发行版本时,请考虑这些更新。本节中的每个备注都引用用于跟踪更新的 JIRA 问题。如果 Jira issue 安全级别是公共的,您可以点击链接来查看 JIRA 问题。如果安全级别受到限制,则 JIRA 问题 ID 没有 JIRA 问题的链接。
3.1. 发行信息 RHOSO 18.0.4
3.1.1. 公告列表
此 Red Hat OpenStack Services on OpenShift (RHOSO)发行版本包括以下公告:
- RHBA-2025:0435
- RHOSO 18.0.4 组件发布
- RHBA-2025:0436
- RHOSO 18.0.4 容器发布
- RHBA-2025:0437
- RHOSO 18.0.4 的 control plane Operator
- RHBA-2025:0438
- RHOSO 18.0.4 的数据平面 Operator
- RHSA-2025:0439
- 中度:Red Hat OpenStack Platform 18.0.4 (openstack-ironic)安全更新
3.1.2. Compute
3.1.2.1. 程序错误修复
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中修复的、对用户有严重影响的错误。
从带有硬件架构属性的镜像引导实例
在此次更新之前,您无法从具有 hw_architecture
或 hw_emulation_architecture
属性的镜像引导实例。在这个版本中,您可以从具有 hw_architecture
和 hw_emulation_architecture
属性的镜像引导实例。
3.1.2.2. 已知问题
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中已知的问题。
在计算服务重启后,NFS 共享上具有临时存储的实例停止工作
当容器化 Compute 代理服务在虚拟机监控程序主机上重新启动时,NFS 共享上的具有临时存储的计算服务(nova)实例停止工作。这是因为 /var/lib/nova/
实例的权限改变。
临时解决方案: 手动恢复权限到原始值并避免服务重启。
对于具有 交换
的服务器的冷迁移失败,用于 NFS 等共享存储。
使用共享存储启用 Compute 服务(nova)时,如果实例使用了 FLAVOR_SWAP
类别,则 NFS 和冷迁移会失败。
默认禁用计算服务电源管理功能
默认情况下,计算服务(nova)电源管理功能被禁用。您可以使用以下 nova-compute
配置启用它:
[libvirt] cpu_power_management = true cpu_power_management_strategy = governor
目前不支持默认的 cpu_power_management_strategy
cpu_state
。重启 nova-compute 会导致该主机上的所有专用 PCPU 都已关机,包括供实例使用的 PCPU。如果使用 cpu_state
策略,则这些实例的 CPU 将变得 unpinned。
3.1.3. 数据平面
3.1.3.1. 程序错误修复
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中修复的、对用户有严重影响的错误。
文档:如果您有多个红帽订阅,则指定一个池来注册节点
在此次更新之前,在创建带有预置备节点或未置备节点的 OpenStackDataPlaneNodeSet CR 创建 OpenStackDataPlaneNodeSet
CR 的过程中,在注册 RHOSO 部署节点时缺少可选的命令指定池。如果您有多个红帽订阅,则缺少的命令可能会导致在 RHOSO 中部署 data plane 或 Compute 节点时导致注册错误。
在这个版本中,如果您有多个红帽订阅,则指定池的可选命令。
Ansible 任务在断开连接的部署中成功写入 registry.conf
文件
在此次更新之前,registry.conf
文件会在断开连接的部署中失败,因为 Ansible 任务尝试使用 template
模块和 raw 字符串输入作为 src
。在这个版本中,Ansible 任务成功写入 registry.conf
文件,因为它使用带有 content
参数的 ansible.builtin.copy
模块。
重启后,在 EDPM 节点上禁用 iSCSI -starter.service
在此次更新之前,iscsi.service
在重启了 EDPM 节点后启动,该节点运行具有 iSCSI 支持的卷的实例,即使 edpm-ansible
中没有启用 iscsi.service
。出现这个问题的原因是,iscsi-starter.service
是在 EDPM 节点的镜像中启用的。在这个版本中,iscsi-starter.service
在 EDPM 节点上被禁用,以防止问题。
3.1.4. 硬件置备
3.1.4.1. 程序错误修复
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中修复的、对用户有严重影响的错误。
用于 Bare Metal 服务(ironic)的新 default_network_interface
参数
在此次更新之前,如果在 ControlPlane 部署过程中没有配置 Bare Metal 服务 network_interface
,则 RHOSO 将其配置为 no-op。
在这个版本中,RHOSO 将 default_network_interface
参数设置为 customServiceConfig / [DEFAULT]
下的默认值。
3.1.5. 网络
3.1.5.1. 程序错误修复
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中修复的、对用户有严重影响的错误。
添加了对没有 DVR 的动态路由的支持
在以前的版本中,除非您还使用分布式虚拟路由(DVR),否则无法在带有自由范围路由(FRR)和边框网关协议(BGP)的数据平面上使用动态路由。现在,您可以在不启用 DVR 的情况下使用动态路由。
文档:为 ovndbcluster 字段设置 replicas: 3
在以前的版本中,RHOSO 文档中的 CR 示例并不一致表示支持 OVN 数据库高可用性,您必须在包含 OVN spec 的 ovndbcluster-nb
和 ovndbcluster-sb
字段中设置 replicas: 3
。
在这个版本中,所有 CR 示例都包含副本要求。以下示例显示了带有 add 部分的 CR 示例摘录:
ovn: template: ovnDBCluster: ovndbcluster-nb: replicas: 3 <<---------- dbType: NB storageRequest: 10G networkAttachment: internalapi ovndbcluster-sb: replcas: 3 <<---------- dbType: SB storageRequest: 10G networkAttachment: internalapi ovnNorthd: {}
在采用前更新至最新的 RHOSP 17.1 版本
在对比 RHOSP 17.1.4 旧的源环境执行源环境时,工作负载会延长网络连接中断。在采用前,请确保至少将源环境更新至 RHOSP 17.1.4。
更正了在定义可用区时 createDefaultLbMgmtNetwork
和 manageLbMgmtNetworks
的默认值
在此次更新之前,当定义了可用区时,createDefaultLbMgmtNetwork
和 manageLbMgmtNetworks
被错误地设置为 false
。
在这个版本中,当定义可用区时,createDefaultLbMgmtNetwork
和 manageLbMgmtNetworks
被设置为 true
。
3.1.5.2. 已知问题
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中已知的问题。
Octavia-operator 不启用反关联性
负载均衡服务(octavia)目前没有在 Compute 服务(nova)中配置反关联性设置,以防止 Amphora 虚拟机调度到同一 Compute 节点。
临时解决方案: 使用 customServiceConfig
参数将相关设置添加到负载均衡服务,如下例所示:
Example
# names will be dependent on the deployment oc patch -n openstack openstackcontrolplane openstack-galera-network-isolation --type=merge --patch ' spec: octavia: template: octaviaHousekeeping: customServiceConfig: | [nova] enable_anti_affinity = true octaviaWorker: customServiceConfig: | [nova] enable_anti_affinity = true octaviaHealthManager: customServiceConfig: | [nova] enable_anti_affinity = true '
采用后旧的 tripleo Networking services (neutron)
在 edpm_tripleo_cleanup
任务后,仍有传统的 tripleo Networking 服务(neutron)服务。这些服务在采用后停止,因此 RHOSO 服务不受影响。
临时解决方案: 执行以下步骤来手动删除旧服务:
-
check tripleo neutron services list:
systemctl list-unit-files --type service
-
从
/etc/systemd/system/
中删除 tripleo 服务
networker 节点上的负载均衡服务(octavia)代理不支持使用
目前不支持使用在 networker 节点上部署的负载均衡服务代理的部署。
当外部 MTU 大于内部 MTU 时,数据包会静默丢弃
当外部 MTU 大于内部 MTU 时,RHOSO 不会按预期分段南北数据包。如果在没有通知的情况下丢弃 ingress 数据包,则应该被使用。
此外,碎片不适用于租户网络之间的 east/west 流量。
在解决这些问题之前,请确保外部 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 设置:
neutron: enabled: true : template: : customServiceConfig: | [DEFAULT] global_physnet_mtu=1558 [ml2] physical_network_mtus = ["datacentre:1500"] [ovn] ovn_emit_need_to_frag = true
- 确保外部网络上的每个设备上的 MTU 设置小于内部 MTU 设置。
- 确保所有使用 OVN 路由器的租户网络具有相同的 MTU。
- 要将更改应用到现有的路由器,请删除路由器并重新创建它。
3.1.6. 网络功能虚拟化
3.1.6.1. 已知问题
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中已知的问题。
不要将虚拟功能(VF)用于 RHOSO control plane 接口
这个 RHOSO 发行版本不支持对 RHOSO control plane 接口使用 VF。
验证任何生产环境部署的 os-net-config
供应商是否为 ifcfg
红帽目前不支持 NMstate
作为 os-net-config 供应商
。确保设置了 edpm_network_config_nmstate: false
,这是默认设置。这样可确保您的环境使用 ifcfg
供应商。
3.1.7. Control plane(控制平面)
3.1.7.1. 已知问题
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中已知的问题。
control plane 在次版本更新过程中临时不可用
在次版本升级到 18.0 功能发行版本 1 时,RHOSO control plane 会临时不可用。API 请求可能会失败并显示 HTTP 错误代码,如错误 500。或者,API 请求可能会成功,但底层生命周期操作会失败。例如,在次要更新期间使用 openstack server create
命令创建的虚拟机(VM)永远不会达到 ACTIVE
状态。control plane 中断是临时的,并在次要更新完成后自动恢复。control plane 中断不会影响已在运行的工作负载。
3.1.8. 安全与强化
3.1.8.1. 程序错误修复
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中修复的、对用户有严重影响的错误。
对 Key Manager (barbican)服务的自定义配置支持
在此次更新之前,在 common_types.go
中存在一个问题,防止 Key Manager 服务的自定义资源定义(CRD)中的 customServiceConfig
字段被正确应用。在这个版本中,这个问题已被解决,允许正确生成并应用自定义配置。
3.1.9. Storage
3.1.9.1. 已知问题
这部分论述了 Red Hat OpenStack Services on OpenShift 18.0 中已知的问题。
当 uniquePodNames
为 true
时,对实例的 extraMounts
传播无法正常工作
当 uniquePodNames
为 true
时,每个 Cinder pod (通常每个组件和服务)都以 pseudo-random 字符串作为前缀。这会影响每个实例传播,因为基于 字符串.TrimPrefix
的传统方法不再有效。
在 DCN 部署中,通过匹配实例 AZ 名称将 secret 传播到 pod。
示例 1 会导致带有与 az0 匹配 secret ceph-conf-az-0 的 pod,带有名称与 az1 匹配的 Pod 获取 secret ceph-conf-az-0 等。示例 1 适用于 Glance pod,但如果 uniquePodNames
为 false
,则仅适用于 Cinder pod。
临时解决方案: 将 uniquePodNames
设置为 false
,如示例 2 所示,直到这个问题解决为止。只有在存储后端使用 NFS 时,才需要 uniquePodNames
设置。
示例 1
apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane spec: extraMounts: - extraVol: - extraVolType: Ceph mounts: - mountPath: /etc/ceph name: ceph0 readOnly: true propagation: - az0 volumes: - name: ceph0 projected: sources: - secret: name: ceph-conf-az-0 - extraVolType: Ceph mounts: - mountPath: /etc/ceph name: ceph1 readOnly: true propagation: - az1 volumes: - name: ceph1 projected: sources: - secret: name: ceph-conf-az-1
示例 2
apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane <...> spec: cinder: uniquePodNames: false # workaround https://issues.redhat.com/browse/OSPRH-11240 enabled: true apiOverride: <...>