发行注记

在这个版本中，LBaaS dashboard 从 horizon 中移出变为一个独立的插件。
因此，现在可以使用 `yum install neutron-lbaas-ui` 来安装 LBaaS。为了使改变生效，需要重启 httpd。

在这个版本中，LBaaS dashboard 从 horizon 中移出变为一个独立的插件。
因此，现在可以使用 `yum install neutron-lbaas-ui` 来安装 LBaaS。为了使改变生效，需要重启 httpd。

这个版本包括了 keycloak-httpd-client-install 软件包的一个技术预览版本。这个软件包包括了一个命令行工具，使用这个工具可以帮助配置 Apache mod_auth_mellon SAML Service Provider 作为 Keycloak SAML IdP 的一个客户端。

这个版本包括了 keycloak-httpd-client-install 软件包的一个技术预览版本。这个软件包包括了一个命令行工具，使用这个工具可以帮助配置 Apache mod_auth_mellon SAML Service Provider 作为 Keycloak SAML IdP 的一个客户端。

在以前的版本中，`mariadb-galera` 的 RPM 包括了一个产生用来进行 Galera SSL 通讯的 TLS 证书的步骤。但是，如果所安装的 RPM 被容器使用，而且这个容器会被复制，则 TLS 证书本身也会被复制。因此，复制所得的容器会包括和原始容器相同的 TLS 证书，如果使用这个证书，就会产生一个安全条件。 
在这个版本中，RPM 软件包不再产生证书。
这样，容器中就不会包括产生的证书。如果 Galera 的 SSL 配置需要，可以手工产生相关的证书。请注意，Red Hat OpenStack director 当前不会为 SSL 配置 Galera。

在以前的版本中，`mariadb-galera` 的 RPM 包括了一个产生用来进行 Galera SSL 通讯的 TLS 证书的步骤。但是，如果所安装的 RPM 被容器使用，而且这个容器会被复制，则 TLS 证书本身也会被复制。因此，复制所得的容器会包括和原始容器相同的 TLS 证书，如果使用这个证书，就会产生一个安全条件。 
在这个版本中，RPM 软件包不再产生证书。
这样，容器中就不会包括产生的证书。如果 Galera 的 SSL 配置需要，可以手工产生相关的证书。请注意，Red Hat OpenStack director 当前不会为 SSL 配置 Galera。

在这个版本中包括了 OpenDaylight Beryllium SR2 作为技术预览。

在这个版本中包括了 OpenDaylight Beryllium SR2 作为技术预览。

这个版本的软件包包括了 aodh 的更新版本（openstack-aodh-2.0.1-3.el7ost）。
如需了解完整的改变列表，请参阅上游社区的发行注记（http://docs.openstack.org/releasenotes/aodh/mitaka.html#id2）

这个版本的软件包包括了 aodh 的更新版本（openstack-aodh-2.0.1-3.el7ost）。
如需了解完整的改变列表，请参阅上游社区的发行注记（http://docs.openstack.org/releasenotes/aodh/mitaka.html#id2）

这个版本包括了 Aodh API 的一个客户端。这个客户端包括了一个 Python API（位于 "aodhclient" 模块中），以及一个命令行脚本（"aodh"）。Python API 和命令行脚本实现了整个 Aodh API。

这个版本包括了 Aodh API 的一个客户端。这个客户端包括了一个 Python API（位于 "aodhclient" 模块中），以及一个命令行脚本（"aodh"）。Python API 和命令行脚本实现了整个 Aodh API。

这个版本的 aodh 软件包（openstack-aodh-2.0.1-1.el7ost）包括了一个重要的软件修正：

* Bug 1575530 - 修正并改进了 partition coordinator，确保了输入任务可以被正确地分配到 partition members。

这个版本的 aodh 软件包（openstack-aodh-2.0.1-1.el7ost）包括了一个重要的软件修正：

* Bug 1575530 - 修正并改进了 partition coordinator，确保了输入任务可以被正确地分配到 partition members。

在以前的版本中，当创建 `gnocchi_aggregation_by_metrics_threshold` 类型的一个警告（alarm）,evaluator 会产生一个错误并导致一个异常。
在这个版本中，通过总把 `needed_overlap` 应用到 aggregation 操作解决了这个问题。

在以前的版本中，当创建 `gnocchi_aggregation_by_metrics_threshold` 类型的一个警告（alarm）,evaluator 会产生一个错误并导致一个异常。
在这个版本中，通过总把 `needed_overlap` 应用到 aggregation 操作解决了这个问题。

在这个版本以前，composite alarm 在系统每次刷新都会发送通过信息，这就会在日志文件中产生不必要的事件通知信息。
在这个版本中，在每次系统刷新时不再发送重复的通知信息。

在这个版本以前，composite alarm 在系统每次刷新都会发送通过信息，这就会在日志文件中产生不必要的事件通知信息。
在这个版本中，在每次系统刷新时不再发送重复的通知信息。

在以前的版本中，默认情况下 gnocchi-dispatcher 选项不会出现在 `ceilometer.conf` 中。因此，这些选项需要被手工添加。在这个版本中，当安装 ceilometer 时会默认包括 gnocchi-dispatcher 选项。

在以前的版本中，默认情况下 gnocchi-dispatcher 选项不会出现在 `ceilometer.conf` 中。因此，这些选项需要被手工添加。在这个版本中，当安装 ceilometer 时会默认包括 gnocchi-dispatcher 选项。

