本 Red Hat OpenStack Platform 发行版本包括以下增强：

BZ#1419556

Object Store 服务 (swift) 现可与 Barbican 集成，以便透明地加密和解密您所存储的（静态）对象。静态加密有别于动态加密，前者是指在对象存储于磁盘上时进行加密。

Swift 对象会以明文形式存储在磁盘上。如果这些磁盘在生命周期结束后未得到正确处置，则可能会带来安全风险。通过加密对象，可以消除这类风险。

Swift 会透明地执行这些加密任务；对象则会在上传到 swift 时自动加密，然后在提供给用户时自动解密。这类加密和解密操作会使用存储在 Barbican 中的同一个（对称）密钥来完成。

BZ#1540239

这个增强功能支持向 Gnocchi DB 实例发送指标数据。

collectd 可组合服务新增了以下参数。如果 CollectdGnocchiAuthMode 被设置为“simple”，则应在配置时考虑 CollectdGnocchiProtocol、CollectdGnocchiServer、CollectdGnocchiPort 和 CollectdGnocchiUser。

如果 CollectdGnocchiAuthMode 被设置为“keystone”，则应在配置时考虑 CollectdGnocchiKeystone* 参数。

以下是各个新增参数的详细描述：

  CollectdGnocchiAuthMode：
    类型：字符串
    描述：>
      使用的是认证 Gnocchi 服务器的类型。受支持的值为
      “simple”和“keystone”。
    默认值：“simple”
  CollectdGnocchiProtocol：
    类型：字符串
    描述：使用的是 API 协议 Gnocchi 服务器。
    默认值：“http”
  CollectdGnocchiServer：
    类型：字符串
    描述：>
      指标应该发送到的目标 gnocchi 端点的
      名称或地址。
    默认值：nil
  CollectdGnocchiPort：
    类型：数字
    描述：我们将在 Gnocchi 服务器上连接的端口。
    默认值：8041
  CollectdGnocchiUser：
    类型：字符串
    描述：>
      用于通过简单认证向远程 Gnocchi 服务器进行认证的
      用户名。
    默认值：nil
  CollectdGnocchiKeystoneAuthUrl：
    类型：字符串
    描述：认证操作所针对的 Keystone 端点 URL。
    默认值：nil
  CollectdGnocchiKeystoneUserName：
    类型：字符串
    描述：用于向 Keystone 进行认证的用户名。
    默认值：nil
  CollectdGnocchiKeystoneUserId：
    类型：字符串
    描述：用于向 Keystone 进行认证的用户 ID。
    默认值：nil
  CollectdGnocchiKeystonePassword：
    类型：字符串
    描述：用于向 Keystone 进行认证的密码
    默认值：nil
  CollectdGnocchiKeystoneProjectId：
    类型：字符串
    描述：用于向 Keystone 进行认证的项目 ID 。
    默认值：nil
  CollectdGnocchiKeystoneProjectName：
    类型：字符串
    描述：用于向 Keystone 进行认证的项目名称。
    默认值：nil
  CollectdGnocchiKeystoneUserDomainId：
    类型：字符串
    描述：用于向 Keystone 进行认证的用户域 ID。
    默认值：nil
  CollectdGnocchiKeystoneUserDomainName：
    类型：字符串
    描述：用于向 Keystone 进行认证的用户域名。
    默认值：nil
  CollectdGnocchiKeystoneProjectDomainId：
    类型：字符串
    描述：用于向 Keystone 进行认证的项目域 ID。
    默认值：nil
  CollectdGnocchiKeystoneProjectDomainName：
    类型：字符串
    描述：用于向 Keystone 进行认证的项目域名。
    默认值：nil
  CollectdGnocchiKeystoneRegionName：
    类型：字符串
    描述：用于向 Keystone 进行认证的区域名称。
    默认值：nil
  CollectdGnocchiKeystoneInterface：
    类型：字符串
    描述：认证操作针对的 Keystone 端点的类型。
    默认值：nil
  CollectdGnocchiKeystoneEndpoint：
    类型：字符串
    描述：>
      显式状态 Gnocchi 服务器 URL（如果您想要覆盖
      Keystone 值）
    默认值：nil
  CollectdGnocchiResourceType：
    类型：字符串
    描述：>
      Gnocchi 中的 collectd-gnocchi 创建的用于存储主机的
      默认资源类型。
    默认值：“collectd”
  CollectdGnocchiBatchSize：
    类型：数字
    描述：Gnocchi 应该批量处理的值的最小数量。
    默认值：10

