3.5. Red Hat OpenStack Platform 16.1.4 维护发行版本 - 2021 年 3 月 17 日

在此次更新之前，如果用户将 ContainerImagePrepare 参数配置为使用自定义标签，如 'tag: "latest"' 或 'tag: "16.1"'，而不是标准的 'tag_from_label: "{version}-{release}'，则容器不会更新最新的容器镜像。

在这个版本中，每当用户运行部署操作时，容器镜像总是被获取，包括更新，并根据正在运行的容器检查镜像 ID，以查看是否需要重新构建该镜像来使用最新的镜像。现在，容器总是会在部署操作过程中刷新，并在更新容器时重启容器。

在此次更新之前，当部署到边缘站点时，镜像(glance)服务没有配置为访问在中央站点的 control plane 上运行的 Key Manager (barbican)服务。这会导致边缘站点上运行的镜像服务无法访问存储在 Key Manager 服务的加密密钥。

在这个版本中，在边缘站点上运行的镜像服务被配置为访问存储在 Key Manager 服务的加密密钥。

在此次更新之前，在 TLS 任何位置，从 Red Hat OpenStack Platform 13 原位升级到 16.1，对 novajoin 容器使用了不正确的 rabbitmq 密码。这会导致 undercloud 上的 novajoin 容器无法正常工作，这会导致运行升级的任何 overcloud 节点失败，并显示以下错误：

2020-11-24 20:01:31.569 7 ERROR join   File "/usr/lib/python3.6/site-packages/amqp/connection.py", line 639, in _on_close
2020-11-24 20:01:31.569 7 ERROR join     (class_id, method_id), ConnectionError)
2020-11-24 20:01:31.569 7 ERROR join amqp.exceptions.AccessRefused: (0, 0): (403) ACCESS_REFUSED - Login was refused using authentication mechanism AMQPLAIN. For detail see the broker logfile.

2020-11-24 20:01:31.569 7 ERROR join   File "/usr/lib/python3.6/site-packages/amqp/connection.py", line 639, in _on_close
2020-11-24 20:01:31.569 7 ERROR join     (class_id, method_id), ConnectionError)
2020-11-24 20:01:31.569 7 ERROR join amqp.exceptions.AccessRefused: (0, 0): (403) ACCESS_REFUSED - Login was refused using authentication mechanism AMQPLAIN. For detail see the broker logfile.

在这个版本中，从 RHOSP 13 升级到 16.1 在任何地方使用正确的 rabbitmq 密码，以便升级的框架可以成功完成。

在此次更新之前，当升级一个本地临时存储的 TLS 时，实时迁移会失败，并将 UseTLSTransportForNbd 设置为 "False"。这是因为 UseTLSTransportForNbd 配置的默认值已从 RHOSP 13 中的 "False" 改为 RHOSP 16.x 中的 "True"，这会导致 QEMU 进程容器中不包含正确的认证。

在这个版本中，director 会检查之前为 global_config_settings 部署的环境的配置，并使用它来确保 UseTLSTransportForNbd 状态与以前的部署一样。如果配置文件中存在 global_config_settings，则 director 会检查 use_tls_for_nbd 键的配置。如果 global_config_settings 不存在，director 会评估 hieradata 键 nova::compute::libvirt::qemu::nbd_tls。在升级的部署中保持 UseTLSTransportForNbd 状态与以前的部署相同，可确保实时迁移正常工作。

在此次更新之前，在 OSP 16.1.3 中的 python-network-runner 中的 rebase 到 0.2.2 会导致 ML2 网络使用 Ansible 不再正常工作。

在这个版本中，python-networking-ansible 被恢复到 0.1.7，Ansible 网络返回到可正常工作的状态。

如需更多信息，请参阅 https://access.redhat.com/documentation/zh-cn/red_hat_openstack_platform/16.1/html/bare_metal_provisioning/ml2-networking-ansible。

在此次更新之前，Block Storage (cinder)服务总是使用默认卷类型分配新创建的卷，即使卷是从另一个源（如镜像、快照或其他卷）创建的卷。这会导致从另一个源创建的卷与源的卷类型不同。

在这个版本中，只有在根据源的卷类型确定是否应该分配默认卷类型后，才会分配默认卷类型。从另一个源创建的卷类型现在与源的卷类型匹配。

在这个版本中，您可以配置 NVDIMM Compute 节点，以便为实例提供持久性内存。使用此功能，您可以通过在具有 NVDIMM 硬件的 Compute 节点上创建和配置 PMEM 命名空间，使实例作为虚拟 PMEM (vPMEM)使用。然后，当云用户需要保留实例内容时，可以创建请求 vPMEM 的实例。