在以前的版本中，事件不能根据基于时间的项进行过滤。
因此，`le` 和 `ge` 查询无法在基于时间的项中进行。
在这个版本中，增加了新的查询操作，`le` 和 `ge` 查询可以对基于时间的项进行操作。

在以前的版本中，事件不能根据基于时间的项进行过滤。
因此，`le` 和 `ge` 查询无法在基于时间的项中进行。
在这个版本中，增加了新的查询操作，`le` 和 `ge` 查询可以对基于时间的项进行操作。

因为仍然运行 `sqlalchemy-migrate` 代码，Telemetry (ceilometer) dbsync 会创建一个老的警告表（alarming table）。因此，Aodh dbsync 好象没有到 Alembic 的参考，而使 SQLAlchemy 创建所需的表。但是，这些表其实已经存在，所以不会进行任何操作，数据库会被标记为最新版本的 Aodh Alembic。
您可以通过不在 ceilometer dbsync 中创建警告表来避免这个问题的发生。

因为仍然运行 `sqlalchemy-migrate` 代码，Telemetry (ceilometer) dbsync 会创建一个老的警告表（alarming table）。因此，Aodh dbsync 好象没有到 Alembic 的参考，而使 SQLAlchemy 创建所需的表。但是，这些表其实已经存在，所以不会进行任何操作，数据库会被标记为最新版本的 Aodh Alembic。
您可以通过不在 ceilometer dbsync 中创建警告表来避免这个问题的发生。

这个版本包括了对特定 RPM 的邀请，从而确保 Google Cloud 备份驱动所需的 python 程序库存在。

这个版本包括了对特定 RPM 的邀请，从而确保 Google Cloud 备份驱动所需的 python 程序库存在。

以前，python-taskflow 缺少了对一个特定 python-networkx 版本的依赖关系。
因此，`cinder create volume` 可能不会象预期的情况一样工作。
在这个版本中，python-taskflow 软件包包括了正确的依赖关系信息，`cinder create volume` 可以象预期的情况一样工作。

以前，python-taskflow 缺少了对一个特定 python-networkx 版本的依赖关系。
因此，`cinder create volume` 可能不会象预期的情况一样工作。
在这个版本中，python-taskflow 软件包包括了正确的依赖关系信息，`cinder create volume` 可以象预期的情况一样工作。

这个版本的 openstack-gnocchi 软件包增加了更新，它的版本是 openstack-gnocchi-2.1.1-1.el7ost
如需了解更多相关信息，请参阅上游社区的相关信息（https://launchpad.net/gnocchi/+milestone/2.1.1）

这个版本的 openstack-gnocchi 软件包增加了更新，它的版本是 openstack-gnocchi-2.1.1-1.el7ost
如需了解更多相关信息，请参阅上游社区的相关信息（https://launchpad.net/gnocchi/+milestone/2.1.1）

当多个环境文件被指定时，它们会在引擎端而不是客户端进行合并。这就可以为 heat 提供足够信息来正确地编配一个栈。

当多个环境文件被指定时，它们会在引擎端而不是客户端进行合并。这就可以为 heat 提供足够信息来正确地编配一个栈。

通过使用环境中的资源注册表，用户可以设置一个 hook 使它在这些资源中暂停删除操作。这可以使用户在一个资源被删除后有机会执行特定的操作，从而可以在删除一个重要资源时执行额外的验证操作。作为结果，当一个带有 pre-delete hook 的资源要被删除时，Heat 会暂停这个操作，直到资源带有了 {'unset_hook': 'pre-delete'} 信号。

通过使用环境中的资源注册表，用户可以设置一个 hook 使它在这些资源中暂停删除操作。这可以使用户在一个资源被删除后有机会执行特定的操作，从而可以在删除一个重要资源时执行额外的验证操作。作为结果，当一个带有 pre-delete hook 的资源要被删除时，Heat 会暂停这个操作，直到资源带有了 {'unset_hook': 'pre-delete'} 信号。

在以前的版本中，iPXE 驱动有一个条件，它会阻止节点被配置为使用 UEFI 引导模式。因此，iPXE 驱动用户无法把节点配置为 UEFI，从而导致被强制使用 BIOS。
在这个版本中，这个条件已被删除，iPXE 驱动的用户现在可以把节点部署为 UEFI 模式。

在以前的版本中，iPXE 驱动有一个条件，它会阻止节点被配置为使用 UEFI 引导模式。因此，iPXE 驱动用户无法把节点配置为 UEFI，从而导致被强制使用 BIOS。
在这个版本中，这个条件已被删除，iPXE 驱动的用户现在可以把节点部署为 UEFI 模式。

这个改进增加了手工清理的功能，它允许操作者把一个节点从一个可管理的状态直接变为清理状态。
增加这个功能的原因是，操作者可能会因为不同的原因（如构建 RAID、对设备数据进行删除等）需要运行清理的步骤。
现在，操作者可以使用 OpenStack Bare Metal (ironic) API 对 ironic 节点开始清理的过程，并可以选择哪些步骤需要运行。

这个改进增加了手工清理的功能，它允许操作者把一个节点从一个可管理的状态直接变为清理状态。
增加这个功能的原因是，操作者可能会因为不同的原因（如构建 RAID、对设备数据进行删除等）需要运行清理的步骤。
现在，操作者可以使用 OpenStack Bare Metal (ironic) API 对 ironic 节点开始清理的过程，并可以选择哪些步骤需要运行。