本节中列出的项目作为技术预览提供。如需关于技术预览状态范围的更多信息，以及相关的支持定义，请参阅 https://access.redhat.com/support/offerings/techpreview/。

BZ#1488095

从 RHOS-12 开始，OpenStack 服务都已容器化。在本发行版本中，我们也对 OpenStack Tempest 进行了容器化。容器化 OpenStack Tempest 会作为技术预览提供。

本节概述了本发行版本的重要详细信息，包括推荐方案和 Red Hat OpenStack Platform 的显著变化。您必须将此信息纳入考量，才能确保您的部署获得最佳成果。

BZ#1468020

Shared File System 服务 (manila) 现可利用 NetApp ONTAP cDOT 驱动提供 IPv6 访问规则支持，以便将 manila 与 IPv6 环境搭配使用。

因此，Shared File System 服务现支持通过 IPv6 网络导出由 NetApp ONTAP 后端支持的共享内容。对于已导出共享内容的访问则会通过 IPv6 客户端的地址来加以控制。

BZ#1469208

Shared File System 服务 (manila) 可按照 NFSv4 协议，挂载由 Ceph 文件系统 (CephFS) 提供支持的共享文件系统。在 Controller 节点上运行的 NFS-Ganesha 服务器用于将 CephFS 导出至高可用性 (HA) 租户。租户间相互隔离，他们或许只能通过提供的 NFS 网关接口来访问 CephFS。这个新功能已完全整合到 director 中，因而可针对 Shared File System 服务进行 CephFS 后端部署和配置。

BZ#1496584

在对 neutron 服务进行容器化后，如尝试在网络命名空间中运行命令，可能会失败并出现以下错误：

# ip netns exec qrouter...
RTNETLINK answers: Invalid argument

要在网络命名空间中运行命令，您必须从创建该命令空间的 neutron  容器中执行这一操作。例如，l3-agent 为路由器创建了网络命名空间，所以命令需改为：

# docker exec neutron_l3_agent ip netns exec qrouter...

对于以“qdhcp”开头的网络命名空间，您同样需要从“neutron_dhcp”容器中运行 exec。

BZ#1503521

本发行版本支持在 networking-ovn 中进行内部 DNS 解析。但是存在两个已知限制，
其中的一个是 bz#1581332，它导致无法通过内部 dns 正确解析内部 fqdn 请求。

请注意，在 GA 发行版本中，tripleo 在默认情况下不会配置扩展。请参阅 bz#1577592，以了解相应的解决办法。

BZ#1533206

openstack-gnocchi 软件包已重命名为 gnocchi。由于上游项目范围有所变化，所以删除了 openstack- 前缀。Gnocchi 已从 OpenStack umbrella 中移出，并作为独立项目进行维护。

BZ#1556933

从 2.1 版起，python-cryptography 都会检查证书中所用的 CNS 名称是否符合 IDN 标准。如果找到的名称未遵循这一规范，cryptography 将无法验证证书，而且可能会在使用 OpenStack 命令行接口时或在 OpenStack 服务日志中看到各种错误。

BZ#1563412

为 OpenStack Compute (nova) 保留的主机内存已从 2048 MB 增加到 4096 MB。这可能会对环境的容量估计值产生影响。如有必要，您可以使用环境文件中的“NovaReservedHostMemory”参数来重新配置保留的内存。例如：

parameter_defaults:
  NovaReservedHostMemory: 2048

BZ#1564176

 所有受支持的 overcloud 用例均不包含 python-mistralclient，所以已将其从 OSP 13 发行版本的 -tools 频道中移除。

BZ#1567735

使用 OVN 作为网络后端的 OSP13 在第一个发行版本中不会包含 IPv6 支持。所以，在回复来自客户机 VM 的  Neighbor Solicitation 请求时会出现问题，并进而导致默认路由丢失。

BZ#1575752

在先前的版本中，*NetName 参数（如 InternalApiNetName）可更改默认网络的名称。这一行为现已不受支持。

