本节中所包括的错误已在 RHEA-2018:2086 公告中解决。如需了解这个公告的更多相关信息，请访问以下链接：https://access.redhat.com/errata/RHEA-2018:2086。

ceph-ansible

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

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

gnocchi

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

opendaylight

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

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

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

openstack-cinder

之前，在进行离线升级时，cinder 服务因滚动升级机制而必须重启两次。

现可利用名为“--bump-versions”的全新可选参数（已添加到 cinder-manage db sync 命令中）来跳过这两个系统重启操作。

Block Storage 服务 (cinder) 会利用同步锁定，来防止卷镜像缓存中出现重复条目。但是，这类锁定所涉及的范围过广，并会导致出现要求从镜像创建卷的多个并行请求，以争用锁定操作；即使镜像缓存未启用，也是如此。

这些要求从镜像创建卷的并行请求将被序列化，所以不会并行运行。

因此，同步锁定已经过更新，以最大限度地缩小锁定所涉及的范围，并使其仅在卷镜像缓存已启用时生效。

现在，要求从镜像创建卷的并行请求会在卷镜像缓存禁用的情况下并行运行。当卷镜像缓存已启用时，锁定会最大限度地缩小范围，以确保仅在缓存中创建单个条目。

openstack-manila

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

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

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

openstack-neutron

在向路由器添加接口或从路由器中删除接口时，如果已在 DHCP 代理上启用隔离的元数据，则该网络的元数据代理不会更新。

所以，如果实例不在路由器所连接的网络中，则无法获取元数据。

在添加或删除路由器接口时，您需要更新元数据代理。然后，实例才能在其网络相互隔离的情况下从 DHCP 命名空间获取元数据。

openstack-selinux

之前，virtlogd 服务会在客户虚拟机启动时重复记录 AVC 拒绝错误。通过此次更新，virtlogd 服务不会再尝试向 systemd 发送关机禁止调用，因而不会再出现上述错误。

openstack-swift

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

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

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

openstack-tripleo-common

Octavia 无法扩展至实际工作负载，因为“service”项目的默认已配置配额会限制可在 overcloud 上创建的 Octavia 负载均衡器的数量。

为免出现此类问题，请以 overcloud 管理员用户的身份将所需的配额设置为无限制，或设置为某个足够大的值。例如，在 undercloud 上运行以下命令：

# source ~/overcloudrc
#  openstack quota set --cores -1 --ram -1 --ports -1 --instances -1 --secgroups -1 service

tripleo.plan_management.v1.update_roles 无法将 overcloud 计划名称（swift 容器名称）或 zaqar 队列名称传递至其所触发的子工作流。这导致在使用 overcloud 计划名称（而非默认值“overcloud”）时会出现错误行为。这个修复程序可以正确传递这些参数，并恢复正确的行为。

如果容器被设置为自动重启，则不存在“docker kill”命令。如果用户尝试运行“docker kill <容器>”，则它可能会无限期挂起。在这种情况下，可以使用 CTRL+C 来停止该命令。

为免出现此类问题，请使用“docker stop”（而非“docker kill”）来停止容器化服务。

原因：“openstack overcloud node configure”命令原先只会为“deploy-kernel”和“deploy-ramdisk”参数获取镜像名称，而不获取镜像 ID。在安装这个修复程序后，镜像 ID 现在也可被接受。

openstack-tripleo-heat-templates

这个增强功能支持，通过 director 部署启用 RT 的 compute 节点，以及“常规”的 compute 节点。

1. 基于 tripleo-heat-templates/environments/compute-real-time-example.yaml 一个创建 compute-real-time.yaml 环境文件，这个文件至少需要配置以下各项的值来设置 ComputeRealTime 角色的参数：

 * IsolCpusList and NovaVcpuPinSet：应该为实时工作负载保留的 CPU 内核的列表。这取决于实时 compute 节点上的 CPU 硬件。

 * KernelArgs：设置为“default_hugepagesz=1G hugepagesz=1G hugepages=X”，其中的 X 取决于客户机的数量及其将配备的内存容量。