这个改进增加了对 iSCSI 驱动的 in-band 清理功能。清理的步骤（如删除磁盘的数据、in-band RAID 配置等）可以在使用这个驱动的节点上进行。
运行清理步骤可以在回收 ironic 中的节点时提供安全性，您可以删除以前租户的数据，运行相关的检查来确定机器的安全性是否被破坏。
现在，pxe_ipmitool、pxe_drac、pxe_iboot、pxe_ilo、pxe_amt、pxe_wol 等驱动可以运行 in-band 清理步骤。

这个改进增加了对 iSCSI 驱动的 in-band 清理功能。清理的步骤（如删除磁盘的数据、in-band RAID 配置等）可以在使用这个驱动的节点上进行。
运行清理步骤可以在回收 ironic 中的节点时提供安全性，您可以删除以前租户的数据，运行相关的检查来确定机器的安全性是否被破坏。
现在，pxe_ipmitool、pxe_drac、pxe_iboot、pxe_ilo、pxe_amt、pxe_wol 等驱动可以运行 in-band 清理步骤。

在以前的版本中，`ipset` 没有被声明为 Open vSwitch (OVS) 和 Linux Bridge neutron 代理的依赖软件包。但是，ipset 是 openstack-neutron 软件包的一个依赖软件包。这就会导致，在安装了 Open vSwitch 或 Linux Bridge 代理的软件包的节点上没有安装 `openstack-neutron`，而 L2 代理却需要 ipset 来配置安全组。
在这个版本中，ipset 是 openstack-openvswitch-agent 依赖的软件包，openstack-linuxbridge-agent 软件包也依赖于 ipset。

在以前的版本中，`ipset` 没有被声明为 Open vSwitch (OVS) 和 Linux Bridge neutron 代理的依赖软件包。但是，ipset 是 openstack-neutron 软件包的一个依赖软件包。这就会导致，在安装了 Open vSwitch 或 Linux Bridge 代理的软件包的节点上没有安装 `openstack-neutron`，而 L2 代理却需要 ipset 来配置安全组。
在这个版本中，ipset 是 openstack-openvswitch-agent 依赖的软件包，openstack-linuxbridge-agent 软件包也依赖于 ipset。

在以前的版本中，openstack-neutron-common 软件包不需要 shadow-utils 软件包，这会导致在安装 openstack-neutron-common 软件包后 'neutron' 用户不会被创建，从而使 neutron 无法在 hypervisor 上执行命令。在这个版本中，openstack-neutron-common 软件包需要 shadow-utils 软件包，'neutron' 用户会被正确创建。

在以前的版本中，openstack-neutron-common 软件包不需要 shadow-utils 软件包，这会导致在安装 openstack-neutron-common 软件包后 'neutron' 用户不会被创建，从而使 neutron 无法在 hypervisor 上执行命令。在这个版本中，openstack-neutron-common 软件包需要 shadow-utils 软件包，'neutron' 用户会被正确创建。

在以前的版本中，在代理启动的过程中如果 br-int 和 br-tun 缺少网桥端口，它会在添加这些端口前检查 patch 端口 `int-br-ex` 和 `phy-br-ex`。但是，用来进行检查的功能是 get_port_ofport()，它会因为 @_ofport_retry 声明来重新进行检查。
这些重新进行的检查会导致重启的过程变得非常慢。
在这个版本中，使用 port_exists() 而不是 get_port_ofport() 来对端口进行检查。因此，在网桥端口缺少 br-int 和 br-tun 时，重启的过程也不会变得缓慢。

在以前的版本中，在代理启动的过程中如果 br-int 和 br-tun 缺少网桥端口，它会在添加这些端口前检查 patch 端口 `int-br-ex` 和 `phy-br-ex`。但是，用来进行检查的功能是 get_port_ofport()，它会因为 @_ofport_retry 声明来重新进行检查。
这些重新进行的检查会导致重启的过程变得非常慢。
在这个版本中，使用 port_exists() 而不是 get_port_ofport() 来对端口进行检查。因此，在网桥端口缺少 br-int 和 br-tun 时，重启的过程也不会变得缓慢。

在这个版本中，openstack-nova 软件包根据上游社区版本 13.1.0 进行了更新。

在这个版本中，openstack-nova 软件包根据上游社区版本 13.1.0 进行了更新。

在以前的版本中，在引导实例时，如果没有指定任何安全组，nova API 会自动添加一个默认的安全组，而这不应该在带有 'port_security_enabled=False' 选项的网络中发生。
因此，当用户在引导一个附加到禁用了组安全的网络的实例时，引导过程会失败。
在这个版本中，nova 不会在为带有 port_security_enabled=False 设置的网络中的实例所创建的端口上添加默认的安全组。
因此，引导过程会正常工作，附加到实例上的端口不会附带默认的安全组。

请注意：一个软件 bug 仍然会显示实例上有一个默认的安全组，但这只会发生在第一次引导实例的时候。

在以前的版本中，在引导实例时，如果没有指定任何安全组，nova API 会自动添加一个默认的安全组，而这不应该在带有 'port_security_enabled=False' 选项的网络中发生。
因此，当用户在引导一个附加到禁用了组安全的网络的实例时，引导过程会失败。
在这个版本中，nova 不会在为带有 port_security_enabled=False 设置的网络中的实例所创建的端口上添加默认的安全组。
因此，引导过程会正常工作，附加到实例上的端口不会附带默认的安全组。