要更改默认网络的名称，请使用自定义可组合网络文件 (network_data.yaml)，并利用“-n”选项将其包含在“openstack overcloud deploy”命令中。在这个文件中，您应该将字段“name_lower”设置成您想为网络改用的自定义网络名称。有关更多信息，请参阅《Overcloud 高级自定义》指南中的“使用可组合的网络”。

另外，您还需要将 ServiceNetMap 表格的局部参数添加到 network_environment.yaml 中，并将旧网络名称的所有默认值覆盖为新的自定义名称。默认值可在 /usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml 中找到。在未来的 OSP-13 发行版本中，无需再修改 ServiceNetMap。

BZ#1577537

修复了 OSP 13 Beta 版中的以下问题：部分容器镜像不可用。

BZ#1578312

当 OVSDB 服务器因出现故障而切换到其他 controller 节点时，不会重新连接 neutron-server/metadata-agent，因为它们无法检测到这一情况。

所以，引导 VM 可能不会作为元数据代理（不会置备新的元数据命名空间）运行，集群也无法正常工作。

要解决这一问题，可行的方法是：在某个新控制器被升级为 OVN 数据库的主控制器后，重新启动所有 compute  节点中的 ovn_metadata_agent 容器。另外，请将 plugin.ini 上的 ovsdb_probe_interval 值增加到 600000 毫秒。

BZ#1589849

如果在某个 Compute 节点中停止了 OVN 元数据代理，该节点上的所有 VM 都将无权访问元数据服务。这会带来如下影响：如果创建了新的 VM，或是重启了某个现有的 VM 后，则该 VM 将无法访问元数据，直至 OVN 元数据代理重新启用。

BZ#1592528

在极少数情况下，在多次重启 controller 节点后，RabbitMQ 的运行状态可能会不一致，而这会导致 API 无法在 overcloud 上运行。

这个问题的症状表现为：
 - 任意 OpenStack 服务日志中出现如下条目：
 DuplicateMessageError: Found duplicate message(629ff0024219488499b0fac0cacaa3a5). Skipping it.
 -“openstack network agent list”返回的结果表明部分代理处于停机状态

要恢复正常运行，请在任意 controller 节点上运行以下命令（只需在一个控制器上执行此操作）：
 pcs resource restart rabbitmq-bundle

当前，Red Hat OpenStack Platform 存在的已知问题包括：

BZ#1321179

使用 `python-requests` 的 OpenStack 命令行客户端当前无法验证在 SAN 字段中有 IP 地址的证书。

BZ#1461132

如果将 Red Hat Ceph Storage 同时用作 Cinder 卷和 Cinder 备份的 Block Storage 后端，那么所有的增量备份都会转而生成完整备份，而且不会显示任何警告。这是一个已知问题。

BZ#1508449

OVN 会将 DHCP 直接用作 compute 节点上的 openflow 控制器（带有 ovn-controller）。但是，SR-IOV 实例会通过 VF/PF 直接连接网络。因此，SR-IOV 实例无法从任意位置接收 DHCP 回复。

要解决这个问题，请将 OS::TripleO::Services::NeutronDhcpAgent 更改为：

   OS::TripleO::Services::NeutronDhcpAgent: docker/services/neutron-dhcp.yaml

BZ#1515815

当路由器网关被清除后，与已被识别的 IP 地址相关的第 3 层流量都会被移除。已被识别的 IP 地址包括 PNF 和外部网关 IP 地址。这会导致流量过时，但不会引发任何功能问题。外部网关和 IP 地址不会频繁变化。当外部网络被删除时，过时流量也将随之移除。

BZ#1518126

在启用了 TLS 的高可用性部署中，Redis 无法正确地跨节点复制数据。Redis follower 节点中不包含 leader 节点的任何数据。建议对 Redis 部署禁用 TLS。

BZ#1519783

Neutron 可能会显示一个错误，声称已超出可用于创建 Neutron 路由器的配额。这是一个已知问题，即：由于 networking-odl 存在错误，Neutron DB 中的单个创建请求会创建多个路由器资源。要解决这个问题，请使用 OpenStack Neutron CLI 删除重复的路由器，然后重新创建路由器，以形成单个实例。

BZ#1557794

在用于备份和恢复 director undercloud 的过程中发现一个回归。所以，该过程要先完成修改和验证，然后才能发布。