注：由于 daxio 软件包仅适用于 x86_64 架构，这个功能只在 x86_64 Compute 节点上被支持。

借助此项功能增强，您可以使用两个新参数 NovaPMEMMappings 和 NovaPMEMNamespaces 来管理 vPMEM。

此功能增强添加了对将开放虚拟网络(OVN)与网络功能虚拟化基础架构(SVVPi)搭配使用的支持。这包括对以下功能的支持：

注： NFV 部署尚不支持从 ML2/OVS 迁移到 ML2/OVN。

此功能增强添加了对 ML2/OVN 机制驱动程序中具有 vlan 和 geneve 网络类型驱动程序的 vlan 透明支持。

借助 vlan 透明性，您可以使用 Networking (neutron)服务网络上的实例来管理 vlan 标签。您可以在实例上创建 vlan 接口，并使用任何 vlan 标签，而不影响其他网络。网络服务不知道这些 vlan 标签。

备注：

virt-admin 工具现在可用于捕获报告 RHOSP 错误的日志。此工具可用于对所有 libvirt 和 QEMU 问题进行故障排除，因为日志提供 Compute 节点上的 libvirt 和 QEMU 之间的通信。您可以使用 virt-admin 动态设置 libvirt 和 QEMU 调试日志过滤器，而无需重启 nova_libvirt 容器。

执行以下步骤在 Compute 节点上启用 libvirt 和 QEMU 日志过滤器：

目前，在确保订阅的环境设置了正确的 DNF 模块流的机制时存在一个已知问题。Ceph 节点使用的订阅中并不总是提供高级虚拟化存储库，这会导致在尝试启用 virt:8.2 时 Ceph 节点的升级或更新失败。有关已知问题的详情请参考 https://bugzilla.redhat.com/show_bug.cgi?id=1923887。

临时解决方案：

覆盖升级或更新环境文件中的 DnfStreams 参数，以防止 Ceph 升级失败：

parameter_defaults:
  ...
  DnfStreams: [{'module':'container-tools', 'stream':'2.0'}]

parameter_defaults:
  ...
  DnfStreams: [{'module':'container-tools', 'stream':'2.0'}]

在 OSP13 中使用 UEFI 引导和 UEFI 引导装载程序的系统可能会遇到以下结果的 UEFI 问题：

如果您的系统使用 UEFI，请联系红帽技术支持。如需更多信息，请参阅红帽知识库解决方案 FFU 13 到 16.1：Leapp 无法在基于 UEFI 的系统上更新内核，/etc/fstab 不包含 EFI 分区。

目前存在一个已知问题 [workarounds]/disable_native_luksv1 和 [workarounds]/rbd_volume_local_attach 配置选项。这些选项仅作为 libgcrypt 和 librdb 中已知性能回归的一个临时临时解决方案。在 RHOSP 使用的底层 RHEL 版本中解析回归后，会删除这些临时解决方案选项。

使用其中任何一个临时解决方案选项相关注意事项。不遵循这些注意事项可能会导致 RDB 加密卷出现问题。注意事项如下：

如果您使用 Red Hat Ceph Storage 订阅并将 director 配置为使用 Red Hat Ceph Storage 节点的 overcloud-minimal 镜像，则因为 Leapp 限制，对 Red Hat Ceph Storage 节点的升级可能会失败。

要避免这个问题，在 system_upgrade 运行后，您必须登录到 Red Hat Ceph Storage 节点以取消设置 RHEL 次版本，升级到最新版本，并重新引导节点。

如果使用 Red Hat Satellite Server 为 Leapp 升级托管 RPM 内容，您必须将以下 8.2 存储库添加到您使用的内容视图中：

如需更多信息，请参阅 https://bugzilla.redhat.com/show_bug.cgi?id=1936419

目前，ceph-ansible 中存在一个已知问题，它可防止 ansible playbook 在部署或更新配置为使用外部非受管 Ceph 集群的 Ceph Ganesha 容器时成功完成。

此问题会导致将 Ceph Ganesha 与共享文件系统服务(manila)搭配使用的 overcloud 的部署、次要更新或主要升级，并且配置为使用外部 Ceph 集群失败。

临时解决方案：

如果您对 overcloud 进行升级或次要更新，请使用 ceph-ansible 版本 4.0.49.1 或更高版本，如果您的环境被配置为使用共享文件系统服务和外部 Ceph 集群的 Ceph Ganesha。在这些条件下，不要尝试使用 undercloud 上安装早于 4.0.49.1 的 ceph-ansible 版本进行升级。