请注意：一个软件 bug 仍然会显示实例上有一个默认的安全组，但这只会发生在第一次引导实例的时候。

在 serial_console 启用的情况下，重复启动和停止一个实例会最终导致 compute 服务没有可用的端口。当这个情况发生时，启动一个实例会出现一个 'SocketPortRangeExhaustedException' 错误，实例无法启动。这是因为 compute 服务会在一个实例启动时创建一个端口，而只会在实例被删除后才释放端口。

在这个版本中，从 libvirt 的角度来看用来销毁 guest（虚拟机）的方法会释放串行接口。这就保证了当一个串行接口不再被实例需要时就会被释放，从而使它可用被再次使用。

在 serial_console 启用的情况下，重复启动和停止一个实例会最终导致 compute 服务没有可用的端口。当这个情况发生时，启动一个实例会出现一个 'SocketPortRangeExhaustedException' 错误，实例无法启动。这是因为 compute 服务会在一个实例启动时创建一个端口，而只会在实例被删除后才释放端口。

在这个版本中，从 libvirt 的角度来看用来销毁 guest（虚拟机）的方法会释放串行接口。这就保证了当一个串行接口不再被实例需要时就会被释放，从而使它可用被再次使用。

在创建快照时，compute API 现在会忽略镜像 API 请求的磁盘格式和容器格式详细信息。这可以确保驱动将会使用正确的快照镜像格式。这可以防止，在镜像被转换为它的基本镜像所使用的格式以外的格式时，出现快照失败（BadRequest）的问题。

在创建快照时，compute API 现在会忽略镜像 API 请求的磁盘格式和容器格式详细信息。这可以确保驱动将会使用正确的快照镜像格式。这可以防止，在镜像被转换为它的基本镜像所使用的格式以外的格式时，出现快照失败（BadRequest）的问题。

在前面的版本中，重新出现了一个以前已被解决的软件错误（BZ#1332599），它会导致在实例硬重启后丢掉它的串口，因此无法通过串口连接到这个实例。这个错误发生在硬重启的过程中，主机的串口会被释放，但域 XML 仍然定义了它们，因此在主机上获得端口的请求在引导的过程中没有被执行。
为了解决这个问题，nova 会在释放端口后从 libvirt 取消定义域。

在前面的版本中，重新出现了一个以前已被解决的软件错误（BZ#1332599），它会导致在实例硬重启后丢掉它的串口，因此无法通过串口连接到这个实例。这个错误发生在硬重启的过程中，主机的串口会被释放，但域 XML 仍然定义了它们，因此在主机上获得端口的请求在引导的过程中没有被执行。
为了解决这个问题，nova 会在释放端口后从 libvirt 取消定义域。

当把一个 SR-IOV VF（Virtual Function）设备分配给一个实例时，它所对应的 PF（Physical Function）会在数据库中标记为不可用。但是，在以前的版本中，当删除实例时，不会在数据库中把相应的 PF 更新为可用。这就导致了在删除了实例后，实例所使用的 PCI 设备不会从数据库中释放。

在这个版本中，nova 会在内存中保存可用 PCI 设备的信息，并定期把它导入到数据库。这就可用帮助数据库维持正确的可用设备信息。

当把一个 SR-IOV VF（Virtual Function）设备分配给一个实例时，它所对应的 PF（Physical Function）会在数据库中标记为不可用。但是，在以前的版本中，当删除实例时，不会在数据库中把相应的 PF 更新为可用。这就导致了在删除了实例后，实例所使用的 PCI 设备不会从数据库中释放。

在这个版本中，nova 会在内存中保存可用 PCI 设备的信息，并定期把它导入到数据库。这就可用帮助数据库维持正确的可用设备信息。

在以前的版本中，openstack-nova-compute 的系统单元文件缺少了对 libvirtd 的依赖关系。因此，当 libvirtd 如果还没有运行，重启 openstack-nova-compute 就会失败。在这个版本中，添加了正确的依赖关系。

在以前的版本中，openstack-nova-compute 的系统单元文件缺少了对 libvirtd 的依赖关系。因此，当 libvirtd 如果还没有运行，重启 openstack-nova-compute 就会失败。在这个版本中，添加了正确的依赖关系。

在这个改进中，疏散（evacuating）带有 CPU 固定的实例会导致这些实例运行于已经运行了其它带有相同固定配置的实例的 hypervisor 上。
进行这个改进的原因是，资源跟踪程序不会跟踪主机上的带有 CPU 固定设置的实例。
现在，一个条件被添加到 NUMATopologyFilter 过滤器中，在实例被疏散时，已经管理了带有相同 CPU 固定配置的主机会通过这个过滤。

在这个改进中，疏散（evacuating）带有 CPU 固定的实例会导致这些实例运行于已经运行了其它带有相同固定配置的实例的 hypervisor 上。
进行这个改进的原因是，资源跟踪程序不会跟踪主机上的带有 CPU 固定设置的实例。
现在，一个条件被添加到 NUMATopologyFilter 过滤器中，在实例被疏散时，已经管理了带有相同 CPU 固定配置的主机会通过这个过滤。