因此，《备份和恢复 Director Undercloud》一书有时不适用于 Red Hat OpenStack Platform 13。在通用版本经过验证并予以发布后，我们将优先更新该过程。

BZ#1559055

OpenDaylight 日志记录中可能缺少较早前的日志。这是在对 OpenDaylight 进行 journald 日志记录（使用“docker logs opendaylght_api”命令）时的一个已知问题。目前的解决方法是，将 OpenDaylight 日志记录切换为“文件”机制，以将容器的内部操作记录到 /opt/opendaylight/data/logs/karaf.log 中。为此，需要把 heat 参数 OpenDaylightLogMechanism 配置为“file”。

BZ#1562035

在运行 docker-puppet 或 paunch 容器时，Docker 无法运行，而且 nsenter 调用会返回一个内核错误。这个问题已被确认为与使用 fork 函数的 unshare 调用有关的内核问题。与 RHEL 7.5.2 发行版本相关的下一个内核发行版本（计划于 6 月底发布）会修复这个问题。可能会在与 BZ #1577745 有关的请求中提供内核热修复程序。

或者，也可使用以下方法来解决：
1) 移除环境文件中的“TunedProfileName”参数，然后进行部署。据我们观察，如果部署时未使用 cpu-partitioning，重现性会下降。完成部署后，请按照以下步骤启用 tuned 配置集：
  * 配置 /etc/tuned/cpu-partitioning-variables.conf 中的“isolated_cores” 
  * 命令 - "tuned-adm profile cpu-partitioning"
  * 重启节点
注意：据我们观察，使用上述解决方法时，这个问题重现的可能性要低一些。

2) 运行 https://bugzilla.redhat.com/show_bug.cgi?id=1562035#c27 和 https://bugzilla.redhat.com/show_bug.cgi?id=1562035#c31 的注释中指定的命令 
注意：这将通过向容器开放主机 pid 来运行容器，但这并非所期望的结果。相关的详细步骤将在 OSP13 的下一个次发行版本中提供，以便不再需要使用“pid=host”这个方法来解决此问题。

BZ#1568012

如果将浮动 IP 与某个实例关联，然后再取消关联该浮动 IP，则无法连接到外部 IP。 如果在非 NAPT 交换机上创建的 VM 被关联到了某个浮动 IP，接着该浮动 IP 又被删除了，则租户 VLAN 网络就会出现上述无法连接的情况。这会导致 NAPT 交换机的 FIB 表中没有流量（仅零星存在）。


由于 FIB 表中没有条目，所以 VM 会丢失与公共网络的连接。

在将浮动 IP 与 VM 关联后，即可恢复与公共网络的连接。只要浮动 IP 与 VM 保持关联状态，VM 就能连接互联网。但是，您将失去来自外部网络的公共 IP/浮动 IP。

BZ#1568311

当未使用浮动 IP 的实例尝试连接其他路由器上使用浮动 IP 的另一个实例时，跨多个子网的 Nova 实例间的第 3 层连接可能会以失败告终。如果 Nova 实例横跨多个 compute 节点，就会出现上述情况。这个问题目前没有适用的解决方案。

BZ#1568976

由于存在可能导致部署或功能故障的功能加载错误，所以在部署期间可能会有一个或多个 OpenDaylight 实例无法正常启动。

在这种情况下，请采取以下措施：
 * 在 HA 部署中，至少要有两个 OpenDaylight 实例能够正常引导，否则部署可能会失败。对于此类案例，目前的解决方法是，使用“docker ps”命令检查每个容器的健康状况。如果健康状况不佳，则请重启容器：“docker restart opendaylight_api”。

 * 在基于 TLS 的部署中，所有 OpenDaylight 实例必须都能正确引导，否则部署将会失败。因此，必须重新开始部署，直至所有 OpenDaylights 都能成功引导。

BZ#1571864

如果在快进升级准备期间临时移除 Heat 栈资源，则会触发“RHEL 取消注册”。
所以，“RHEL 取消注册”会因 Heat 软件部署无法正常发出信号而停止。

为免出现此类问题，当 overcloud 使用的仍是 OSP 10 并准备执行最新的 overcloud 最低版本更新时，请按照以下步骤操作：
1. 编辑模板文件 /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration/rhel-registration.yaml
2. 删除该模板中的 RHELUnregistration 和 RHELUnregistrationDeployment 资源。
3. 继续执行最低更新并完成快进升级过程。

