4.6. RHBA-2018:3587 — Red Hat OpenStack Platform 13.0 director Bug Fix Advisory

本节中所包括的错误已在 RHBA-2018:3587 公告中解决。有关此公告的详情请点击以下链接 ：https://access.redhat.com/errata/RHBA-2018:3587

instack-undercloud

有些硬件在收到 IPMI bootdev 命令时以意外方式更改引导设备排序。这可能会阻止节点引导正确的 NIC，或阻止 PXE 引导时启动。此发行版本为 "ipmi" 驱动程序引入了一个新的 "noop" 管理界面。在使用时，不会发出 bootdev 命令，而是使用当前的引导顺序。节点必须配置为尝试从正确的 NIC 进行 PXE 引导，然后回退到本地硬盘驱动器。这个更改可确保预先配置的引导顺序与新的管理界面保持一致。

在以前的版本中，undercloud hieradata 覆盖可用于使用类似 overcloud 的 <service>::config 选项来调优某些服务配置。但是，所有部署的 OpenStack 服务都不提供此功能。在这个版本中，任何目前不可用的配置值都可以通过 <service>::config hieradata 进行更新。

openstack-tripleo-common

从 Red Hat OpenStack Platform 12 升级到 13 时，将删除 ceph-osd 软件包。软件包移除会停止正在运行的 OSD，尽管它们在容器中运行，不应也不需要 软件包。此发行版本删除了在升级期间删除软件包的 playbook，而且 Ceph OSD 不会在升级过程中意外停止。

当 OpenStack 更新和/或升级时，director 将最新的 amphora 镜像上传到 glance。最新的 amphora 镜像确保 amphora 实例使用最新的通用程序错误和安全修复运行，而不仅适用于 Octavia 代理修复，也用于操作系统修复。

在这个版本中，使用最新的 amphora 镜像创建新并重新创建实例。之前的 amphora 镜像将保留在 glance 中，并重命名为将时间戳包含在后缀中。

openstack-tripleo-heat-templates

连接到 publicURL Keystone 端点的实例 HA 脚本之一。现在默认移到 internalURL 端点。另外，Operator 可以通过 nova.conf 中的 '[placement]/valid_interfaces' 配置入口点来覆盖它。

在以前的版本中，缺少在线数据迁移的触发器。在升级到 OSP 13 后，overcloud 中的 nova、cinder 和 ironic 的在线数据迁移不会自动运行，这强制手动临时解决方案。此发行版本为在线数据迁移添加触发器逻辑。在升级到 OSP 13 时，openstack overcloud 升级聚合 命令过程中触发在线数据迁移。

在之前的版本中，您可以通过 nova::compute::libvirt::rx_queue_size/nova::compute::libvirt::libvirt_size 设置 RX/TX 队列大小。但是，没有专用的 TripleO heat 模板参数。在这个版本中，可在角色基础中设置 RX/TX 队列大小，如下所示：

parameter_defaults: ComputeParameters: NovaLibvirtRxQueueSize: 1024 NovaLibvirtTxQueueSize: 1024

结果是使用新参数设置的 rx_queue_size/tx_queue_size。

要将 MTU 设置为 OSPD 的一部分，这个版本会将 neutron::plugins::ml2::physical_network_mtus 添加为 heat 模板中的 NeutronML2PhysicalNetworkMtus，以在 ml2 插件中启用 MTU。Neutron::plugins::ml2::physical_network_mtus 根据 TripleO heat 模板中的值来设置。

在以前的版本中，检查 Docker 守护进程是否需要重启的条件太严格。因此，每当 Docker 配置发生变化或更新 Docker RPM 时，Docker 守护进程和所有容器都会重启。在这个版本中，条件会被放宽，以防止不必要的容器重启。将"实时恢复"功能用于配置更改，以确保 Docker 守护进程和所有容器在 Docker RPM 更新时重新启动，但不会在 Docker 配置更改时重启。

在重新部署期间，可以无须重启多个容器，即使没有任何配置更改。这是因为在配置文件的 md5 计算中包含太多不需要的文件。在这个版本中，重新部署不会触发错误的容器重启。

TripleO CinderNetappBackendName 参数无法正确覆盖 cinder 的 Netapp 后端的默认值。因此，与 cinder 的 Netapp 后端关联的名称不能被覆盖。在这个版本中，CinderNetappBackendName 参数可以正确地覆盖默认的后端名称。

puppet-cinder

一些配置设置已从 cinder 中删除，但对应的参数不会从负责设置 cinder 的配置设置的 TripleO Puppet 模块中删除。因此，无效的 cinder 配置设置被添加到 cinder.conf 中。在这个版本中，Puppet 模块已被更新，以防止将过时的设置添加到 cinder.conf 中。

puppet-tripleo

在系统关闭过程中发生 rhel-plugin-push.service 和 Docker 服务之间的故障交互，这会导致控制器长时间重启。在这个版本中，为这两个服务强制进行正确的关闭排序。现在重启控制器需要较少的时间。

在部署期间，OVS 交换机可能配置了不正确的 OpenFlow 控制器端口(6640，而不是 6653，用于三个控制器的两个)。这会导致部署失败，或者稍后部署的功能失败，其中将不正确的流编程成交换机。此发行版本会正确地为每个 OVS 交换机将所有 OpenFlow 控制器端口设置为 6653。所有 OVS 交换机都具有正确的 OpenFlow 控制器配置，它由三个 URI 组成，每个 OpenDaylight 使用端口 6653。

当从集群中移除单个 OpenDaylight 实例时，这会将实例移到隔离状态，这意味着不再对传入请求执行。HA 代理仍然对隔离的 OpenDaylight 实例进行负载均衡，这可能会导致 OpenStack 网络命令失败或无法正常工作。HA Proxy 现在将隔离的 OpenDaylight 实例检测到为不健康状态。HA Proxy 不会将请求转发到隔离的 OpenDaylight。

python-os-brick

在某些情况下，负责扫描 FibreChannel HBA 主机的 os-brick 代码可能会返回无效的值。无效的值将导致 cinder 和 nova 等服务失败。在这个版本中，FibreChannel HBA 扫描代码总是返回一个有效值。在扫描 FibreChannel HBA 主机时，Cinder 和 nova 不再崩溃。

在多路径连接中，设备在断开连接时单独清除所有路径。在某些情况下，单个设备中的故障会错误地防止断开连接。在这个版本中，单个路径不再刷新，因为多路径已经确保在远程设备上写入缓冲的数据。现在，只有在实际丢失数据时，断开连接才会失败。

在有些情况下，multipathd 显示状态 不会因为应该返回错误代码，因此我们现在会检查 stdout 作为这个问题的一个临时解决方案，以便正确检测到 multipathd 处于错误状态。

在之前的发行版本中，当一个 iSCSI 路径在迁移启动期间的一个缩小时，卷迁移会失败（带有 VolumePathNotRemoved 错误）。此发行版本解决了这个问题，方法是扩展超时时间以验证卷删除。

iSCSI 设备检测根据重新扫描时间检查是否存在设备。在扫描间可用的设备未探测到。在这个版本中，搜索和重新扫描是独立的操作，它会以不同的节奏进行操作，每秒钟的检查会发生。

python-tripleoclient

在之前的版本中，如果您通过 deploy 命令行的 '-p' 选项（如 mysql、horizon、pcsd 等）在重新部署期间将重置为部署命令行的 '-p' 选项（如 mysql、horizon、pcsd 等）的定制计划。这会导致重新部署失败。在这个版本中，自定义计划不会触发设置新密码。