Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

发行注记

Red Hat OpenStack Platform 13

Red Hat OpenStack Platform 13 发行详细信息

OpenStack 文档团队

Red Hat 客户内容服务

摘要

本文档概述了此 Red Hat OpenStack Platform 发行版本的主要功能、改进和已知问题。

第 1 章 简介

1.1. 关于本发行版本

本 Red Hat OpenStack Platform 发行版本基于 OpenStack“Queens”发行版本,包括 Red Hat OpenStack Platform 特有的其他功能、已知问题以及已解决的问题。

本文中仅包含与 Red Hat OpenStack Platform 相关的变更。OpenStack“Queens”发行版本本身的发行注记可从以下位置获得:https://releases.openstack.org/queens/index.html

Red Hat OpenStack Platform 同时使用了其它红帽产品的组件,相关信息可以访问以下链接获得:

https://access.redhat.com/zh_CN/node/2572141

如需试用 Red Hat OpenStack Platform,请通过以下网址注册:

https://www.redhat.com/zh/topics/openstack

注意

Red Hat OpenStack Platform 用例可以使用 Red Hat Enterprise Linux High Availability Add-On。有关这个附件组件的更多详细信息,请参阅以下 URL:https://www.redhat.com/zh/technologies/linux-platforms/enterprise-linux。有关要与 Red Hat OpenStack Platform 搭配使用的软件包版本的详细信息,请参阅以下 URL:https://access.redhat.com/site/solutions/509783

1.2. 要求

Red Hat OpenStack Platform 支持最新版本的 Red Hat Enterprise Linux。Red Hat Enterprise Linux 7.5 支持这个版本的 Red Hat OpenStack Platform。