BZ#1573597

如果用作 Gnocchi  后端的 Swift 集群性能欠佳，则可能会在 collectd 日志中生成 503 错误，并在 gnocchi-metricd.conf 中生成“ConnectionError: ('Connection aborted.', CannotSendRequest())”错误。
为免出现此类问题，请增大 CollectdDefaultPollingInterval 参数的值，或改进 Swift 集群的性能。

BZ#1574708

如果将 OpenDaylight 实例从集群中移除后再重新建立连接时，实例可能无法成功加入集群。节点最终将会重新加入集群。

在这种情况下，应该进行以下操作：
 * 重启故障节点。
 * 监控 REST 端点，以验证集群成员是否健康： http://$ODL_IP:8081/jolokia/read/org.opendaylight.controller:Category=ShardManager,name=shard-manager-config,type=DistributedConfigDatastore
 * 响应中包含字段“SyncStatus”；如果值为“true”，则表明集群成员很健康。

BZ#1574725

在为两个不同的 Compute 节点调度 VLAN 供应商网络的同一子网中的多个 VM 时，VM 间的 ARP 有时会失败。

由于这些 VM 间的 ARP 数据包传输失败，所以这两个 VM 间基本上没有任何网络流量。

BZ#1575023

manila-share 服务无法初始化，因为改变 ceph-ansible 的复杂 ceph-keys 处理会导致 /etc/ceph/ceph.client.manila.keyring 文件中生成错误内容。

为使 manila-share 服务正常初始化，请按照以下步骤操作：
1) 复制 /usr/share/openstack/tripleo-heat-templates 以用于 overcloud 部署。

2) 编辑 .../tripleo-heat-templates/docker/services/ceph-ansible/ceph-base.yaml 文件，以将第 295 行的所有三斜线改成单斜线。
更改前：
mon_cap: 'allow r, allow command \\\"auth del\\\", allow command \\\"auth caps\\\", allow command \\\"auth get\\\", allow command \\\"auth get-or-create\\\"'
更改后：
mon_cap: 'allow r, allow command \"auth del\", allow command \"auth caps\", allow command \"auth get\", allow command \"auth get-or-create\"'

3) 只要您的原始 overcloud-deploy 命令中出现了 /usr/share/openstack-tripleo-heat 模板，部署 overcloud 以替换到 tripleo-heat-templates 副本的路径。

ceph 密钥 /etc/ceph/ceph.client.manila.keyring 文件将包含正确的内容，manila-share 服务将会正确初始化。

BZ#1575118

Ceph 发行版本 12.2.1 减少了每个 OSD 允许的最大 PG 数量。这个下限可能会导致监控器过早发出 HEALTH_WARN 消息。

监控器的警告阈值已从每个 OSD 300 个 PG 降至每个 OSD 200 个 PG。200 仍是常规建议目标值（每个 OSD 100 个 PG）的两倍。 这个限值可通过监控器上的 mon_max_pg_per_osd 选项来调整。旧的 mon_pg_warn_max_per_osd 选项已移除。

池所占用的 PG 数量无法降低。如果升级导致现有部署达到上限，您可在执行 ceph-upgrade 步骤时将该限值提高到其升级前的值。在环境文件中，请按照如下所示添加参数设置：

  parameter_defaults:
    CephConfigOverrides:
      mon_max_pg_per_osd: 300

该设置会应用于 ceph.conf，集群则会处于 HEALTH_OK 状态。

BZ#1575150

存在一个已知问题，即：当一个 OpenDaylight 集群成员停止（因故障或其他原因）后，OpenDaylight 集群可能会最多停止响应 30 分钟。这个问题的解决方法是：耐心等待，直至集群再次处于活动状态。

BZ#1575496

如果为包含 Director 的外部网络使用了物理主机接口，但该接口未连接 OVS 网桥，则该接口不会在 OpenDaylight 设置中传递流量。流量不会传递，您应该避免使用这类配置。

请务必在 overcloud 外部网络的 NIC 模板中使用 OVS 网桥。该网桥在 Director 中的默认名称为“br-ex”（虽然您可以使用任意名字）。您应该将用于外部网络的物理主机接口连接到该 OVS 网桥。