2. 构建并上传 overcloud-realtime-compute 镜像：

 * 准备仓库（用于 CentOS）：
   - sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-XXX.el7.centos.noarch.rpm
   - sudo -E tripleo-repos current-tripleo-dev
   - export DIB_YUM_REPO_CONF="/etc/yum.repos.d/delorean* /etc/yum.repos.d/quickstart*"

 * openstack overcloud image build --image-name overcloud-realtime-compute --config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-realtime-compute.yaml --config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-realtime-compute-centos7.yaml

 * openstack overcloud image upload --update-existing --os-image-name overcloud-realtime-compute.qcow2

3. 使用 ComputeRealTime 以及所需的所有其他角色来创建 roles_data.yaml，例如：openstack overcloud roles generate -o ~/rt_roles_data.yaml Controller ComputeRealTime ...；然后，采用任一常用方式将 ComputeRealTime 角色分配给实时节点。请参阅 https://docs.openstack.org/tripleo-docs/latest/install/advanced_deployment/custom_roles.html

4. 部署 overcloud：
openstack overcloud deploy --templates -r ~/rt_roles_data.yaml -e ./tripleo-heat-templates/environments/host-config-and-reboot.yaml -e ./compute-real-time.yaml [...]

在 HA 配置中使用 glance-direct 方法时，需要使用共享分级区域。如果没有通用的分级区域，可能无法在 HA 配置中使用“glance-direct”方法上传镜像。针对 controller 节点的传入请求会被分发到各个可用的 controller 节点。一个控制器会负责处理第一步，另一个控制器则会负责处理第二个请求，这两个控制器还会将镜像写入不同的分级区域。第二个控制器将无权访问负责处理第一步的控制器所使用的分级区域。

Glance 支持多种镜像导入方法，其中包括“glance-direct”方法。此方法采用的是三步式方案：创建镜像记录，将镜像上传至分级区域，然后将镜像从分级区域传输至存储后端，以使镜像处于可用状态。在 HA 设置（即包含 3 个 controller 节点）中，glance-direct 方法需要一个通用分级区域，该区域会在多个 controller 节点间共享一个文件系统。

现在，您可以对列有 Glance 支持的导入方法的列表进行配置。默认配置不会启用“glance-direct”方法（默认情况下支持“从 Web 下载”这种导入方法）。为了避免出现问题并可靠地在 HA 环境中将镜像导入 Glance，请勿启用“glance-direct”方法。

在主机停止运行 /run/openvswitch 文件夹后，openvswitch systemd 脚本会将该文件夹删除。
ovn-controller 容器中的 /run/openvswitch 路径已是一个过时的目录。该服务会在再次启动时重新创建这个文件夹。为了能让 ovn-controller 再次访问这个文件夹，您必须重新挂载这个文件夹，或重启 ovn-controller 容器。

添加了一个新的 CinderRbdExtraPools Heat 参数，它会指定一个列表，其中列有可与 Cinder 的 RBD 后端搭配使用的 Ceph 池。系统会为该列表中的每一个池各自创建一个额外的 Cinder RBD 后端驱动。这是对于 CinderRbdPoolName 关联的标准 RBD 后端驱动的补充。这个新参数是可选项，其默认值是一个空白列表。该参数指定的所有池都会关联至一个 Ceph 集群。

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

这个增强功能支持向 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

OVN 元数据服务原先不会部署在基于 DVR 的环境中。因此，实例无法获取实例名称、公钥等元数据。

这个补丁可以启用上述服务，以使所有已引导的实例都能获取元数据。

Cinder 后端服务的 Heat 模板原先会触发 Puppet 在 overcloud 主机上部署 cinder-volume 服务，无论您是否想在容器中部署该服务。这会导致 cinder-volume 服务被部署了两次：一次在容器中，一次在主机上。

正因如此，当 OpenStack 卷操作（如创建和附加卷）由主机上运行的未授权 cinder-volume 服务来负责处理时，此类操作会以失败告终。

所以，我们对 Cinder 后端 heat 模板进行了更新，它不会再为 cinder-volume 服务部署第二个实例。

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

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 服务将会正确初始化。