在以前的版本中，当 ceilometer 安装被禁用时，Packstack 会尝试创建一个 gnocchi 数据库。因为创建 gnocchi 数据库的一些参数没有被传递，所以禁用 ceilometer 会导致 Packstack 安装失败。在这个版本中，如果禁用了 ceilometer，Packstack 不会再试图创建 gnocchi 数据库。

在以前的版本中，当 ceilometer 安装被禁用时，Packstack 会尝试创建一个 gnocchi 数据库。因为创建 gnocchi 数据库的一些参数没有被传递，所以禁用 ceilometer 会导致 Packstack 安装失败。在这个版本中，如果禁用了 ceilometer，Packstack 不会再试图创建 gnocchi 数据库。

在以前的版本中，iPXE 会在 HTTP 下载的过程中停止工作，这会导致 Bare Metal Provisioning (ironic) 服务停止工作。

在这个版本中，在出现问题时 iPXE 会重启尝试从网络启动。使用 '--timeout' 选项可用避免无限期的停止。因此，停止工作的问题不会在 HTTP 的下载过程中出现。

在以前的版本中，iPXE 会在 HTTP 下载的过程中停止工作，这会导致 Bare Metal Provisioning (ironic) 服务停止工作。

在这个版本中，在出现问题时 iPXE 会重启尝试从网络启动。使用 '--timeout' 选项可用避免无限期的停止。因此，停止工作的问题不会在 HTTP 的下载过程中出现。

负责配置 VPNaaS 和 LBaaS 的服务供应程序（service provider）会创建永远不会包括在服务启动中的额外文件。这会导致在 LBaaS 被启用的情况下，neutron-server 无法被启动。

在以前的版本中，LBaaS 服务配置供应程序被更新来把服务供应程序直接放人到 /etc/neutron/neutron.conf。更新 VPNaaS 来进行同样的操作会导致它覆盖由 LBaaS 设置的 'service_provider' 值（反之亦然）。为了解决这个问题，这个版本把 'neutron_config' 供应程序从 ini_setting 移到 openstackconfig，并为 neutron::server 添加了一个变量来管理服务供应程序。这样，就可以防止 VPNaaS 和 LBaaS 相互覆盖 service_provider 的值。因此，在启用 LBaaS 的情况下，neutron-server 可以正常启动。

负责配置 VPNaaS 和 LBaaS 的服务供应程序（service provider）会创建永远不会包括在服务启动中的额外文件。这会导致在 LBaaS 被启用的情况下，neutron-server 无法被启动。

在以前的版本中，LBaaS 服务配置供应程序被更新来把服务供应程序直接放人到 /etc/neutron/neutron.conf。更新 VPNaaS 来进行同样的操作会导致它覆盖由 LBaaS 设置的 'service_provider' 值（反之亦然）。为了解决这个问题，这个版本把 'neutron_config' 供应程序从 ini_setting 移到 openstackconfig，并为 neutron::server 添加了一个变量来管理服务供应程序。这样，就可以防止 VPNaaS 和 LBaaS 相互覆盖 service_provider 的值。因此，在启用 LBaaS 的情况下，neutron-server 可以正常启动。

在以前的版本中，当一个密钥的 caps 参数被修改后，Ceph puppet 模块（puppet-ceph）不会更新 CephX 的密钥环（keyring）。因为新的 'metrics' 池的 caps 没有被添加到 CephX 密钥环中，所以会导致 overcloud 升级失败。

在这个版本中，如果 'rbd_keyring' 或 'linvirt_rbd_secret_uuid' 被改变，puppet-ceph 会重新产生 virsh secret，或更新它的密钥。这可以保证当 secrets 或 caps  改变后，CephX 的密钥环也会被更新。

在以前的版本中，当一个密钥的 caps 参数被修改后，Ceph puppet 模块（puppet-ceph）不会更新 CephX 的密钥环（keyring）。因为新的 'metrics' 池的 caps 没有被添加到 CephX 密钥环中，所以会导致 overcloud 升级失败。

在这个版本中，如果 'rbd_keyring' 或 'linvirt_rbd_secret_uuid' 被改变，puppet-ceph 会重新产生 virsh secret，或更新它的密钥。这可以保证当 secrets 或 caps  改变后，CephX 的密钥环也会被更新。

在以前的版本中，因为缺少了 SELinux 策略，在带有  Apache 的 WSGI 中启动 Compute API 会在 audit.log 中产生一个 AVC。

在这个版本中，Compute 可以被绑定到 HTTP 的端口，它在带有 Apache 的 WSGI 中运行不会产生错误。

在以前的版本中，因为缺少了 SELinux 策略，在带有  Apache 的 WSGI 中启动 Compute API 会在 audit.log 中产生一个 AVC。

在这个版本中，Compute 可以被绑定到 HTTP 的端口，它在带有 Apache 的 WSGI 中运行不会产生错误。

在以前的版本中，如果在带有 Apache 的 WSGI 中运行 Block Storage API，而 SELinux 被设置为 'enforce' 模式，则会产生一个 AVC。这是因为 SELinux 会阻止 '/usr/sbin/httpd' 访问 '/var/log/cinder/cinder-api.log' 文件。

在这个版本中，'httpd' 被允许访问 Block Storage API 日志文件。作为结果，在 WSGI 中运行 Block Storage API 不会产生 AVC。