当您使用已连接到 OVS 网桥的接口时，部署就可以正常工作，至租户的外部网络流量也能正常工作。

BZ#1577975

有时，OpenDaylight 的 CPU 占用率可能会非常高。这个问题应该不会影响 OpenDaylight 的正常功能，虽然它可能会对其他系统服务存在潜在影响。

BZ#1579025

在 pacemaker 尝试对 slave 节点进行升级时，OVN pacemaker 资源代理 (RA) 脚本有时无法正确处理升级操作。如果 ovsdb 服务器报告状态为 RA 脚本的 master，但 master 的 IP 已被移到节点上，即会出现上述情况。这个问题会在上游解决。

出现这类问题时，neutron 服务器将无法连接 OVN North 和 South DB 服务器，所有到 neutron 服务器的 Create/Update/Delete API 都会失败。

通过重启 ovn-dbs-bundle 资源，可以解决这类问题。请在任意 Controller 节点上运行以下命令：

“pcs resource restart ovn-dbs-bundle”

BZ#1579417

无论租户网络中采用的是何种封装，都需要配置 VXLAN 隧道，才能支持 SNAT。如果使用的是 VLAN 租户网络，则还需正确配置 MTU，因为 VXLAN 隧道头会被添加到有效负载中，而这可能会导致数据包超出默认 MTU（1500 字节）。

必须正确配置 VXLAN 隧道，SNAT 流量才能从其中流过。
如果使用的是 VLAN 租户网络，请采用以下任一方法来配置 MTU，以便 SNAT 流量能够流经 VXLAN 隧道：
 * 配置基于 VLAN 租户的网络，以在每个网络配置中使用数值为 1450 的 MTU。
 * 将 NeutronGlobalPhysnetMtu heat 参数设置为 1450。注意：这意味着所有平面/VLAN 供应商网络的 MTU 都将为 1450，这可能不是您所期望的（尤其是对于外部供应商网络）。
 * 将租户网络底层的 MTU 配置为 1550（或更高值）。这包括设置租户网络 NIC 的 NIC 模板中的 MTU。

BZ#1581337

为了使用 PING 类型的健康监控器，HAProxy（我们的驱动器中用于实现网络负载均衡的默认软件）的版本必须至少为 1.6。如果使用低版本的 HAProxy，健康检查会在用户不知情的情况下使用 TCP 连接。

上游社区已通过在代码中增加检查环节来修复这一问题，这个检查环节会确定所使用的 HAProxy 版本并采取相应的措施：
如果使用的是 HAProxy v1.6 或更高版本，我们可以使用 PING。
否则，我们会继续使用 TCP 连接（对于这些 haproxy 版本，因为没有任何其他解决方案可供使用。所以最好使用 TCP 连接）。

在 OSP13 GA 中的问题是，HAProxy 作为 RHEL 频道的一部分来提供，而该频道使用的是旧版 HAProxy。因此，当 OSP13 用户配置 PING 类型的健康监控器时，将会建立 TCP 连接。

BZ#1583541

如果基于 SRIOV 的 Compute 实例和 OVS Compute 实例位于不同的网络中，则这两类实例无法相互连接。要解决这个问题，请使用已连接到这两个 VLAN 供应商网络的外部路由器。

BZ#1584518

默认情况下，RHOSP 不会在 nova 中配置 DifferentHostFilter/SameHostFilter 的可用性，但是有些测试需要这些设置才能正确完成。所以，某些安全组测试可能会随机地失败。

您应该跳过这些测试，或为您的 nova 配置添加过滤器。

BZ#1584762

如果在 undercloud 上手动启用了 Telemetry，则“hardware.*”指标会因各个节点上错误的防火墙配置而无法正常工作。

要解决这个问题，您需要使用 Control Plane 网络按照如下所示为 undercloud 部署添加额外模板，以手动设置“snmpd”子网：

parameter_defaults:
  SnmpdIpSubnet: 192.168.24.0/24

BZ#1588186

某个争用条件导致 Open vSwitch 无法连接 Opendaylight openflowplugin。目前，我们正准备在本产品的 13.z 发行版本中对此进行修复。

BZ#1590114

如果在 undercloud 上手动启用了 Telemetry，则“hardware.*”指标会因各个节点上错误的防火墙配置而无法正常工作。