原先，在配置 HA cinder-volume 服务时，cinder 的 DEFAULT/host 配置会被设置为“hostgroup”。其他 cinder 服务（cinder-api、cinder-scheduler、cinder-backup）也会使用“hostgroup”来进行配置，无论服务是由哪个 overcloud 节点来运行的。这些服务的日志消息看上去全都源自同一个“hostgroup”主机，因而很难判断各条消息具体是由哪个节点生成的。

现在，在实施 HA 部署时，cinder-volume 的 backend_host 会被设置为“hostgroup”，而不是将 DEFAULT/host 设置为该值。这可确保每个节点的 DEFAULT/host 值都是唯一的。

因此，源于 cinder-api、cinder-scheduler 和 cinder-backup 的日志消息会正确地与生成该消息的节点关联。

原先，升级到新的发行版本后，系统会使用先前的发行版本中的旧 RPC 版本来阻止 Block Storage 服务 (cinder)。所以，需要使用最新 RPC 版本的所有 cinder API 请求都会以失败告终。

现在，当升级到新的发行版本时，所有 cinder RPC 版本都会更新，以匹配最新的发行版本。

python-cryptography

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

原先，在安装 python-cryptography 后，从 RDO 的首次导入会因缺少 Obsoletes 而失败。这个软件包的 RHEL 7 版现可正确导入，因为它包含正确的 Obsoletes 条目。

这个修复程序为 python-cryptography 增加了 Obsoletes。

python-ironic-tests-tempest

在升级到 OSP 发行版本 13 后，升级前安装的 tempest 插件 (-tests) rpm 便无法再运行。初始升级软件包中不包含废弃旧 rpm 所需的 epoch 命令。OSP 13 并未提供 sub-rpm，新插件 rpm 中的 Obsoletes 也无法正确废弃相应的 rpm。

要修复这个问题，请更新 obsoletes；或者，手动卸载旧的 -rpm，然后再手动安装替换插件 python2-*-tests-tempest。

python-networking-ovn

为帮助保持 neutron 与 OVN 数据库之间的一致性，我们针对各项配置变化进行了内部比较，并在后端进行了验证。我们还为每一项配置变化分配了修订编号，并利用预定任务，验证了针对上述数据库所做的所有创建、更新和删除操作。

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

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

原先，在创建没有网关的子网时，不会添加任何 DHCP 选项，而且此类子网上的实例无法获取 DHCP。

现在则会使用元数据/DHCP 端口来执行这一操作，这样实例就能获取 IP 地址。您必须启用这个元数据服务。
对于没有外部网关的子网上的实例，现能按照 DHCP 通过 OVN 元数据/DHCP 端口来获取自己的 IP 地址。

原先，现有的 L3 HA 调度程序会考虑节点的优先级。所以，所有网关都由同一个节点来托管，而且负载不会被分发到候选节点。

这个修复程序会实施一种算法，以在调度网关路由器时选用负载最轻的节点。现在，系统会调用负载最轻的网络节点上的网关端口，以将负载均匀地分发到各个端口。

原先，在将子端口重新分配给另一虚拟机监控器上的其他主干时，子端口的绑定信息不会随之更新，子端口也不会转变为 ACTIVE 。

现在，当您从主干中删除子端口时，这个修复程序会清除相关的绑定信息。子端口现会在重新分配给另一虚拟机监控器上的其他中继端口后转变为 ACTIVE。

python-os-brick

原先，在使用 iSCSI 查找功能时，节点的 startup 配置会从“automatic”还原成“default”，这导致系统不会在重启后启动相关服务。这个问题已通过以下方法得以修复：每次进行 discovery 操作，系统会恢复所有的 startup 值。

python-zaqar-tests-tempest

升级操作原先存在依赖关系方面的问题，在 Queens 版本中，tempest 的插件集是从 openstack-*-tests rpm 子数据包中提取的。但是，并非所有软件包都拥有正确的 Provides 和 Obsoletes 组合。OSP 13 并没有 -tests (unittest sub-rpms)。

在尝试使用先前的发行版本所安装的 -tests 来进行升级时，操作会因依赖关系方面的问题而失败。

为了解决这个问题，我们重新引入了旧版 -tests rpm 的 Obsoletes。