在以前的版本中，如果在带有 Apache 的 WSGI 中运行 Block Storage API，而 SELinux 被设置为 'enforce' 模式，则会产生一个 AVC。这是因为 SELinux 会阻止 '/usr/sbin/httpd' 访问 '/var/log/cinder/cinder-api.log' 文件。

在这个版本中，'httpd' 被允许访问 Block Storage API 日志文件。作为结果，在 WSGI 中运行 Block Storage API 不会产生 AVC。

这个功能改进了副本放置（replica placement）的功能，它可以防止重复分配问题的出现。
增加这个功能的原因是，在传统的 Swift 结构中，意外地为相同设备分配两个分区副本会导致，在没有任何提示的情况下维持时间的减少。
现在，可以防止重复分配问题的出现。但是，这需要设备的数量不少于副本的数量，从而可能会导致一些老的 ring 被错误地认定为无效。因此，还是可能出现域（zone）的数量小于副本数量的情况。

这个功能改进了副本放置（replica placement）的功能，它可以防止重复分配问题的出现。
增加这个功能的原因是，在传统的 Swift 结构中，意外地为相同设备分配两个分区副本会导致，在没有任何提示的情况下维持时间的减少。
现在，可以防止重复分配问题的出现。但是，这需要设备的数量不少于副本的数量，从而可能会导致一些老的 ring 被错误地认定为无效。因此，还是可能出现域（zone）的数量小于副本数量的情况。

这个改进增加了指示容器或账户服务器进行反向项目列出的功能。使用这个功能可以在中间件中分隔带版本的项。
为此，因为安全的原因，内部结构被重新组织。另外，如果需要，反向列出也可以通过客户端应用程序实现。

这个改进增加了指示容器或账户服务器进行反向项目列出的功能。使用这个功能可以在中间件中分隔带版本的项。
为此，因为安全的原因，内部结构被重新组织。另外，如果需要，反向列出也可以通过客户端应用程序实现。

在以前的版本中，类型为 'gnocchi-resource-threshold' 的警告（alarm）信息中的 'project_id' 和 'user_id' 项为空。 

在这个版本中，当产生类型为 'gnocchi-resource-threshold' 的警告信息时会为 'project_id' 和 'user_id' 项产生数据。

在以前的版本中，类型为 'gnocchi-resource-threshold' 的警告（alarm）信息中的 'project_id' 和 'user_id' 项为空。 

在这个版本中，当产生类型为 'gnocchi-resource-threshold' 的警告信息时会为 'project_id' 和 'user_id' 项产生数据。

python-colorama 软件包被添加到 Red Hat OpenStack Platform 9。
这个软件包是 python-gabbi 的依赖软件包，openstack-gnocchi 需要它。
现在，openstack-gnocchi 和 python-gabbi 都可以被正常安装而不会出现依赖软件包错误。

python-colorama 软件包被添加到 Red Hat OpenStack Platform 9。
这个软件包是 python-gabbi 的依赖软件包，openstack-gnocchi 需要它。
现在，openstack-gnocchi 和 python-gabbi 都可以被正常安装而不会出现依赖软件包错误。

Time Series Database-as-a-Service (gnocchi) Ceph 存储驱动依赖于 'python-cradox' 程序库，从而会导致带有 Ceph 后端的 gnocchi 失败。

在这个版本中，'openstack-puppet-modules' 软件包会安装 'python-cradox'。'python-cradox' 是 Ceph librados 库的一个 Python 库，它使用 'cython' 而不是 'ctypes'。现在，运行带有 Ceph 后端的 Time Series Database-as-a-Service 不会出现错误。

Time Series Database-as-a-Service (gnocchi) Ceph 存储驱动依赖于 'python-cradox' 程序库，从而会导致带有 Ceph 后端的 gnocchi 失败。

在这个版本中，'openstack-puppet-modules' 软件包会安装 'python-cradox'。'python-cradox' 是 Ceph librados 库的一个 Python 库，它使用 'cython' 而不是 'ctypes'。现在，运行带有 Ceph 后端的 Time Series Database-as-a-Service 不会出现错误。

在这个版本中，使用 Ceilometer 警告 API 的 API 已被添加到 Horizon。这可以使在以后的开发中使用 API，但当前还没有这个 API 的 GUI 前端。

在这个版本中，使用 Ceilometer 警告 API 的 API 已被添加到 Horizon。这可以使在以后的开发中使用 API，但当前还没有这个 API 的 GUI 前端。

在这个版本中为 Horizon 增加了对 Cinder 卷加密的支持，现在，管理员可以通过 GUI 管理加密的卷类型，卷类型可以通过 Horizon 进行添加、修改和删除。

在这个版本中为 Horizon 增加了对 Cinder 卷加密的支持，现在，管理员可以通过 GUI 管理加密的卷类型，卷类型可以通过 Horizon 进行添加、修改和删除。

在这个版本中，'python-django-horizon' 软件包被升级为版本 9.0.1。

这个新版本的主要特性包括：
* 解决了 "Create Network" 中存在的程序错误。
* 解决了在元数据 widget 中显示元数据的错误。
* 解决了多个与本地化相关的问题。

在这个版本中，'python-django-horizon' 软件包被升级为版本 9.0.1。

这个新版本的主要特性包括：
* 解决了 "Create Network" 中存在的程序错误。
* 解决了在元数据 widget 中显示元数据的错误。
* 解决了多个与本地化相关的问题。