要解决这个问题，您需要使用 Control Plane 网络按照如下所示为 undercloud 部署添加额外模板，以手动设置“snmpd”子网：

parameter_defaults:
  SnmpdIpSubnet: 192.168.24.0/24

BZ#1590560

ceph-ansible 工具有时不会将 ceph-create-keys 容器从创建它的节点中移除。

因此，部署可能会失败，并显示消息“Error response from daemon: No such container: ceph-create-keys”。这可能会对满足以下条件的 ceph-ansible 运行（包括全新部署）造成影响：拥有多个 compute 节点，或者拥有用作 ceph 客户端并会托管服务消耗型 Ceph 的自定义角色。

BZ#1590938

如果您在 RHCS3 上部署了三个以上的 OSD，并将池的 PG 数量设置为由 pgcalc (https://access.redhat.com/labs/cephpgc) 来决定，则部署将会失败，因为 ceph-ansible  会在所有 OSD 激活前创建池。

为避免出现这类问题，请将默认的 PG 数量设置为 32，并在部署完成后按照 Storage Strategies Guide 所述手动增加 PG 的数量 (https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html/storage_strategies_guide/placement_groups_pgs#set_the_number_of_pgs)。

BZ#1590939

由于 ceph-ansible OpenStack 池任务的容器名称错误，所以无法将 Ceph MON 和 OSD 置于一处。
标准 HCI (Computes + OSD) 不会受到影响。

BZ#1593290

如果在连有基于 SR-IOV 的网络接口的客户机正在运行的情况下，重启了 nova-compute 服务，随后又移除了该客户机，则之后便无法再将该节点上的 SR-IOV VF 连接至任何客户机。这是因为系统会在服务启动时逐一枚举可用的设备，但设备若与客户机相连，就不会包含在主机设备列表中。

您必须在移除客户机后重启“nova-compute”服务。在移除客户机并重启该服务后，可用 SR-IOV 设备的列表就会正确显示。

BZ#1593715

非安全 registry 列表的更新会比在主要升级期间抓取某些容器镜像要晚。所以，来自新引入的非安全 registry 的容器镜像无法在“openstack overcloud upgrade run”命令运行期间下载。

您可以使用以下任一方法来解决这个问题：

方法 A：在包含 Pacemaker 所管理容器的节点上手动更新 /etc/sysconfig/docker 文件，然后添加任意新引入的非安全 registry。

方法 B：先运行“openstack overcloud deploy”，然后立即进行升级，然后使用带有 DockerInsecureRegistryAddress 参数的环境文件来提供所需的新的非安全 registry 列表。

所有容器镜像应该都会在升级期间成功下载。

BZ#1593757

虽然系统报告显示，在现有 overcloud 部署上启用 Octavia 成功，但是，由于 Controller 节点上的防火墙规则配置错误，所以无法访问 Octavia API 端点。

解决方法：

在所有 controller 节点上，添加防火墙规则，并确保它们已插在 DROP 规则前面：

IPv4：
  # iptables -A INPUT -p tcp -m multiport --dports 9876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy ipv4" -j ACCEPT
  # iptables -A INPUT -p tcp -m multiport --dports 13876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy_ssl ipv4" -j ACCEPT
  # iptables -A INPUT -p tcp -m multiport --dports 9876,13876 -m state --state NEW -m comment --comment "120 octavia_api ipv4" -j ACCEPT


IPv6：
  # ip6tables -A INPUT -p tcp -m multiport --dports 9876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy ipv6" -j ACCEPT
  # ip6tables -A INPUT -p tcp -m multiport --dports 13876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy_ssl ipv6" -j ACCEPT
  # ip6tables -A INPUT -p tcp -m multiport --dports 9876,13876 -m state --state NEW -m comment --comment "120 octavia_api ipv6" -j ACCEPT

重启 HAProxy：
  # docker restart haproxy-bundle-docker-0

BZ#1595363

在快进升级过程中，用户会将 undercloud 从 v10 升级到 v11。在某些情况下，nova-api.log 可能会报告以下错误：

“Unexpected API Error. Table 'nova_cell0.instances' doesn't exist”

您可以通过运行以下命令来解决这一错误：

$ sudo nova-manage api_db sync

这不是一个关键问题，应该不会对快进升级流程造成重大影响。