Red Hat OpenStack Platform 仪表板是一个基于 web 的用户界面,用户可以通过它来管理 OpenStack 资源和服务。本发行版本中的仪表板支持以下网络浏览器的最新发行版:

  • Chrome
  • Firefox
  • Firefox ESR
  • Internet Explorer 11 和更高版本(需要禁用 Compatibility Mode
注意

在部署 Red Hat OpenStack Platform 前,请务必考虑可用部署方法的特性。如需了解更多相关信息,请参阅 Installing and Managing Red Hat OpenStack Platform

1.3. 部署限制

如需获得 Red Hat OpenStack Platform 的部署限制列表,请参阅 Deployment Limits for Red Hat OpenStack Platform

1.4. 数据库容量管理

有关在 Red Hat OpenStack Platform 环境中管理 MariaDB 数据库容量的推荐方案,请参阅 Database Size Management for Red Hat Enterprise Linux OpenStack Platform

1.5. 认证的驱动器和插件

如需获得 Red Hat OpenStack Platform 中的已认证驱动和插件的列表,请参阅 Component, Plug-In, and Driver Support in Red Hat OpenStack Platform

1.6. 认证的客户机操作系统

如需获得 Red Hat OpenStack Platform 中的已认证客户机操作系统的列表,请参阅 Certified Guest Operating Systems in Red Hat OpenStack Platform and Red Hat Enterprise Virtualization

1.7. Bare Metal Provisioning 支持的操作系统

如需获得可通过 Bare Metal Provisioning (ironic) 安装到 Red Hat OpenStack Platform 裸机节点的受支持客户机操作系统的列表,请参阅 Supported Operating Systems Deployable With Bare Metal Provisioning (ironic)

1.8. 支持的虚拟机监控程序

Red Hat OpenStack Platform 只支持与 libvirt 驱动一起使用(在 Compute 节点上使用 KVM 作为虚拟机监控器)。

从 Red Hat OpenStack Platform 7 (Kilo) 版本开始完全支持 Ironic。通过 Ironic,您可以使用常用的技术(如 PXE 引导和 IPMI)来配备裸机,并支持使用可插入的驱动器来实现与特定厂商相关的功能。

红帽不支持其它 Compute 虚拟化驱动器,如 VMware "direct-to-ESX" 虚拟机监控程序和非 KVM libvirt 虚拟机监控程序。

1.9. Content Delivery Network (CDN) 仓库

本节介绍部署 Red Hat OpenStack Platform 13 所需的仓库设置。

您可以通过 Content Delivery Network (CDN) 安装 Red Hat OpenStack Platform 13。为此,请配置 subscription-manager 以便使用正确的仓库。

运行以下命令可启用 CDN 仓库:

#subscription-manager repos --enable=[reponame]

运行以下命令可禁用 CDN 仓库:

#subscription-manager repos --disable=[reponame]

表 1.1. 所需的仓库 (x86_64)

仓库名称仓库标签

Red Hat Enterprise Linux 7 Server (RPM)

rhel-7-server-rpms

Red Hat Enterprise Linux 7 Server - RH Common (RPM)

rhel-7-server-rh-common-rpms

Red Hat Enterprise Linux High Availability(面向 RHEL 7 服务器)

rhel-ha-for-rhel-7-server-rpms

Red Hat OpenStack Platform 13 for RHEL 7 (RPMs)

rhel-7-server-openstack-13-rpms

Red Hat Enterprise Linux 7 Server - Extras (RPM)

rhel-7-server-extras-rpms

表 1.2. 可选仓库 (x86_64)

仓库名称仓库标签

Red Hat Enterprise Linux 7 Server - Optional

rhel-7-server-optional-rpms

Red Hat OpenStack Platform 13 Operational Tools for RHEL 7 (RPMs)

rhel-7-server-openstack-13-optools-rpms

表 1.3. 所需的仓库 (ppc64le)

仓库名称仓库标签

Red Hat Enterprise Linux for IBM Power, little endian

rhel-7-for-power-le-rpms

Red Hat OpenStack Platform 13 for RHEL 7 (RPMs)

rhel-7-server-openstack-13-for-power-le-rpms

要禁用的仓库

下表概述了您必须禁用的仓库,以便确保 Red Hat OpenStack Platform 13 能正常工作。

表 1.4. 要禁用的仓库

仓库名称仓库标签

Red Hat CloudForms Management Engine

"cf-me-*"

Red Hat Enterprise Virtualization

"rhel-7-server-rhev*"

Red Hat Enterprise Linux 7 Server - Extended Update Support

"*-eus-rpms"

警告

Red Hat OpenStack Platform 软件仓库中的一些软件包和 Extra Packages for Enterprise Linux (EPEL) 软件仓库提供的软件包有冲突。启用了 EPEL 软件仓库的系统不支持使用 Red Hat OpenStack Platform。

1.10. 产品支持

可用资源包括:

客户门户网站

红帽客户门户网站提供了丰富的资源,助您规划、部署和维护 OpenStack 系统。这些资源包括:

  • 知识库文档和解决方案。
  • 技术概要。
  • 产品文档。
  • 支持用例管理。

请通过 https://access.redhat.com/ 访问客户门户网站。

邮件列表

红帽提供了以下与 OpenStack 用户相关的公共邮件列表:

  • rhsa-announce 邮件列表提供了 Red Hat OpenStack Platform 等红帽产品的安全补丁程序发行通知。

请通过 https://www.redhat.com/mailman/listinfo/rhsa-announce 进行订阅。

第 2 章 主要新功能

本节介绍了这个 Red Hat OpenStack Platform 发行版本中包括的主要新功能。

2.1. Red Hat OpenStack Platform Director

本节概述了 director 的主要新功能。

快进升级
director 通过提供了跨多个版本的快进升级方法,尤其是从 Red Hat OpenStack Platform 10 升级至 Red Hat OpenStack Platform 13。这是为了让用户能够继续使用某个被视为长生命版本的 OpenStack 版本,并在下一个长生命版本发布时进行升级。相关完整说明可在 Fast Forward Upgrades 指南中找到
L3 路由骨干/分支网络
director 能为置备和内省功能定义多个网络。如将这一功能与可组合网络搭配使用,用户便可为 overcloud 置备和配置完整的 L3 路由骨干/分支架构。相关完整说明可在 Spine Leaf Networking 指南中找到
Red Hat Virtualization 驱动
Director OpenStack Bare Metal (ironic) 服务包含用于管理 Red Hat Virtualization 环境中的虚拟节点的驱动。这个驱动允许 Director 使用 Red Hat Virtualization 中部署的 Controller 节点来置备和支持 overcloud。有关新的虚拟化功能的更多信息,请参阅 Virtualize your OpenStack control plane with Red Hat Virtualization and Red Hat OpenStack Platform 13

2.2. 容器

本节概述了 Red Hat OpenStack Platform 中用于实现容器化的主要新功能。

完全容器化服务
本发行版本会以容器的形式来提供所有的 Red Hat OpenStack Platform 服务,包括上一版本中未容器化的服务:OpenStack Networking (neutron)、OpenStack Block Storage (cinder) 和 OpenStack Shared File Systems (manila)。overcloud 现会使用完全容器化的服务。

2.3. Bare Metal 服务

本节概述了 Bare Metal (ironic) 服务的主要新功能。

2.4. Ceph 存储

本节概述了 Ceph 存储的主要新功能。

Red Hat Ceph Storage 3.0 支持
对于本发行版本,Red Hat Ceph Storage 3.0 (luminous) 是 Red Hat OpenStack 默认支持的 Ceph 版本,也是 director 默认部署的版本。Ceph 现支持从版本 2.x 滚动升级至版本 3。如果您的 Ceph 集群是使用 director 来部署的,那么当您升级到这个新的 OpenStack 发行版本时,Red Hat Ceph Storage 也会随之升级到 3.0。
横向扩展 Ceph 元数据服务器和 RADOS 网关节点
Red Hat Ceph Storage 3.0 新增了一项支持功能,可通过适当配置 Ceph 文件系统 (CephFS),在多个元数据服务器 (MDS) 间扩展元数据负载。完成相关配置后,Ceph 集群中可供使用的额外专用 MDS 服务器会自动分配,以处理这类额外负载。此外,还可添加新的专用 Ceph RADOS 网关 (RGW) 节点,以便 RGW 按需进行纵向扩展。
使用 NFS 的 Manila CephFS 存储
Shared File System 服务 (manila) 支持使用 NFSv4 协议挂载由 Ceph 文件系统 (CephFS) 提供支持的共享文件系统。在 Controller 节点上运行的 NFS-Ganesha 服务器用于将 CephFS 导出至高可用性 (HA) 租户。租户间相互隔离,他们或许只能通过提供的 NFS 网关接口来访问 CephFS。这个新功能已完全整合到 director 中,因而可针对 Shared File System 服务进行 CephFS 后端部署和配置。
增强对于多个 Cinder Ceph 池的支持
Block Storage (cinder) RADOS 块设备 (RBD) 后端可以使用 director 模板参数 CinderRbdExtraPools 映射至同一 Ceph 集群中的不同池。系统会为与这个参数关联的每一个 Ceph 池都创建一个新的 Block Storage RBD 后端,与 CinderRbdPoolName 参数关联的标准 RBD 后端除外。
使用 ceph-ansible 的 RBD 镜像 Director
Ceph rbd-mirror 守护进程会从远程集群调用镜像更新,并将这些更新应用于本地集群中的镜像。RBD 镜像会使用 ceph-ansible 和 Red Hat Ceph Storage 3.0 (luminous) 以容器的形式进行部署。rbd-mirror 不会复制与该镜像相关的 OpenStack 元数据。

2.5. Compute

本节概述了 Compute 服务的主要新功能。

实时 KVM 集成

现可为实时 KVM (RT-KVM) 与 Compute 服务之间的集成提供全面支持。RT-KVM 的优点包括:

  • 系统调用和中断的平均延迟较为确定且较低。
  • 客户机实例支持精确时间协议 (PTP),可以准确地同步时钟(适用于本发行版本的社区级支持)。

2.6. 高可用性

本节概述了高可用性的主要新功能。

适用于 Instance HA 的 director 集成功能
现在,您可以使用 director 来部署 Instance HA。您无需进行额外的手动配置,即可为 Instance HA 进行安装和升级配置。
注意

只有版本 13 和更高版本才会提供适用于 Instance HA 的 director 集成功能。要从早前的版本升级到版本 13(包括快进升级),您必须先手动禁用 Instance HA。

2.7. 指标和监控

本节概述了与指标和监控组件相关的主要新功能和变更。

collectd 5.8 集成

collectd 5.8 版包含以下额外插件:

  • ovs-stats - 该插件会收集 OVS 所连网桥和接口的统计信息。
  • ovs-events - 该插件会监控 Open vSwitch (OVS) 所连接口的链路状态,向 collectd 分发值,并在 OVS 数据库中的链路状态发生变化时发出通知。
  • hugepages - hugepages 插件可按编号、字节或百分比在平台上监控可用和已用的巨页。
  • intel-rdt - intel_rdt 插件会收集由 Intel 资源调配技术 (Intel® RDT) 的监控功能(如缓存监控技术 (CMT)、内存带宽监控 (MBM))提供的信息。这些功能会提供有关共享资源使用情况的信息,如上一级缓存占用情况、本地内存带宽使用情况、远程内存带宽使用情况以及每个时钟的相关说明。
  • libvirt 插件扩展 - 对 libvirt 插件进行扩展,是为了支持平台上的“CMT”、“MBM”、“CPU 固定”、“利用率”和“状态”指标。
collectdgnocchi 集成

collectd-gnocchi 插件会将指标发送至 gnocchi。默认情况下,该插件会创建一个名为 collectd 的资源类型,并为受监控的每一个主机创建一个新资源。

每个主机都有一个列表,其中列有按照以下命名规范动态创建的各项指标:

plugin-plugin_instance/type-type_instance-value_number

为了正确地创建指标,请确保归档策略规则与之匹配。

支持包含多个 RabbitMQ 服务器的 sensu
在本发行版本中,Red Hat OpenStack Platform 支持包含多个 RabbitMQ 服务器的 sensu。为此,您需要在 config.yaml 文件中使用 MonitoringRabbitCluster 参数。
支持 Intel 资源调配技术/内存带宽监控
“内存带宽监控”(MBM) 是 Intel® 资源调配技术 (RDT) 中的一个集成功能。它会收集所有节点中的内存使用和可用性信息,然后将这些信息提供给 OpenStack,以便其做出更加明智的调度决策并满足 SLA 要求。

2.8. 网络功能虚拟化

本节概述了网络功能虚拟化 (NFV) 的主要新功能。

适用于 NFV 工作负载的实时 KVM Compute 角色
实时 KVM (RT-KVM) Compute 节点现可支持 NFV 工作负载,并新增了“RT-KVM Compute 节点”这一角色。这个新角色可以开放一部分具备实时功能的 Compute 节点,以支持具有严格延迟要求的客户机。

2.9. OpenDaylight

本节概述了 OpenDaylight 服务的主要新功能。

OpenDaylight 集成

OpenDaylight 是一个灵活的模块化开放 SDN 平台,本 Red Hat OpenStack Platform 发行版本现可为其提供全面支持。红帽发布的这个最新版本中整合了经过精心挑选的 OpenDaylight 组件,这些组件旨在启用 OpenDaylight SDN 控制器作为 OpenStack 的网络后端。该解决方案中所用的关键 OpenDaylight 项目为 NetVirt,可以支持 OpenStack neutron API。

如需更多相关信息,请参阅 Red Hat OpenDaylight Product GuideRed Hat OpenDaylight Installation and Configuration Guide

2.10. OpenStack Networking

本节介绍了 Networking 服务的主要新功能。

Octavia LBaaS
Octavia 现已受到全面支持。Octavia 是一个可以实现负载均衡的官方 OpenStack 项目,旨在用来替代当前基于 HAProxy 的实现。Octavia 不但能实现 LBaaS v2 API,还能提供其他功能。Octavia 包含引用负载均衡驱动器,后者可借助 amphora(以 Compute VM 的形式实现)达到负载均衡。
开放虚拟网络 (OVN)
OVN 现已受到全面支持。OVN 是一种基于 Open vSwitch 的网络虚拟化解决方案,用于为实例提供网络服务。OVN 可为 neutron API 提供全面支持。

2.11. 安全性

本节概述了与于安全性组件相关的主要新功能。

Barbican
OpenStack Key Manager (barbican) 是 Red Hat OpenStack Platform 的口令管理器。您可以利用 barbican API 和命令行集中管理 OpenStack 服务所使用的证书、密钥和密码。
Barbican - 支持已加密的卷
您可以使用 barbican 来管理 Block Storage (cinder) 加密密钥。该配置会使用 LUKS 来加密实例所关联的磁盘,包括引导磁盘。密钥的管理对于用户是完全透明的。
Barbican - glance 镜像签名
您可以配置 Image 服务 (glance),以验证上传的镜像是否有被篡改。镜像会先用存储在 barbican 中的密钥签名,然后再在每次使用前接受验证。
与策略决策点 (PDP) 集成
对于依靠策略决策点 (PDP) 来控制资源访问权限的客户,Identity 服务 (keystone) 现可将项目与外部 PDP 集成,以进行授权检查。外部 PDP 不但可以评估访问请求,还可根据已确立的策略允许或拒绝访问。
基础架构和虚拟化强化
“AIDE 入侵检测”现在是一个“技术预览”功能。director 的 AIDE 服务允许操作者集中设置其入侵检测规则集,然后在 overcloud 上安装和设置 AIDE。

2.12. 存储

本节概述了适用于存储组件的主要新功能。

Block Storage - Block Storage 服务的容器化部署
现在,本发行版本会默认针对 Block Storage 服务 (cinder) 进行容器化部署。如果您为这些服务所选择使用的后端需要依赖外部安装,则必须获取针对相关供应商的容器以完成部署。
Block Storage - 多后端可用域
现在,Block Storage 服务 (cinder) 允许使用新的驱动配置选项 backend_availability_zone 在配置文件的后端部分中定义后端可用域。在先前的版本中,cinder-volume 中配置的后端必须属于同一存储可用域。
Block Storage - OpenStack Key Manager 支持
Block Storage 服务 (cinder) 现可使用 OpenStack Key Manager (barbican) 来存储卷加密密钥。该功能可通过在 director 中配置 OpenStack Key Manager 来启用。用户可以通过 Identity 服务 (keystone) 使用“admin”或“creator"角色在 OpenStack Key Manager 中添加新密钥。
Block Storage - RBD 驱动器加密支持
RBD 驱动器现会使用 LUKS 来执行 Block Storage 服务 (cinder) 卷加密操作。该功能可以使用 Block Storage 服务和 Compute 服务来加密 RBD 上的各个卷,以确保静态数据的安全性。RBD 驱动器加密操作需要使用 OpenStack Key Manager (barbican) 才能完成,并且只能针对 Block Storage 服务执行这一操作。
Image 服务 - Image 签名和验证支持
Image 服务 (glance) 现可使用 OpenStack Key Manager (barbican) 为可引导镜像签名并进行签名验证。现在,在存储镜像之前,会先验证镜像签名。您必须要为原始镜像添加加密签名,然后才能将其上传到 Image 服务。在完成引导后,系统会使用这个签名来验证镜像。OpenStack Key Manager 可为签名密钥提供密钥管理支持。
Object Storage - 静态加密和 OpenStack Key Manager 支持
Object Storage (swift) 服务现可在 CTR 模式下使用存储在 OpenStack Key Manager (barbican) 中的 256 位密钥,按照 AES 以加密形式存储对象。在使用 director 为 Object Storage 启用加密功能后,系统会创建单个密钥,以用于加密集群中的所有对象。这样不但可以保护对象,还能维持 Object Storage 集群的安全合规性。
Shared File System - Shared File System 服务的容器化部署
现在,本发行版本会默认针对 Shared File System 服务 (manila) 进行容器化部署。如果您为这些服务所选择使用的后端需要依赖外部安装,则必须获取针对相关供应商的容器以完成部署。
Shared File System - 利用 NetApp ONTAP cDOT 驱动器支持 IPv6 访问规则
现在,Shared File System 服务 (manila) 支持通过 IPv6 网络导出由 NetApp ONTAP 后端支持的共享内容。对于已导出共享内容的访问,则会通过 IPv6 客户端的地址来加以控制。

2.13. 技术预览

本节概述了作为技术预览包括在 Red Hat OpenStack Platform 13 中的功能。

注意

如需了解被标记为技术预览的功能的支持范围,请参阅 Technology Preview Features Support Scope

2.13.1. 新的技术预览

以下新功能以技术预览的形式出现:

基于 Ansible 的配置 (config download)
director 现可基于 overcloud 计划生成一组 Ansible playbook。这将 overcloud 的配置方法从 OpenStack Orchestration (heat) 变成了基于 Ansible 的方法。部分受支持的 OpenStack Platform 13 功能(如升级)将会使用这个功能。但是,我们不建议,对于生产环境,在不受支持的功能中使用这一功能。这一功能当前只是一个技术预览功能。
OVS 硬件分流
Open vSwitch (OVS) 硬件分流功能会利用 SmartNIC 将繁重的处理转移到硬件上,以加快 OVS 的速度。这样便可通过将 OVS 处理分流到 SmartNIC 上来减少被占用的主机资源。

2.13.2. 过去发布的技术预览

以下功能仍然以技术预览的形式出现:

Benchmarking 服务

Rally 是一个基准测试工具,它会自动执行并统一多节点 OpenStack 部署、云验证、基准测试和分析操作。它可以作为 OpenStack CI/CD 系统的一个基本工具来持续提高它的 SLA、性能和稳定性。这个工具包括以下核心组件:

  • Server Provider - 为不同的虚拟化技术(LXS、Virsh 等)以及云服务商提供了一个统一的交互接口。它会利用 ssh 访问权限通过 L3 网络来提供这样的接口。
  • Deploy Engine - 在实施任何基准测试规程之前,请先使用服务器供应商提供的服务器来部署 OpenStack 发行版。
  • Verification - 对部署的云环境进行一组测试来检查它是否工作正常,收集结果并以用户可读的形式展现
  • Benchmark Engine - 允许您编写参数化基准测试方案,并针对云环境加以运行。
Benchmarking 服务 - 引入新的插件类型:hook
允许作为迭代运行的测试方案,并在 Rally 报告中提供与已执行操作相关的时间戳(及其他信息)。
Benchmarking 服务 - 新方案
为 nova、cinder、magnum、ceilometer、manila 和 newton 添加了基准测试方案。
Benchmarking 服务 - 验证组件代码重构
Rally Verify 用于启动 Tempest。它已经过代码重构,以包含新的模型:验证器类型、验证器和验证结果。
Cells
OpenStack Compute 包含了 Cells 概念,它由 nova-cells 软件包提供,用于划分计算资源。在本发行版本中,Cells v1 已被 Cells v2 取代。Red Hat OpenStack Platform 将 "cell of one" 部署为默认配置,但目前不支持多单元部署。
DNS-as-a-Service (DNSaaS)
DNS-as-a-Service (DNSaaS) 包含一个用于进行域和记录管理的 REST API,支持多租户,并可与 OpenStack Identity 服务 (keystone) 集成以进行认证。DNSaaS 还包含一个用于与 Compute (nova) 和 OpenStack Networking (neutron) 通知进行集成的框架,因而可以自动生成 DNS 记录。此外,DNSaaS 还集成了 Bind9 后端。
Firewall-as-a-Service (FWaaS)
Firewall-as-a-Service 插件为 OpenStack Networking (neutron) 添加了边界防火墙管理功能。FWaaS 使用 iptables 在一个项目的所有虚拟路由上应用防火墙策略,并支持在每个项目中使用一个防火墙策略和逻辑防火墙实例。FWaaS 在网络边界进行操作,对 OpenStack Networking (neutron) 路由器进行过滤。这一点和安全组有所不同,安全组在实例层面进行操作。
Google 云存储备份驱动器 (Block Storage)
Block Storage 服务 (cinder) 现可配置为使用 Google 云存储来存储卷备份。有了这个功能,用户便无需再花费大量费用来维护一个仅用于灾难恢复的备用云。
裸机节点链路聚合

本发行版本引入了裸机节点链路聚合功能。通过链路聚合,您可以在裸机节点 NIC 上配置绑定,以支持故障转移和负载平衡。此功能要求能够从专门的 neutron 插件配置具体的硬件交换机供应商支持。请验证您的硬件供应商交换机支持正确的 neutron 插件。

此外,您可以手动预先配置交换机,为这些裸机节点设置绑定。要使节点从某一个绑定接口引导,交换机需要支持 LACP 和 LACP 回退(如果未形成绑定,则绑定链路回退到各个链路)。否则,节点还需要单独的置备和清理网络。

Red Hat OpenStack Platform for POWER
现在可在 IBM POWER8 little endian 硬件上部署预配备的 overcloud Compute 节点。
Red Hat SSO
本发行版本包括了 keycloak-httpd-client-install 软件包的一个版本。这个软件包包括了一个命令行工具,使用这个工具可以帮助配置 Apache mod_auth_mellon SAML Service Provider 作为 Keycloak SAML IdP 的一个客户端。

第 3 章 发行信息

本发行注记重点介绍了部署 Red Hat OpenStack Platform 时需要考虑的信息,如技术预览项、推荐方案、已知问题、过时的功能等。

在本 Red Hat OpenStack Platform 发行版本的产品支持周期内,每个更新版本的备注都会包括在相应的公告中。

3.1. Red Hat OpenStack Platform 13 GA

本发行注记重点介绍了部署 Red Hat OpenStack Platform 时需要考虑的信息,如技术预览项、推荐方案、已知问题、过时的功能等。

3.1.1. 增强

本 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

3.1.2. 技术预览

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

BZ#1488095

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

3.1.3. 发行注记

本节概述了本发行版本的重要详细信息,包括推荐方案和 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

3.1.4. 已知问题

当前,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

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

第 4 章 技术备注

本章的内容是对 Red Hat OpenStack Platform“Queens”勘误公告内容的补充,该公告通过 Content Delivery Network 发布。

4.1. RHEA-2018:2086 — Red Hat OpenStack Platform 13.0 功能增强公告

本节中所包括的错误已在 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。