'stack-delete' 命令会在删除请求发出后马上显示 heat 堆栈的信息，而删除一个 heat 堆栈的操作实际是一个异步操作，它所显示的状态可能还没有实际变为 'DELETE_IN_PROGRESS'，这可能会对用户造成混淆。

现在，'stack-delete' 命令不会返回任何信息，这和其它 OpenStack 服务的删除命令一致。

'stack-delete' 命令会在删除请求发出后马上显示 heat 堆栈的信息，而删除一个 heat 堆栈的操作实际是一个异步操作，它所显示的状态可能还没有实际变为 'DELETE_IN_PROGRESS'，这可能会对用户造成混淆。

现在，'stack-delete' 命令不会返回任何信息，这和其它 OpenStack 服务的删除命令一致。

这个版本包括了 oslo.concurrency 3.7.1 中的更新，它增加了对进程的限制来解决 CVE-2015-5162 安全问题。相关信息，请参阅 https://bugs.launchpad.net/ossa/+bug/1449062。

这个版本包括了 oslo.concurrency 3.7.1 中的更新，它增加了对进程的限制来解决 CVE-2015-5162 安全问题。相关信息，请参阅 https://bugs.launchpad.net/ossa/+bug/1449062。

python-wsgi_intercept 软件包被添加到 Red Hat OpenStack Platform 9。
这个软件包是 python-gabbi 的依赖软件包，openstack-gnocchi 需要它。
现在，openstack-gnocchi 和 python-gabbi 都可以被正常安装而不会出现依赖软件包错误。

python-wsgi_intercept 软件包被添加到 Red Hat OpenStack Platform 9。
这个软件包是 python-gabbi 的依赖软件包，openstack-gnocchi 需要它。
现在，openstack-gnocchi 和 python-gabbi 都可以被正常安装而不会出现依赖软件包错误。

以前，在 Undercloud 中，ironic-inspector 没有包括在 Keystone 的端点目录（endpoint catalog）中。这意味着无法通过目录来发现 ironic-inspector 的 API 端点。在这个版本中，ironic-inspector API 端点被添加到 Keystone 目录中，您现在可以通过目录来发现 ironic-inspector API 端点。

以前，在 Undercloud 中，ironic-inspector 没有包括在 Keystone 的端点目录（endpoint catalog）中。这意味着无法通过目录来发现 ironic-inspector 的 API 端点。在这个版本中，ironic-inspector API 端点被添加到 Keystone 目录中，您现在可以通过目录来发现 ironic-inspector API 端点。

在一个较慢的环境中，当 Glance 试图和作为后端的 Swift 进行通讯时会出现超时的问题，这会导致一些 Glance 操作（如上传镜像）失败。现在，Swift 代理服务器的默认 node_timeout value 值被增加到 60 秒。这为在一个较慢的、使用Swift 作为后端的环境中的 Glance 镜像上传增加了稳定性。

在一个较慢的环境中，当 Glance 试图和作为后端的 Swift 进行通讯时会出现超时的问题，这会导致一些 Glance 操作（如上传镜像）失败。现在，Swift 代理服务器的默认 node_timeout value 值被增加到 60 秒。这为在一个较慢的、使用Swift 作为后端的环境中的 Glance 镜像上传增加了稳定性。

ipxe-bootimages RPM 没有包括在 director 的软件仓库中。这会在 director 的安装过程中出现错误。在这个版本中，这个软件包被添加到 director 的软件仓库中，现在它的 RPM 是 director 安装的一部分。

ipxe-bootimages RPM 没有包括在 director 的软件仓库中。这会在 director 的安装过程中出现错误。在这个版本中，这个软件包被添加到 director 的软件仓库中，现在它的 RPM 是 director 安装的一部分。

几乎所有的 Overcloud Pacemaker 资源都依赖于 Keystone 资源。这意味着，在配置改变后重启 Keystone 资源会重启所有依赖它的资源。在这个版本中包括了一个假的 openstack-core，Overcloud Pacemaker 资源（包括 keystone）使用它作为依赖。这意味着，重启 Keystone 资源将不会影响到其它资源。

几乎所有的 Overcloud Pacemaker 资源都依赖于 Keystone 资源。这意味着，在配置改变后重启 Keystone 资源会重启所有依赖它的资源。在这个版本中包括了一个假的 openstack-core，Overcloud Pacemaker 资源（包括 keystone）使用它作为依赖。这意味着，重启 Keystone 资源将不会影响到其它资源。

ManagementNetValueSpecs 参数在 director 的 Heat 模板中使用错误的类型（字符串）。这会导致部署带有 Management 网络的 Overcloud 时出现以下错误：

"Property error: resources.ManagementNetwork.properties.ManagementNetValueSpecs: Value must be a string".

现在，ManagementNetValueSpecs 的数据类型被改为 json，以上错误将不会出现。

ManagementNetValueSpecs 参数在 director 的 Heat 模板中使用错误的类型（字符串）。这会导致部署带有 Management 网络的 Overcloud 时出现以下错误：

"Property error: resources.ManagementNetwork.properties.ManagementNetValueSpecs: Value must be a string".

现在，ManagementNetValueSpecs 的数据类型被改为 json，以上错误将不会出现。

在以前的 Heat 版本中，域资源会在 /etc/heat/heat.conf 被配置前就在 overcloud 中创建。但是，域资源依赖于这个文件的设置，因此这些资源的创建可能不正确，从而导致用户无法创建 heat 堆栈。用户需要手工重启 Pacemaker Heat Engine 资源来解决这个问题。

在这个版本中使用了部署 Heat 服务的正确步骤，因此解决了这个问题。

在以前的 Heat 版本中，域资源会在 /etc/heat/heat.conf 被配置前就在 overcloud 中创建。但是，域资源依赖于这个文件的设置，因此这些资源的创建可能不正确，从而导致用户无法创建 heat 堆栈。用户需要手工重启 Pacemaker Heat Engine 资源来解决这个问题。

在这个版本中使用了部署 Heat 服务的正确步骤，因此解决了这个问题。

老版本的 puppet-ceph-external.yaml Heat 环境文件将不再被支持，9.0 中的模板带有这个文件的新版本。任何对老版本 puppet-ceph-external.yaml 文件进行的定制都需要迁移到新版本。

老版本的 puppet-ceph-external.yaml Heat 环境文件将不再被支持，9.0 中的模板带有这个文件的新版本。任何对老版本 puppet-ceph-external.yaml 文件进行的定制都需要迁移到新版本。

这个补丁程序更新了 dashboard 中 Help URL。现在，这个 URL 指向官方的 Red Hat OpenStack Platform 文档，而不是 OpenStack 上游社区的文档。

这个补丁程序更新了 dashboard 中 Help URL。现在，这个 URL 指向官方的 Red Hat OpenStack Platform 文档，而不是 OpenStack 上游社区的文档。

在 director 的 Heat 模板中，默认的 newtork-isolation.yaml 文件包括与默认的 network-management.yaml 文件相冲突的值。如果在创建 Overcloud 的过程中，在 network-management.yaml 之后包括了 network-isolation.yaml 文件，部署过程会取消激活 Management 网络。在这个更新中重新安排了这些文件以避免这些冲突。现在，无论 network-management.yaml 和 network-isolationl.yaml 文件在部署过程中出现的顺序如何，都不会产生冲突。

在 director 的 Heat 模板中，默认的 newtork-isolation.yaml 文件包括与默认的 network-management.yaml 文件相冲突的值。如果在创建 Overcloud 的过程中，在 network-management.yaml 之后包括了 network-isolation.yaml 文件，部署过程会取消激活 Management 网络。在这个更新中重新安排了这些文件以避免这些冲突。现在，无论 network-management.yaml 和 network-isolationl.yaml 文件在部署过程中出现的顺序如何，都不会产生冲突。

Overcloud 使用一个假的 openstack-core resource 来替代 keystone（现在通过 httpd 访问）。但是，如果使用外部的负载均衡系统时，Overcloud 不会创建 openstack-core。这会因为在创建 Pacemaker 限制（constraint）时需要 openstack-core 而导致 puppet 失败。在这个版本中，可以保证在任何部署配置中都创建 openstack-core 资源，整个部署会成功，所需限制会被创建。

Overcloud 使用一个假的 openstack-core resource 来替代 keystone（现在通过 httpd 访问）。但是，如果使用外部的负载均衡系统时，Overcloud 不会创建 openstack-core。这会因为在创建 Pacemaker 限制（constraint）时需要 openstack-core 而导致 puppet 失败。在这个版本中，可以保证在任何部署配置中都创建 openstack-core 资源，整个部署会成功，所需限制会被创建。

OpenStack Platform 9 的部署需要 "client.openstack" 用户有一个额外的 CephX 密钥。但是，director 的命令行客户端不会为存在的部署创建这个密钥，并使用一个空的 secret 更新 "ceph.openstack" 密钥环。在更新前，需要创建一个新的 CephX 密钥并使用一个环境文件中的 CephClientKey 参数把它传递给部署过程。例如：

  parameter_defaults:
    CephClientKey: 'my_cephx_key'

使用以下命令产生新密钥：

$ ceph-authtool --gen-print-key

OpenStack Platform 9 的部署需要 "client.openstack" 用户有一个额外的 CephX 密钥。但是，director 的命令行客户端不会为存在的部署创建这个密钥，并使用一个空的 secret 更新 "ceph.openstack" 密钥环。在更新前，需要创建一个新的 CephX 密钥并使用一个环境文件中的 CephClientKey 参数把它传递给部署过程。例如：

  parameter_defaults:
    CephClientKey: 'my_cephx_key'

使用以下命令产生新密钥：

$ ceph-authtool --gen-print-key

在一个 RPM 更新时，"os-collect-config" 服务会在 Overcloud 中重启。这会导致 Overcloud 更新失败。在这个版本中对这个行为进行了修改，在进行 RPM 更新时，"os-collect-config" 不会重启。现在，在更新 "os-collect-config" 后 Overcloud 的更新也会成功。请注意，在 "os-refresh-config" 运行时 "os-collect-config" 会正确重启，因此在更新过程中将不再需要重启。

在一个 RPM 更新时，"os-collect-config" 服务会在 Overcloud 中重启。这会导致 Overcloud 更新失败。在这个版本中对这个行为进行了修改，在进行 RPM 更新时，"os-collect-config" 不会重启。现在，在更新 "os-collect-config" 后 Overcloud 的更新也会成功。请注意，在 "os-refresh-config" 运行时 "os-collect-config" 会正确重启，因此在更新过程中将不再需要重启。