4.2. RHEA-2015:1549 — Red Hat Enterprise Linux OpenStack Platform director 发行版本

diskimage-builder 中缺少了 PyYAML 的一个依赖程序，这会导致构建镜像失败。在这个版本中，增加了缺少的依赖程序，现在镜像可以被成功构建。

diskimage-builder 中缺少了 PyYAML 的一个依赖程序，这会导致构建镜像失败。在这个版本中，增加了缺少的依赖程序，现在镜像可以被成功构建。

在实施过程中不再使用 deploy-baremetal-overcloudrc 文件。现在，使用 "openstack overcloud deploy" 命令以及相关的命令行参数。

在实施过程中不再使用 deploy-baremetal-overcloudrc 文件。现在，使用 "openstack overcloud deploy" 命令以及相关的命令行参数。

RabbitMQ 配置中的一个重复的行会导致 Undercloud 安装失败。在这个版本中，删除了这个重复的行，Undercloud 可以被成功安装。

RabbitMQ 配置中的一个重复的行会导致 Undercloud 安装失败。在这个版本中，删除了这个重复的行，Undercloud 可以被成功安装。

openstack-ironic-discoverd 服务会在启动时检查是否存在 openstack-ironic-api。因为启动顺序的原因，openstack-ironic-discoverd 会在重启时无法监测到 openstack-ironic-api。在这个版本中，openstack-ironic-discoverd 启动代码中删除了对 openstack-ironic-api 的检查，在重启时，所有服务都可以被成功启动。

openstack-ironic-discoverd 服务会在启动时检查是否存在 openstack-ironic-api。因为启动顺序的原因，openstack-ironic-discoverd 会在重启时无法监测到 openstack-ironic-api。在这个版本中，openstack-ironic-discoverd 启动代码中删除了对 openstack-ironic-api 的检查，在重启时，所有服务都可以被成功启动。

Ironic/Heat systemd 服务文件中的一个小错误导致日志文件重定向错误。在这个版本中，Ironic/Heat service 文件已被修正，日志会被重定向到正确的文件。

Ironic/Heat systemd 服务文件中的一个小错误导致日志文件重定向错误。在这个版本中，Ironic/Heat service 文件已被修正，日志会被重定向到正确的文件。

ironic-discoverd 的 edeploy 插件会收集过度的信息，并存在一个 SQL blob 列中。因为这个列中的数据可能会过多，发现（Discovery）服务会在向 Ironic 保存 edeploy 数据时出现错误。在这个版本中，edeploy 插件会在 Undercloud 中把数据保存在一个 Swift 对象中的，在使用 edeploy 插件时，发现服务不会运行失败。

ironic-discoverd 的 edeploy 插件会收集过度的信息，并存在一个 SQL blob 列中。因为这个列中的数据可能会过多，发现（Discovery）服务会在向 Ironic 保存 edeploy 数据时出现错误。在这个版本中，edeploy 插件会在 Undercloud 中把数据保存在一个 Swift 对象中的，在使用 edeploy 插件时，发现服务不会运行失败。

Hostname 在 Overcloud 节点中被不正确地配置。这意味着，Pacemaker 不能解析集群成员的名称。在这个版本中，缩短了 hostname，这意味着，Nova 和 Neutron 现在不再需要附加无效的域名。

Hostname 在 Overcloud 节点中被不正确地配置。这意味着，Pacemaker 不能解析集群成员的名称。在这个版本中，缩短了 hostname，这意味着，Nova 和 Neutron 现在不再需要附加无效的域名。

在这个发行版本中，增加了可以为独立的网络分配特定 IP 地址范围的功能.

现在，可以通过在 Overcloud Orchestration 模板中设置以下参数来指定 IP 地址分配：

* InternalApiAllocationPools
* StorageAllocationPools
* StorageMgmtAllocationPools
* TenantAllocationPools
* ExternalAllocationPools

在这个发行版本中，增加了可以为独立的网络分配特定 IP 地址范围的功能.

现在，可以通过在 Overcloud Orchestration 模板中设置以下参数来指定 IP 地址分配：

* InternalApiAllocationPools
* StorageAllocationPools
* StorageMgmtAllocationPools
* TenantAllocationPools
* ExternalAllocationPools

在这个发行版本中，您可以配置 Compute VNC 代理网络。通过这个功能，您可以分离不同的网络，并可以指定哪个服务需要在哪里运行。

现在，通过设置 Overcloud Orchestration 模板中的 ServiceNetMap -> NovaVncProxyNetwork 参数，可以指定哪个网络可以作为 Compute VNC 代理使用。

在这个发行版本中，您可以配置 Compute VNC 代理网络。通过这个功能，您可以分离不同的网络，并可以指定哪个服务需要在哪里运行。

现在，通过设置 Overcloud Orchestration 模板中的 ServiceNetMap -> NovaVncProxyNetwork 参数，可以指定哪个网络可以作为 Compute VNC 代理使用。

在这个发行版本中，Heat 模板增加了 VLAN 标识符和 OVS 绑定选项，这可以减少重复的配置。Heat 模板现在包括了以下参数：BondInterfaceOvsOptions、StorageNetworkVlanID、StorageMgmtNetworkVlanID、InternalApiNetworkVlanID、TenantNetworkVlanID 和 ExternalNetworkVlanID。

在这个发行版本中，Heat 模板增加了 VLAN 标识符和 OVS 绑定选项，这可以减少重复的配置。Heat 模板现在包括了以下参数：BondInterfaceOvsOptions、StorageNetworkVlanID、StorageMgmtNetworkVlanID、InternalApiNetworkVlanID、TenantNetworkVlanID 和 ExternalNetworkVlanID。

在过去的版本中，HAProxy 无法正确配置 Horizon listener，这会导致在公共 VIP 中 Horizon 无效。在这个版本中，启用了 HAProxy Horizon listener，Horizon dashboard 现在在公共 VIP 中有效。

在过去的版本中，HAProxy 无法正确配置 Horizon listener，这会导致在公共 VIP 中 Horizon 无效。在这个版本中，启用了 HAProxy Horizon listener，Horizon dashboard 现在在公共 VIP 中有效。

Ceilometer 的 backend_url 使用了一个不正确的 redis VIP。在这个版本中，Ceilometer backend_url 被设置为由 Heat 提供的服务，并不会在实施过程中构建。现在， Ceilometer 使用正确 的 IP 地址。

Ceilometer 的 backend_url 使用了一个不正确的 redis VIP。在这个版本中，Ceilometer backend_url 被设置为由 Heat 提供的服务，并不会在实施过程中构建。现在， Ceilometer 使用正确 的 IP 地址。

因为 socket 绑定冲突，novncproxy 会启动失败。这意味着 novncproxy 服务无效。在这个版本中，novncproxy 服务只被绑定到控制器的 internal_api 地址。novncproxy 现在可以成功启动。

因为 socket 绑定冲突，novncproxy 会启动失败。这意味着 novncproxy 服务无效。在这个版本中，novncproxy 服务只被绑定到控制器的 internal_api 地址。novncproxy 现在可以成功启动。

以前，当 neutron-server 首先运行时，一个竞争情况会在 neutron 数据库初始化过程中出现。当两个控制器在同时启用 neutron-server 时，启动 neutron-server 和代理的操作会在输掉竞争的控制器节点上失败，因此 Neutron 服务会在相应的控制器节点上无效。相关日志的内容和以下相似：

    DBDuplicateEntry: (IntegrityError) (1062, "Duplicate entry 'datacentre-1' for key 'PRIMARY'") 'INSERT INTO ml2_vlan_allocations (physical_network, vlan_id, allocated) VALUES (%s, %s, %s)' (('datacentre', 1, 0),

在这个版本中，Neutron 服务器会在一个节点上短暂启动后马上暂停，主 pacemaker 在允许其它 puppet 或 pacemaker 配置发生前，会先让初始的数据库配置发生。这样做的结果就是，Neutron 服务可以在所有控制器节点上启动，而不会出现任何错误。

以前，当 neutron-server 首先运行时，一个竞争情况会在 neutron 数据库初始化过程中出现。当两个控制器在同时启用 neutron-server 时，启动 neutron-server 和代理的操作会在输掉竞争的控制器节点上失败，因此 Neutron 服务会在相应的控制器节点上无效。相关日志的内容和以下相似：

    DBDuplicateEntry: (IntegrityError) (1062, "Duplicate entry 'datacentre-1' for key 'PRIMARY'") 'INSERT INTO ml2_vlan_allocations (physical_network, vlan_id, allocated) VALUES (%s, %s, %s)' (('datacentre', 1, 0),

在这个版本中，Neutron 服务器会在一个节点上短暂启动后马上暂停，主 pacemaker 在允许其它 puppet 或 pacemaker 配置发生前，会先让初始的数据库配置发生。这样做的结果就是，Neutron 服务可以在所有控制器节点上启动，而不会出现任何错误。

以前，mongodb 节点列表只能在一个 Controller 节点上被正确创建，这意味着，其它所有 Controller 节点中的 Ceilometer 的 mongodb 节点列表都为空。在这个版本中，mongodb 节点列表可以在所有 Controller 节点上被正确创建，Ceilometer 具有正确的 mongodb 节点列表。

以前，mongodb 节点列表只能在一个 Controller 节点上被正确创建，这意味着，其它所有 Controller 节点中的 Ceilometer 的 mongodb 节点列表都为空。在这个版本中，mongodb 节点列表可以在所有 Controller 节点上被正确创建，Ceilometer 具有正确的 mongodb 节点列表。

以前，一个不正确的 HAProxy 后端配置会导致 HAProxy 把 glance-registry 服务请求转发给已经下线的节点。在这个版本中，glance-registry 服务的更新过程会被监控，从而确保可以发现已经下线的节点。

以前，一个不正确的 HAProxy 后端配置会导致 HAProxy 把 glance-registry 服务请求转发给已经下线的节点。在这个版本中，glance-registry 服务的更新过程会被监控，从而确保可以发现已经下线的节点。

以前，Galera 的 HAProxy listener 会和 ctlplane 地址进行绑定。这意味着，在使用带有网络分离的 Overcloud 时，客户端无法访问 Galera 服务。在这个版本中，HAProxy Galera listener 的绑定地址被改为 internal_api 网络中的 VIP。现在，客户端可以访问带有独立网络的 Overclouds 上的 Galera 服务。

以前，Galera 的 HAProxy listener 会和 ctlplane 地址进行绑定。这意味着，在使用带有网络分离的 Overcloud 时，客户端无法访问 Galera 服务。在这个版本中，HAProxy Galera listener 的绑定地址被改为 internal_api 网络中的 VIP。现在，客户端可以访问带有独立网络的 Overclouds 上的 Galera 服务。

HAProxy 过去不会使用 clustercheck 检查 MariaDB 的后端状态。这会导致 HAProxy 转发请求到 MariaDB 节点的操作由 TCP 检查，而没有和 Galera 集群进行同步。在这个版本中会使用 clustercheck 检查 MariaDB 的后端状态。现在，HAProxy 可以正确地把请求转发到 MariaDB 节点。

HAProxy 过去不会使用 clustercheck 检查 MariaDB 的后端状态。这会导致 HAProxy 转发请求到 MariaDB 节点的操作由 TCP 检查，而没有和 Galera 集群进行同步。在这个版本中会使用 clustercheck 检查 MariaDB 的后端状态。现在，HAProxy 可以正确地把请求转发到 MariaDB 节点。

以前，distro-specific hieradata 文件没有应用到 Overcloud 节点。在这个版本中提供了用于在所有 Overcloud 节点上分发的静态 RedHat.yaml。

以前，distro-specific hieradata 文件没有应用到 Overcloud 节点。在这个版本中提供了用于在所有 Overcloud 节点上分发的静态 RedHat.yaml。

以前，mariadb 服务在系统引导时启动，这会导致在重启后，Pacemaker 的 mariadb 资源会失败。在这个版本中，引导时不会自动启动 mariadb 服务。现在，mariadb 完全由 Pacemaker 资源控制。

以前，mariadb 服务在系统引导时启动，这会导致在重启后，Pacemaker 的 mariadb 资源会失败。在这个版本中，引导时不会自动启动 mariadb 服务。现在，mariadb 完全由 Pacemaker 资源控制。

Keystone 服务通过 Pacemaker 启动，并作为 Pacemaker 中的 Ceilometer 资源的一个 systemd 的依赖。这会在启动两个版本的 Keystone 服务间产生冲突，从而导致 Pacemaker Keystone 资源启动失败。在这个版本中添加了一个 Pacemaker 的管制机制，它会暂停 Ceilometer 资源，直到 Keystone 资源已被启动。现在，Keystone 会在启动 Ceilometer 前启动，并且不再通过 systemd 启动。

Keystone 服务通过 Pacemaker 启动，并作为 Pacemaker 中的 Ceilometer 资源的一个 systemd 的依赖。这会在启动两个版本的 Keystone 服务间产生冲突，从而导致 Pacemaker Keystone 资源启动失败。在这个版本中添加了一个 Pacemaker 的管制机制，它会暂停 Ceilometer 资源，直到 Keystone 资源已被启动。现在，Keystone 会在启动 Ceilometer 前启动，并且不再通过 systemd 启动。

因为缺少了一个 ControlPlaneNetwork 参数，带有 director 计划的实施和 Heat 基于模板的实施不完全相同。这会导致在使用网络隔离时，基于计划的 Overcloud 实施会失败。在这个版本中包括了到 ControlPlaneNetwork 参数的路径。现在，Overcloud 部署可以正常工作。

因为缺少了一个 ControlPlaneNetwork 参数，带有 director 计划的实施和 Heat 基于模板的实施不完全相同。这会导致在使用网络隔离时，基于计划的 Overcloud 实施会失败。在这个版本中包括了到 ControlPlaneNetwork 参数的路径。现在，Overcloud 部署可以正常工作。

过去，Heat 服务会在不相关的 redis VIP 重新设定位置时重新启动。在 Pacemaker 中，Heat 资源会重启失败，这是因为它依赖于 Ceilometer 资源，而 Ceilometer 资源会因为集群失败造成无法在重启设定位置的 redis VIP 上重启。在这个版本中，当 Ceilometer 重启时会停止 Heat 服务。

过去，Heat 服务会在不相关的 redis VIP 重新设定位置时重新启动。在 Pacemaker 中，Heat 资源会重启失败，这是因为它依赖于 Ceilometer 资源，而 Ceilometer 资源会因为集群失败造成无法在重启设定位置的 redis VIP 上重启。在这个版本中，当 Ceilometer 重启时会停止 Heat 服务。

以前，在启用了网络隔离的 Overclouds 中，Pacemaker 会把 redis master 设置为 master 无法访问的网络中的一个主机名。这意味着 redis 节点无法加入集群。在这个版本中，当部署启用了网络隔离时，Pacemaker 的主机名会根据 internal_api 地址进行解析。

以前，在启用了网络隔离的 Overclouds 中，Pacemaker 会把 redis master 设置为 master 无法访问的网络中的一个主机名。这意味着 redis 节点无法加入集群。在这个版本中，当部署启用了网络隔离时，Pacemaker 的主机名会根据 internal_api 地址进行解析。

以前，OpenStack 使用在控制器节点上启用的 NeutronScale puppet 资源，并把 neutron 代理的 "host" 项进行重写（"neutron-n-0" 代表控制器 0，"neutron-n-1" 代表控制器 1）。当相关的 neutron-scale 资源由 pacemaker 启动时，这个重写操作会在部署的结束阶段进行。常见于 VM 环境中，neutron 会报告 L3 HA 没有足够的 L3 代理，这和 overcloud 的 neutron agent-list 命令不一致。因此，在一些情况下，Neutron 会产生一个错误信息，声明没有足够的 L3 代理来提供 HA（默认最少需要 2 个 L3 代理）。Overcloud 上的 "neutron agent-list" 命令会显示不一致的代理信息，例如，每个代理都有重复的项，一个是在主机 "overcloud-controller-1.localdomain" 上的原始代理 （通常显示为 "XXX"），另一个是主机 "neutron-n-1" 上的“较新的”代理（最终状态会是 ":-)"）。在其它情况中，如果只有一个控制器，代理重新命名会导致一个 neutron 代理（openvswitch）失败，它下面的其它代理将会无法启动，最终导致没有 L3、元数据或 dhcp 代理。

这个问题已被解决。现在，会确保原生（native）neutron L3 High Availability 被使用，并且为原生 neutron HA 在每个网络上启用足够的 DHCP 代理。以前，在所有情况下都只静态地设置两个 DHCP 代理。现在，在 tripleo heat 模板中添加了一个参数来设置它（默认值是 '3'），并在 oscplugin 中使用它。NeutronScale 资源本身被从 tripleo heat 模板中删除（overcloud 控制器 puppet manifest 保存在这个模板中）。作为结果，在使用这个版本后进行的部署中，控制器节点不会包括 neutron-scale 资源。这可以使用以下命令进行验证：

1. 在控制器节点上运行：
# pcs status | grep -n neutron -A 1

您应该看不到任何 "neutron-scale" 克隆设置或资源定义。

2. 在 undercloud 上运行：
$ source overcloudrc 
$ neutron agent-list

所有的 neutron 代理都应该显示位于一个主机上。这个主机的名字与 "overcloud-controller-0.localdomain" 或 "overcloud-controller-2.localdomain" 类似，而不是 "neutron-n-0" 或 "neutron-n-2"。

以前，OpenStack 使用在控制器节点上启用的 NeutronScale puppet 资源，并把 neutron 代理的 "host" 项进行重写（"neutron-n-0" 代表控制器 0，"neutron-n-1" 代表控制器 1）。当相关的 neutron-scale 资源由 pacemaker 启动时，这个重写操作会在部署的结束阶段进行。常见于 VM 环境中，neutron 会报告 L3 HA 没有足够的 L3 代理，这和 overcloud 的 neutron agent-list 命令不一致。因此，在一些情况下，Neutron 会产生一个错误信息，声明没有足够的 L3 代理来提供 HA（默认最少需要 2 个 L3 代理）。Overcloud 上的 "neutron agent-list" 命令会显示不一致的代理信息，例如，每个代理都有重复的项，一个是在主机 "overcloud-controller-1.localdomain" 上的原始代理 （通常显示为 "XXX"），另一个是主机 "neutron-n-1" 上的“较新的”代理（最终状态会是 ":-)"）。在其它情况中，如果只有一个控制器，代理重新命名会导致一个 neutron 代理（openvswitch）失败，它下面的其它代理将会无法启动，最终导致没有 L3、元数据或 dhcp 代理。

这个问题已被解决。现在，会确保原生（native）neutron L3 High Availability 被使用，并且为原生 neutron HA 在每个网络上启用足够的 DHCP 代理。以前，在所有情况下都只静态地设置两个 DHCP 代理。现在，在 tripleo heat 模板中添加了一个参数来设置它（默认值是 '3'），并在 oscplugin 中使用它。NeutronScale 资源本身被从 tripleo heat 模板中删除（overcloud 控制器 puppet manifest 保存在这个模板中）。作为结果，在使用这个版本后进行的部署中，控制器节点不会包括 neutron-scale 资源。这可以使用以下命令进行验证：

1. 在控制器节点上运行：
# pcs status | grep -n neutron -A 1

您应该看不到任何 "neutron-scale" 克隆设置或资源定义。

2. 在 undercloud 上运行：
$ source overcloudrc 
$ neutron agent-list

所有的 neutron 代理都应该显示位于一个主机上。这个主机的名字与 "overcloud-controller-0.localdomain" 或 "overcloud-controller-2.localdomain" 类似，而不是 "neutron-n-0" 或 "neutron-n-2"。

过去，因为控制器节点不共享 consoleauth 令牌，所以会导致进行验证请求时失败。在这个版本中，memcached 可以共享 consoleauth 令牌，验证请求可以成功进行。

过去，因为控制器节点不共享 consoleauth 令牌，所以会导致进行验证请求时失败。在这个版本中，memcached 可以共享 consoleauth 令牌，验证请求可以成功进行。

在这个发行版本中，可以设置 neutron_tunnel_id_ranges 和 neutron_vni_ranges 参数来分别管理 GRE 和 VXLAN 的通道 ID。通过 overcloud Neutron，它们可以应用到 overcloud 租户网络。例如：

# openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 1  --neutron-tunnel-id-ranges "1:1111,2:2222" --neutron-vni-ranges "3:33,5:55,100:999" --neutron-tunnel-types "gre,vxlan"

如果没有指定，tunnel_id_ranges 和 neutron_vni_ranges 的默认值都会是 "1:1000"，这可能不适用于特定的部署环境。

如果使用了以上示例中的设置，您可以在部署完成后，在控制器节点上的相关 neutron 配置文件中进行检查和验证，例如：

# grep -rni 'vni_ranges\|id_ranges\|tunnel_types' /etc/neutron/*
/etc/neutron/plugin.ini:78:tunnel_id_ranges =1:1111,2:2222
/etc/neutron/plugin.ini:85:vni_ranges =3:33,5:55,100:999
/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:77:tunnel_types =gre,vxlan
/etc/neutron/plugins/ml2/ml2_conf.ini:78:tunnel_id_ranges =1:1111,2:2222
/etc/neutron/plugins/ml2/ml2_conf.ini:85:vni_ranges =3:33,5:55,100:999

您也可以在部署完成后，通过创建一个 overcloud 网络进行测试，例如：

# source overcloudrc # from the undercloud box for example
# neutron net-create --provider:network_type "vxlan" "foo"

这会创建一个类型为 vxlan 的网络。您可以检查它是否从指定的 vni_ranges 中接收到一个分段 ID：

# neutron net-show foo
| provider:network_type     | vxlan
| provider:segmentation_id  | 3

同样，您也可以检查 GRE 网络是否被分配了适当的分段 ID。

在这个发行版本中，可以设置 neutron_tunnel_id_ranges 和 neutron_vni_ranges 参数来分别管理 GRE 和 VXLAN 的通道 ID。通过 overcloud Neutron，它们可以应用到 overcloud 租户网络。例如：

# openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 1  --neutron-tunnel-id-ranges "1:1111,2:2222" --neutron-vni-ranges "3:33,5:55,100:999" --neutron-tunnel-types "gre,vxlan"

如果没有指定，tunnel_id_ranges 和 neutron_vni_ranges 的默认值都会是 "1:1000"，这可能不适用于特定的部署环境。

如果使用了以上示例中的设置，您可以在部署完成后，在控制器节点上的相关 neutron 配置文件中进行检查和验证，例如：

# grep -rni 'vni_ranges\|id_ranges\|tunnel_types' /etc/neutron/*
/etc/neutron/plugin.ini:78:tunnel_id_ranges =1:1111,2:2222
/etc/neutron/plugin.ini:85:vni_ranges =3:33,5:55,100:999
/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:77:tunnel_types =gre,vxlan
/etc/neutron/plugins/ml2/ml2_conf.ini:78:tunnel_id_ranges =1:1111,2:2222
/etc/neutron/plugins/ml2/ml2_conf.ini:85:vni_ranges =3:33,5:55,100:999

您也可以在部署完成后，通过创建一个 overcloud 网络进行测试，例如：

# source overcloudrc # from the undercloud box for example
# neutron net-create --provider:network_type "vxlan" "foo"

这会创建一个类型为 vxlan 的网络。您可以检查它是否从指定的 vni_ranges 中接收到一个分段 ID：

# neutron net-show foo
| provider:network_type     | vxlan
| provider:segmentation_id  | 3

同样，您也可以检查 GRE 网络是否被分配了适当的分段 ID。

以前，在没有协调的情况下创建 overcloud Keystone admin 租户会在一个有多个控制器的部署中出现问题。Heat 堆栈的创建会在 ControllerNodesPostDeployment 资源上失败，Keystone 会返回一个 409 ERROR: openstack Conflict occurred attempting to store project - Duplicate Entry (HTTP 409)。Puppet 的运行会在此时失败。在这个版本中，admin 租户会首先在 pacemaker master 节点上创建，因此，带有多个控制器的部署可以正确地创建 overcloud keystone admin 用户。在部署完成后，您可以通过使用 admin 用户访问任何 overcloud 服务来进行验证：

# on the undercloud system, for example:
$ source overcloudrc 
$ keystone user-list

以前，在没有协调的情况下创建 overcloud Keystone admin 租户会在一个有多个控制器的部署中出现问题。Heat 堆栈的创建会在 ControllerNodesPostDeployment 资源上失败，Keystone 会返回一个 409 ERROR: openstack Conflict occurred attempting to store project - Duplicate Entry (HTTP 409)。Puppet 的运行会在此时失败。在这个版本中，admin 租户会首先在 pacemaker master 节点上创建，因此，带有多个控制器的部署可以正确地创建 overcloud keystone admin 用户。在部署完成后，您可以通过使用 admin 用户访问任何 overcloud 服务来进行验证：

# on the undercloud system, for example:
$ source overcloudrc 
$ keystone user-list

在部署一个 Overcloud 时，Tuskar 会修改 Heat 套件（Heat stack）的顶级参数的名称。这会在 Heat 对套件进行验证时出现一个错误：

ERROR: The Parameter (NeutronExternalNetworkBridge) was not defined in template.

这个问题的一个临时解决办法是，使用 "tuskar plan-update" 修改参数；或在环境文件中使用修改过的参数名：

parameters:
  Controller-1::NeutronExternalNetworkBridge: "''"

Overcloud 部署会使用正确的参数值。

请注意：参数需要在 "parameters:" 项而不是 "parameter_defaults:" 项中定义。否则，Tuskar 的导出环境 environment.yaml 中设置的值会覆盖这个值。

在部署一个 Overcloud 时，Tuskar 会修改 Heat 套件（Heat stack）的顶级参数的名称。这会在 Heat 对套件进行验证时出现一个错误：

ERROR: The Parameter (NeutronExternalNetworkBridge) was not defined in template.

这个问题的一个临时解决办法是，使用 "tuskar plan-update" 修改参数；或在环境文件中使用修改过的参数名：

parameters:
  Controller-1::NeutronExternalNetworkBridge: "''"

Overcloud 部署会使用正确的参数值。

请注意：参数需要在 "parameters:" 项而不是 "parameter_defaults:" 项中定义。否则，Tuskar 的导出环境 environment.yaml 中设置的值会覆盖这个值。

以前，无论 Cinder publicurl 端点（endpoint）是否可以被连接，Compute 节点都会查询 Keystone。这意味着，专用的 Compute 节点无法和 Cinder API 进行通讯。在这个版本中，publicurl 端点被改为了 Compute 端口可以访问的 internalurl 端点。

以前，无论 Cinder publicurl 端点（endpoint）是否可以被连接，Compute 节点都会查询 Keystone。这意味着，专用的 Compute 节点无法和 Cinder API 进行通讯。在这个版本中，publicurl 端点被改为了 Compute 端口可以访问的 internalurl 端点。

以前，无论  Nova 和 Swift publicurl 端点（endpoint）是否可以被连接，Compute 节点都会查询 Keystone。这意味着，专用的 Cinder Storage  节点无法与 Nova 和 Swift API 进行通讯。在这个版本中，publicurl 端点被改为 internalurl 端点，现在，Cinder Storage 节点可以和 Nova 和 Swift API 进行通讯。

以前，无论  Nova 和 Swift publicurl 端点（endpoint）是否可以被连接，Compute 节点都会查询 Keystone。这意味着，专用的 Cinder Storage  节点无法与 Nova 和 Swift API 进行通讯。在这个版本中，publicurl 端点被改为 internalurl 端点，现在，Cinder Storage 节点可以和 Nova 和 Swift API 进行通讯。

在以前的版本中，allow_overlapping_ips Neutron 被设置为默认的值，Neutron 中的 allow_overlapping_ips 被禁用，这会无法在相同的范围内定义多个网络。在这个版本中，allow_overlapping_ips 被设置为 "true"，这将允许定义相互间有覆盖范围的多个网络。

在以前的版本中，allow_overlapping_ips Neutron 被设置为默认的值，Neutron 中的 allow_overlapping_ips 被禁用，这会无法在相同的范围内定义多个网络。在这个版本中，allow_overlapping_ips 被设置为 "true"，这将允许定义相互间有覆盖范围的多个网络。

以前，默认的 Ceph scale 被设置为 1。这意味着，即使用户不希望创建 Ceph 节点，一个 Ceph 节点也会被创建。

在这个版本中，默认的 Ceph scale 设置是 0，Ceph 不再会被默认部署。

以前，默认的 Ceph scale 被设置为 1。这意味着，即使用户不希望创建 Ceph 节点，一个 Ceph 节点也会被创建。

在这个版本中，默认的 Ceph scale 设置是 0，Ceph 不再会被默认部署。

以前，os-apply-config 命令创建的 /etc/puppet/hieradata 没有设置访问权限。这个目录中的文件包括了密码和令牌信息，从而可能造成对 OpenStack 安装的非授权访问。在这个版本中，/etc/puppet/hieradata 的所有者被设置为 root，它的权限是 0700。现在，只有 root 用户可以访问 /etc/puppet/hieradata，这增加了系统的安全性。

以前，os-apply-config 命令创建的 /etc/puppet/hieradata 没有设置访问权限。这个目录中的文件包括了密码和令牌信息，从而可能造成对 OpenStack 安装的非授权访问。在这个版本中，/etc/puppet/hieradata 的所有者被设置为 root，它的权限是 0700。现在，只有 root 用户可以访问 /etc/puppet/hieradata，这增加了系统的安全性。

Overcloud 节点会包括不正确的同步系统时间，这会在 HA Controller 集群中产生一些错误。一个临时解决办法是，在运行 "openstack overcloud deploy" 命令时使用 --ntp-server 命令行参数。这个参数会在每个 Overcloud 节点的 /etc/ntp.conf 文件中配置 ntp 服务器，从而保证了正确的同步系统时间，并使 Overcloud 可以被成功部署。

Overcloud 节点会包括不正确的同步系统时间，这会在 HA Controller 集群中产生一些错误。一个临时解决办法是，在运行 "openstack overcloud deploy" 命令时使用 --ntp-server 命令行参数。这个参数会在每个 Overcloud 节点的 /etc/ntp.conf 文件中配置 ntp 服务器，从而保证了正确的同步系统时间，并使 Overcloud 可以被成功部署。

以前，迁移到一个 puppet 部署意味着 boot-stack tripleo-image-element 不再创建初始的 Tuskar 数据库。因此，在成功安装 undercloud 后，Tuskar 服务并没有被正确配置。在这个版本中，undercloud 会正确安装并配置 Tuskar。现在，当成功安装完 undercloud 后，您可以正常使用 Tuskar 服务。

以前，迁移到一个 puppet 部署意味着 boot-stack tripleo-image-element 不再创建初始的 Tuskar 数据库。因此，在成功安装 undercloud 后，Tuskar 服务并没有被正确配置。在这个版本中，undercloud 会正确安装并配置 Tuskar。现在，当成功安装完 undercloud 后，您可以正常使用 Tuskar 服务。

以前，tuskar 服务的配置参数 auth_strategy 被默认设置为 "noauth"。这会导致对 tuskar 管理集合和角色（包括模板，以及密码等敏感参数设置）的不受限制的访问。在这个版本中，默认的设置是进行 keystone 验证。现在，到 tuskar 服务的、没有被验证的 http 请求将返回 HTTP 401 Unauthorized 错误。在 Undercloud 上使用以下命令进行验证：

$ curl -v localhost:8585/v2/plans

以前，tuskar 服务的配置参数 auth_strategy 被默认设置为 "noauth"。这会导致对 tuskar 管理集合和角色（包括模板，以及密码等敏感参数设置）的不受限制的访问。在这个版本中，默认的设置是进行 keystone 验证。现在，到 tuskar 服务的、没有被验证的 http 请求将返回 HTTP 401 Unauthorized 错误。在 Undercloud 上使用以下命令进行验证：

$ curl -v localhost:8585/v2/plans

以前，执行批量操作的代码并不检查一个节点是否已被选择。操作会假设节点列表不为空。当 DEBUG 被禁用时，代码会产生一个未捕获的异常（uncaught exception），并产生一个 "Something went wrong" 信息。

在这个版本中，代码会检查是否最少有一个节点被选项，在没有选择任何节点时，会显示一个详细的错误信息。现在，当执行批量操作时如果没有选择节点，一个信息会要求您需要首先选择一些节点。

以前，执行批量操作的代码并不检查一个节点是否已被选择。操作会假设节点列表不为空。当 DEBUG 被禁用时，代码会产生一个未捕获的异常（uncaught exception），并产生一个 "Something went wrong" 信息。

在这个版本中，代码会检查是否最少有一个节点被选项，在没有选择任何节点时，会显示一个详细的错误信息。现在，当执行批量操作时如果没有选择节点，一个信息会要求您需要首先选择一些节点。

以前，节点详情 URL 名称的指定不正确。在这个版本中，节点详情 URL 的名称已被修正。现在，节点详情链接可以被正确处理，用户可以正确地访问节点详情页。

以前，节点详情 URL 名称的指定不正确。在这个版本中，节点详情 URL 的名称已被修正。现在，节点详情链接可以被正确处理，用户可以正确地访问节点详情页。

以前，在 Undercloud 的过程中，角色不能被添加到计划中。因此，不能使用 OpenStack Dashboard 对角色进行编辑。

在这个版本中，角色会在 Undercloud 的安装过程中被添加到计划中。因此，现在可以通过 Dashboard 编辑角色。

以前，在 Undercloud 的过程中，角色不能被添加到计划中。因此，不能使用 OpenStack Dashboard 对角色进行编辑。

在这个版本中，角色会在 Undercloud 的安装过程中被添加到计划中。因此，现在可以通过 Dashboard 编辑角色。

以前，因为需要和外部 API 服务（如 keystone、heat、ironic 和 tuskar）进行交流，director 的用户界面会需要大量时间来加载页面。在这个版本中添加了所有外部服务调用的缓存，这减少了实际调用的数量，并减少了页面加载的时间。现在，当访问用户界面时，页面的加载时间会大大缩短。

以前，因为需要和外部 API 服务（如 keystone、heat、ironic 和 tuskar）进行交流，director 的用户界面会需要大量时间来加载页面。在这个版本中添加了所有外部服务调用的缓存，这减少了实际调用的数量，并减少了页面加载的时间。现在，当访问用户界面时，页面的加载时间会大大缩短。

以前，在创建和初始相关端点（endpoint）前，用户接口会尝试连接相应的 Overcloud keystone-api。当用户接口无法找到端点时，Overcloud 就无法从用户接口进行初始化。在这个版本中，当 Overcloud 还没有被初始化时，用户接口可以被正确地识别。以上错误将不会再发生。

以前，在创建和初始相关端点（endpoint）前，用户接口会尝试连接相应的 Overcloud keystone-api。当用户接口无法找到端点时，Overcloud 就无法从用户接口进行初始化。在这个版本中，当 Overcloud 还没有被初始化时，用户接口可以被正确地识别。以上错误将不会再发生。

以前，post-install 验证的功能没有在 CLI 中实现，它只包括在已过时的 OpenStack Deployment (tripleO) 脚本中。因此，python-rdomanager-oscplugin 中没有包括这个命令。

在这个版本中，post-install 验证功能已被实现，'openstack overcloud validate' 命令现在包括在 CLI 中。

以前，post-install 验证的功能没有在 CLI 中实现，它只包括在已过时的 OpenStack Deployment (tripleO) 脚本中。因此，python-rdomanager-oscplugin 中没有包括这个命令。

在这个版本中，post-install 验证功能已被实现，'openstack overcloud validate' 命令现在包括在 CLI 中。

以前，DRAC ready-state 配置没有在 CLI 中实现，它只包括在已过时的 OpenStack Deployment (tripleO) 脚本中。因此，python-rdomanager-oscplugin 中没有包括这个命令。

在这个版本中，DRAC ready-state 功能已被实现，'openstack baremetal configure ready state' 命令现在包括在 CLI 中。

以前，DRAC ready-state 配置没有在 CLI 中实现，它只包括在已过时的 OpenStack Deployment (tripleO) 脚本中。因此，python-rdomanager-oscplugin 中没有包括这个命令。

在这个版本中，DRAC ready-state 功能已被实现，'openstack baremetal configure ready state' 命令现在包括在 CLI 中。

这个发行版本为管理默认 overcloud neutron 租户网络行为提供了 4 个参数：--neutron-network-type、--neutron-tunnel-types、--neutron-disable-tunneling 和 --neutron-network-vlan-ranges。它的默认设置是为 overcloud 租户网络提供 GRE 类型和通道（tunnel）。

如果把 --neutron-network-type 设置为 'vlan'，您将可以通过设置 --neutron-network-vlan-ranges 参数来管理分配给 overcloud Neutron 租户网络的 VLAD ID 的范围（默认值是 "datacenter:1:1000"，其中的 "datacenter" 是 VLAN 要被分配到的 Neutron 物理网络的名称）。如果把网络类型只设置为 'vlan'，--neutron-disable-tunneling 需要被同时指定（参见以下示例）。

如果把 --neutron-network-type 设置为 'gre' 或 'vxlan'（或两个都被设置），则相关的 --neutron-tunnel-types 参数也需要被启用（参见以下示例）。另外，如果把网络类型设置为 'gre' 或 'vxlan'，您还可以通过设置相关的 --neutron-tunnel-id-ranges 和 --neutron-vni-ranges 参数来分别管理 GRE 和 VXLAN 的通道 ID。

示例：
* 为 overcloud 租户网络指定 'vxlan' 类型：
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "vxlan" --neutron-tunnel-types "vxlan"

* 为 overcloud 租户网络指定 'gre' 和 'vxlan' 类型：
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "gre,vxlan" --neutron-tunnel-types "gre,vxlan"

* 为 overcloud 租户网络指定 'vlan' 类型，并同时设置 VLAN 的范围：
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "vlan" --neutron-disable-tunneling --neutron-network-vlan-ranges "datacenter:3:3000"

如果在部署时没有指定这些参数，它们会被设置为以下的默认值。这些默认值可能会不适用于具体的部署环境：

--neutron-network-type # default 'gre'
--neutron-tunnel-types # default 'gre'
--neutron-disable-tunneling # defaults to tunneling being enabled
--neutron-network-vlan-ranges # 'datacenter:1:1000'

在部署完成后，您可以检查控制器节点（contorller node）的 Neutron 配置日志来确定以下是否已被配置：

grep -rni 'tunnel_types\|network_type\|enable_tunneling\|vlan_ranges' /etc/neutron/*
/etc/neutron/plugin.ini:14:tenant_network_types = vlan
/etc/neutron/plugin.ini:72:network_vlan_ranges =datacenter:3:3000
/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:54:enable_tunneling=False
/etc/neutron/plugins/ml2/ml2_conf.ini:14:tenant_network_types = vlan
/etc/neutron/plugins/ml2/ml2_conf.ini:72:network_vlan_ranges =datacenter:3:3000

另外，您可以在 overcloud Neutron 上创建一个网络并检查它。例如，在 undercloud 上：

$ source overcloudrc
$ neutron net-create "default"
$ neutron net-show default
...
| provider:network_type     | vlan                                 |
| provider:physical_network | datacenter                           |
| provider:segmentation_id  | 3                                    |
...

这个发行版本为管理默认 overcloud neutron 租户网络行为提供了 4 个参数：--neutron-network-type、--neutron-tunnel-types、--neutron-disable-tunneling 和 --neutron-network-vlan-ranges。它的默认设置是为 overcloud 租户网络提供 GRE 类型和通道（tunnel）。

如果把 --neutron-network-type 设置为 'vlan'，您将可以通过设置 --neutron-network-vlan-ranges 参数来管理分配给 overcloud Neutron 租户网络的 VLAD ID 的范围（默认值是 "datacenter:1:1000"，其中的 "datacenter" 是 VLAN 要被分配到的 Neutron 物理网络的名称）。如果把网络类型只设置为 'vlan'，--neutron-disable-tunneling 需要被同时指定（参见以下示例）。

如果把 --neutron-network-type 设置为 'gre' 或 'vxlan'（或两个都被设置），则相关的 --neutron-tunnel-types 参数也需要被启用（参见以下示例）。另外，如果把网络类型设置为 'gre' 或 'vxlan'，您还可以通过设置相关的 --neutron-tunnel-id-ranges 和 --neutron-vni-ranges 参数来分别管理 GRE 和 VXLAN 的通道 ID。

示例：
* 为 overcloud 租户网络指定 'vxlan' 类型：
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "vxlan" --neutron-tunnel-types "vxlan"

* 为 overcloud 租户网络指定 'gre' 和 'vxlan' 类型：
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "gre,vxlan" --neutron-tunnel-types "gre,vxlan"

* 为 overcloud 租户网络指定 'vlan' 类型，并同时设置 VLAN 的范围：
openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2  --neutron-network-type "vlan" --neutron-disable-tunneling --neutron-network-vlan-ranges "datacenter:3:3000"

如果在部署时没有指定这些参数，它们会被设置为以下的默认值。这些默认值可能会不适用于具体的部署环境：

--neutron-network-type # default 'gre'
--neutron-tunnel-types # default 'gre'
--neutron-disable-tunneling # defaults to tunneling being enabled
--neutron-network-vlan-ranges # 'datacenter:1:1000'

在部署完成后，您可以检查控制器节点（contorller node）的 Neutron 配置日志来确定以下是否已被配置：

grep -rni 'tunnel_types\|network_type\|enable_tunneling\|vlan_ranges' /etc/neutron/*
/etc/neutron/plugin.ini:14:tenant_network_types = vlan
/etc/neutron/plugin.ini:72:network_vlan_ranges =datacenter:3:3000
/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:54:enable_tunneling=False
/etc/neutron/plugins/ml2/ml2_conf.ini:14:tenant_network_types = vlan
/etc/neutron/plugins/ml2/ml2_conf.ini:72:network_vlan_ranges =datacenter:3:3000

另外，您可以在 overcloud Neutron 上创建一个网络并检查它。例如，在 undercloud 上：

$ source overcloudrc
$ neutron net-create "default"
$ neutron net-show default
...
| provider:network_type     | vlan                                 |
| provider:physical_network | datacenter                           |
| provider:segmentation_id  | 3                                    |
...

过去，Unified CLI 会在 OpenStack overcloud 部署还没有完成时就出现超时，这会导致用户错误地接收到一个部署失败的信息。

在这个版本中，超时的值被增加到一个小时。现在，部署过程应该可以在超时时间内完成。

过去，Unified CLI 会在 OpenStack overcloud 部署还没有完成时就出现超时，这会导致用户错误地接收到一个部署失败的信息。

在这个版本中，超时的值被增加到一个小时。现在，部署过程应该可以在超时时间内完成。

在这个发行版本中，删除了一个重复的、用于扩展部署的命令。现在，可以使用 Tuskar 或部署命令来直接扩展部署。

在这个发行版本中，删除了一个重复的、用于扩展部署的命令。现在，可以使用 Tuskar 或部署命令来直接扩展部署。

在以前的 KVM PXE 代码中有一个错误，它在有多个节点同时使用 PXE 引导时显示失败，从而造成一些节点无法连接到 DHCP。

在这个版本中，睡眠（sleep）值被增加，允许节点处于反省状态（introspection）。现在，DHCP 将不再会是一个问题，只是反省状态时间会稍长。

在以前的 KVM PXE 代码中有一个错误，它在有多个节点同时使用 PXE 引导时显示失败，从而造成一些节点无法连接到 DHCP。

在这个版本中，睡眠（sleep）值被增加，允许节点处于反省状态（introspection）。现在，DHCP 将不再会是一个问题，只是反省状态时间会稍长。

以前，当使用 'openstack overcloud deploy' 命令时，一些命令行参数不会被代码使用，从而使用户无法设置这些参数。

在这个版本中，这些参数会被正确使用，并被发送到 Orchestration 服务。

以前，当使用 'openstack overcloud deploy' 命令时，一些命令行参数不会被代码使用，从而使用户无法设置这些参数。

在这个版本中，这些参数会被正确使用，并被发送到 Orchestration 服务。

过去，OpenStack Overcloud 验证使用上游的文件来运行 OpenStack Integration Test Suite (tempest)，而不是使用 redhat-openstack/tempest 中的中游工具。这造成了输出格式的不同。

在这个版本中，OpenStack Overcloud 验证使用中游工具运行 tempest，输出格式与期望的相同。

过去，OpenStack Overcloud 验证使用上游的文件来运行 OpenStack Integration Test Suite (tempest)，而不是使用 redhat-openstack/tempest 中的中游工具。这造成了输出格式的不同。

在这个版本中，OpenStack Overcloud 验证使用中游工具运行 tempest，输出格式与期望的相同。

以前，CLI 没有提供修改特定 Neutron 参数的方法。在这个版本中，deploy 命令添加了新的选择，用户可以在 "Openstack overcloud deploy" 命令中使用它们来配置这些参数。

以前，CLI 没有提供修改特定 Neutron 参数的方法。在这个版本中，deploy 命令添加了新的选择，用户可以在 "Openstack overcloud deploy" 命令中使用它们来配置这些参数。

以前，Tuskar API 需要所有参数都是一个字符串。但是，当传递的一些参数是整数时，这些参数就无法被 API 接受。

在这个版本中，所有参数在被发送给 API 前，都会被转换为字符串。现在，API 可以介绍所有参数，部署可以正常进行。

以前，Tuskar API 需要所有参数都是一个字符串。但是，当传递的一些参数是整数时，这些参数就无法被 API 接受。

在这个版本中，所有参数在被发送给 API 前，都会被转换为字符串。现在，API 可以介绍所有参数，部署可以正常进行。

过去，在 /usr/share/openstack-tripleo-heat-templates/ 中使用“硬代码”来指定到 Heat 模板集合的路径。这会导致，在使用自定义 Heat 模板（如创建一个本地副本并对它进行定制）时出现问题。在这个版本中，使用一个输入变量（通过  --template 参数指定）来替代它。现在，用户可以创建一个带有自定义 Heat 模板集合的 Overcloud。

过去，在 /usr/share/openstack-tripleo-heat-templates/ 中使用“硬代码”来指定到 Heat 模板集合的路径。这会导致，在使用自定义 Heat 模板（如创建一个本地副本并对它进行定制）时出现问题。在这个版本中，使用一个输入变量（通过  --template 参数指定）来替代它。现在，用户可以创建一个带有自定义 Heat 模板集合的 Overcloud。

以前，在重新实效 OpenStack Overcloud 时，所需的参数不会被正确地传递给 Orchestration 服务，这会产生一个 UPGRADE_FAILED 信息。

在这个版本中，在 Orchestration 更新参数中添加了一个 'Existing=True' 参数。现在，Overcloud 可以被成功部署。

以前，在重新实效 OpenStack Overcloud 时，所需的参数不会被正确地传递给 Orchestration 服务，这会产生一个 UPGRADE_FAILED 信息。

在这个版本中，在 Orchestration 更新参数中添加了一个 'Existing=True' 参数。现在，Overcloud 可以被成功部署。

以前，在部署过程中，虽然 ironic 日志显示有可用的节点，heat 引擎日志会因为没有找到有效的主机而返回一个非零的错误。这是因为，在 "openstack baremetal introspection" 命令完成后，director 没有把节点设置为 "available"。在这个版本中，当 introspection 完成后节点被设置为 "available"。现在，director 在实施 Overcloud 时可以看到节点。

以前，在部署过程中，虽然 ironic 日志显示有可用的节点，heat 引擎日志会因为没有找到有效的主机而返回一个非零的错误。这是因为，在 "openstack baremetal introspection" 命令完成后，director 没有把节点设置为 "available"。在这个版本中，当 introspection 完成后节点被设置为 "available"。现在，director 在实施 Overcloud 时可以看到节点。

除了使用数据库中的计划，现在 director 还可以使用 Heat 模板集合来创建一个 Overcloud。这个功能提供了一个在运行 "openstack overcloud stack update" 命令来更新 Overcloud 中的软件包时直接使用 Heat 模板的方法。如果您使用模板集合而不是计划创建 Overcloud，在运行 "openstack overcloud stack update" 命令时使用 "--templates" 参数替代 "--plan" 参数。

除了使用数据库中的计划，现在 director 还可以使用 Heat 模板集合来创建一个 Overcloud。这个功能提供了一个在运行 "openstack overcloud stack update" 命令来更新 Overcloud 中的软件包时直接使用 Heat 模板的方法。如果您使用模板集合而不是计划创建 Overcloud，在运行 "openstack overcloud stack update" 命令时使用 "--templates" 参数替代 "--plan" 参数。

现在，director 提供了一个参数来在更新 Overcloud 节点上的软件包时接收格外的 Heat 环境文件。Overcloud 分离的网络在创建以及以后的更新过程中需要额外的环境文件，如果没有这些环境文件，用户将无法在带有分离网络的 Overcloud 中使用 "openstack overcloud update stack" 命令。现在，用户可以在 "openstack overcloud update stack" 命令中使用 "-e" 参数来解决这个问题。

现在，director 提供了一个参数来在更新 Overcloud 节点上的软件包时接收格外的 Heat 环境文件。Overcloud 分离的网络在创建以及以后的更新过程中需要额外的环境文件，如果没有这些环境文件，用户将无法在带有分离网络的 Overcloud 中使用 "openstack overcloud update stack" 命令。现在，用户可以在 "openstack overcloud update stack" 命令中使用 "-e" 参数来解决这个问题。

在这个发行版本中，用户可以在删除 overcloud 节点时直接使用 Heat 模板。现在，如果在部署 overcloud 时没有使用 Tuskar，则可以在运行 "openstack overcloud node delete" 命令时使用 "--templates" 参数。

在这个发行版本中，用户可以在删除 overcloud 节点时直接使用 Heat 模板。现在，如果在部署 overcloud 时没有使用 Tuskar，则可以在运行 "openstack overcloud node delete" 命令时使用 "--templates" 参数。

在这个发行版本中增加了一个新功能 - 在从 overcloud 中删除一个节点时可以接受额外的 Heat 环境文件。当在一个分离的网络中进行 overcloud 更新时，额外的环境文件需要被传递给 Heat。现在，"openstack overcloud node delete" 命令可以被用来在一个分离的网络中删除 overcloud 节点。

在这个发行版本中增加了一个新功能 - 在从 overcloud 中删除一个节点时可以接受额外的 Heat 环境文件。当在一个分离的网络中进行 overcloud 更新时，额外的环境文件需要被传递给 Heat。现在，"openstack overcloud node delete" 命令可以被用来在一个分离的网络中删除 overcloud 节点。

以前，在 deploy 命令中存在一些功能相同的重复的参数。在这个版本中，这些重复的参数（--plan-uuid、--use-tripleo-heat-templates、--extra-template）已被删除。

以前，在 deploy 命令中存在一些功能相同的重复的参数。在这个版本中，这些重复的参数（--plan-uuid、--use-tripleo-heat-templates、--extra-template）已被删除。

以前，超时值没有被设置，这意味着在一个小时之后，部署就会出现超时。在这个版本中增加了一个超时参数，可以被用来设置一个自定义的超时值。它的默认值是 4 小时。

以前，超时值没有被设置，这意味着在一个小时之后，部署就会出现超时。在这个版本中增加了一个超时参数，可以被用来设置一个自定义的超时值。它的默认值是 4 小时。

以前，Heat 模板缺少一个特定的参数来配置 Neutron L3 Agent。因此，director 无法正确配置 L3 Agent。在这个版本中，为模板添加了以前缺少的 Heat 参数。
现在，director 可以正确配置 L3 Agent。

以前，Heat 模板缺少一个特定的参数来配置 Neutron L3 Agent。因此，director 无法正确配置 L3 Agent。在这个版本中，为模板添加了以前缺少的 Heat 参数。
现在，director 可以正确配置 L3 Agent。

以前，当实施只有一个控制器时， 'L3HA' 会作为 'True' 传递给 overcloud Neutron 配置。因为 Neutron 需要最少 2 个 L3 代理来实现原生 L3 HA，在实施成功完成后设置 overcloud 租户网络会报告错误。在实施成功完成后创建租户 Neutron 网络或路由时，Neutron 会返回以下错误：

    Not enough l3 agents available to ensure HA. Minimum required 2, available 1.

在这个版本中，这个错误已被解决。当进行带有一个控制器的实施时，控制器节点的 /etc/neutron/neutron.conf 文件中的 'L3HA' 是 'False'；当实施有 2 个控制器节点时，它的值是 'True'。

以前，当实施只有一个控制器时， 'L3HA' 会作为 'True' 传递给 overcloud Neutron 配置。因为 Neutron 需要最少 2 个 L3 代理来实现原生 L3 HA，在实施成功完成后设置 overcloud 租户网络会报告错误。在实施成功完成后创建租户 Neutron 网络或路由时，Neutron 会返回以下错误：

    Not enough l3 agents available to ensure HA. Minimum required 2, available 1.

在这个版本中，这个错误已被解决。当进行带有一个控制器的实施时，控制器节点的 /etc/neutron/neutron.conf 文件中的 'L3HA' 是 'False'；当实施有 2 个控制器节点时，它的值是 'True'。

以前，python-tuskarclient 不支持指定一个 Tuskar API 服务器自定义 CA 证书来验证 SSL 证书。因为服务器使用的证书对于客户是未知的，所有连接会失败。在这个版本中，python-tuskarclient 增加了一个 --os-cacert 选项，使用它可以指定 CA 证书路径，从而可以和 API 服务器进行正常交流。

以前，python-tuskarclient 不支持指定一个 Tuskar API 服务器自定义 CA 证书来验证 SSL 证书。因为服务器使用的证书对于客户是未知的，所有连接会失败。在这个版本中，python-tuskarclient 增加了一个 --os-cacert 选项，使用它可以指定 CA 证书路径，从而可以和 API 服务器进行正常交流。

以前，在 Overcloud 中，/etc/glance/glance-api.conf 文件中的 glance_store 项被设置为 stores=glance.store.filesystem.Store。这会导致因为不同的 store 类型造成镜像上传错误。在这个版本中，glance 配置被改为使用 glance.store.http.Store 作为 store 参数，并包括了 store 类型使用的后端。

以前，在 Overcloud 中，/etc/glance/glance-api.conf 文件中的 glance_store 项被设置为 stores=glance.store.filesystem.Store。这会导致因为不同的 store 类型造成镜像上传错误。在这个版本中，glance 配置被改为使用 glance.store.http.Store 作为 store 参数，并包括了 store 类型使用的后端。

过去，配置文件中的不正确的 DHCP 选项顺序会导致引导失败。在这个版本中，使用 DHCP 选项标签（tag）来提供正确的顺序。现在，机器可以使用 iPXE ROM 进行键条式加载引导，然后调用 HTTP URL 继续引导的过程。这可以保证整个引导过程可以正确进行。

过去，配置文件中的不正确的 DHCP 选项顺序会导致引导失败。在这个版本中，使用 DHCP 选项标签（tag）来提供正确的顺序。现在，机器可以使用 iPXE ROM 进行键条式加载引导，然后调用 HTTP URL 继续引导的过程。这可以保证整个引导过程可以正确进行。

过去，grub 配置会把内核参数设置为把控制台重新定向到一个可能并不存在的串口上。这会导致节点引导失败。在这个版本中，把控制台重新定向到串口的功能在默认情况下被禁用。现在，节点可以被成功引导。

过去，grub 配置会把内核参数设置为把控制台重新定向到一个可能并不存在的串口上。这会导致节点引导失败。在这个版本中，把控制台重新定向到串口的功能在默认情况下被禁用。现在，节点可以被成功引导。

上游的 Nova 会在主机名中默认加上 "novalocal"，这会导致 nova 主机名和 Puppet 所期望的相关主机名不符，从而使在创建 Overcloud 时，Heat 堆栈中的 ControllerNodesPostDeployment 出现 CREATE_FAILED 错误。在这个版本中，上游的默认设备被覆盖，主机名中不再会被自动添加 "novalocal" 后缀。现在，部署后的 Puppet 配置会在 Overcloud Heat 堆栈中报告一个 CREATE_COMPLETE 信息。

上游的 Nova 会在主机名中默认加上 "novalocal"，这会导致 nova 主机名和 Puppet 所期望的相关主机名不符，从而使在创建 Overcloud 时，Heat 堆栈中的 ControllerNodesPostDeployment 出现 CREATE_FAILED 错误。在这个版本中，上游的默认设备被覆盖，主机名中不再会被自动添加 "novalocal" 后缀。现在，部署后的 Puppet 配置会在 Overcloud Heat 堆栈中报告一个 CREATE_COMPLETE 信息。

在 instack.answers 中为 Undercloud 设置 deployment_mode 配置的功能以前是一个技术预览（tech preview），现在这个功能已被删除。deployment_mode 允许选择一个 "scale" 模式来把不同的角色部署到特定节点中。这个功能现在被节点标签（node tagging）功能所替代，它是 Automated Health Check (AHC) 工具的一部分。

在 instack.answers 中为 Undercloud 设置 deployment_mode 配置的功能以前是一个技术预览（tech preview），现在这个功能已被删除。deployment_mode 允许选择一个 "scale" 模式来把不同的角色部署到特定节点中。这个功能现在被节点标签（node tagging）功能所替代，它是 Automated Health Check (AHC) 工具的一部分。

director 提供了一个把不同的网络服务在独立的子网和 VLAN 中进行分离的方法。相关的信息包括在 Red Hat Enterprise Linux OpenStack Platform 7.0 Director 安装和使用指南中。

director 提供了一个把不同的网络服务在独立的子网和 VLAN 中进行分离的方法。相关的信息包括在 Red Hat Enterprise Linux OpenStack Platform 7.0 Director 安装和使用指南中。

DHCP 提供的路由信息和静态路由信息都出现在路由表中，但是 DHCP 路由的 metric 值会是 100。这意味着 metric 值为 0 的静态路由一直会被使用。如果需要使用多个 DHCP 连接，您可以把其中的一个或多个配置为忽略 DHCP 服务器提供的路由信息（使用 "defroute: false" 声明）。

DHCP 提供的路由信息和静态路由信息都出现在路由表中，但是 DHCP 路由的 metric 值会是 100。这意味着 metric 值为 0 的静态路由一直会被使用。如果需要使用多个 DHCP 连接，您可以把其中的一个或多个配置为忽略 DHCP 服务器提供的路由信息（使用 "defroute: false" 声明）。

以前，OpenStack Integration Test Suite (tempest) 没有提供针对于部署的值，从而会导致以下模板测试失败。

在这个版本中，'openstack overcloud validate' 命令中添加了一个 '--deployer-input' 参数，管理员可以使用它提供一个包括针对于部署的值的文件（tempest.conf)。使用 '--deployer-input filename' 参数可以减少测试结果失败的情况。

以前，OpenStack Integration Test Suite (tempest) 没有提供针对于部署的值，从而会导致以下模板测试失败。

在这个版本中，'openstack overcloud validate' 命令中添加了一个 '--deployer-input' 参数，管理员可以使用它提供一个包括针对于部署的值的文件（tempest.conf)。使用 '--deployer-input filename' 参数可以减少测试结果失败的情况。

Redis 需要使用一个独立的 VIP。在部署带有网络隔离的 Redis 时，director 会默认自动把 Redis VIP 放置在 Internal API VIP。操作者无法使用 ServiceNetMap 参数把 Redis 移到其它网络中。

Redis 需要使用一个独立的 VIP。在部署带有网络隔离的 Redis 时，director 会默认自动把 Redis VIP 放置在 Internal API VIP。操作者无法使用 ServiceNetMap 参数把 Redis 移到其它网络中。

以前，director 使用一个带有网络和浮动 IP 选项的文件来进行部署。但是，早期版本的 director 会忽略网络选项。在这个版本中，使用 "openstack overcloud director" 命令的一组命令行参数来替代这个文件。现在，用来配置网络和浮动 IP 地址的选项包括在 CLI 工具中。

以前，director 使用一个带有网络和浮动 IP 选项的文件来进行部署。但是，早期版本的 director 会忽略网络选项。在这个版本中，使用 "openstack overcloud director" 命令的一组命令行参数来替代这个文件。现在，用来配置网络和浮动 IP 地址的选项包括在 CLI 工具中。

以前，'management_plan.uuid' 变量名中的一个错误会造成属性错误，从而可能导致所有 Tuskar 计划的部署失败。在这个版本中，这个变量名已被改正。

以前，'management_plan.uuid' 变量名中的一个错误会造成属性错误，从而可能导致所有 Tuskar 计划的部署失败。在这个版本中，这个变量名已被改正。

以前，当部署一个 Overcloud 时，director 会把 Public VIP 服务放置到 Provisioning 网络的 "ctlplane" 中。这意味着，您无法从 Overcloud 以外访问这些服务。在这个版本更新中，Heat 模板会把 Public VIP 放置到一个 External 网络中。

以前，当部署一个 Overcloud 时，director 会把 Public VIP 服务放置到 Provisioning 网络的 "ctlplane" 中。这意味着，您无法从 Overcloud 以外访问这些服务。在这个版本更新中，Heat 模板会把 Public VIP 放置到一个 External 网络中。

以前，当部署一个 Overcloud 时，director 会把 Public VIP 服务放置到 Provisioning 网络的 "ctlplane" 中。这意味着，您无法从 Overcloud 以外访问 horizon 和 keystone 服务。在这个版本更新中，Heat 模板会把 Public VIP 放置到一个 External 网络中。

以前，当部署一个 Overcloud 时，director 会把 Public VIP 服务放置到 Provisioning 网络的 "ctlplane" 中。这意味着，您无法从 Overcloud 以外访问 horizon 和 keystone 服务。在这个版本更新中，Heat 模板会把 Public VIP 放置到一个 External 网络中。

以前，当 ironic-discoverd 发出一个带有已在节点上配置的、相同的引导设备的 'set_boot_device' 请求时，OpenStack Bare Metal Provisioning (ironic) 中的 DRAC 驱动会试图对 BIOS 进行一个没有任何改变的配置任务，这会导致部署失败。

在这个版本中，如果请求中的目标引导设备和当前的相同，OpenStack Bare Metal Provisioning 中的 DRAC 驱动会忽略这个请求。因此，部署可以成功完成。

以前，当 ironic-discoverd 发出一个带有已在节点上配置的、相同的引导设备的 'set_boot_device' 请求时，OpenStack Bare Metal Provisioning (ironic) 中的 DRAC 驱动会试图对 BIOS 进行一个没有任何改变的配置任务，这会导致部署失败。

在这个版本中，如果请求中的目标引导设备和当前的相同，OpenStack Bare Metal Provisioning 中的 DRAC 驱动会忽略这个请求。因此，部署可以成功完成。

以前，当 Orchestration 部署 Overcloud 时 keystone 令牌会过期，这会导致部署失败（验证错误）。

在这个版本中，令牌超时值已被增加，部署 Overcloud 可以成功完成。

以前，当 Orchestration 部署 Overcloud 时 keystone 令牌会过期，这会导致部署失败（验证错误）。

在这个版本中，令牌超时值已被增加，部署 Overcloud 可以成功完成。

以前，External 网络上没有设置默认的路由。这意味着，您只能从和 Controller 相同的子网中访问 Horizon 和 Public API。在这个版本更新中，Heat 模板包括了 ExternalInterfaceDefaultRoute 参数，这可以确保 External 接口上有一个默认的路由。

以前，External 网络上没有设置默认的路由。这意味着，您只能从和 Controller 相同的子网中访问 Horizon 和 Public API。在这个版本更新中，Heat 模板包括了 ExternalInterfaceDefaultRoute 参数，这可以确保 External 接口上有一个默认的路由。

以前，NeutronScale 资源对 Controller 节点上的 neutron 代理进行了重命名，这会导致与 "neutron agent-list" 命令的结果不一致，Neutron 会报告一个“没有足够 L3 代理来实现 L3 HA”错误。在这个版本中，NeutronScale 资源被从 Overcloud Heat 模板和计划中删除。NeutronScale 不会再出现在 "neutron agent-list" 命令结果中，Neutron 不会报告任何错误。

以前，NeutronScale 资源对 Controller 节点上的 neutron 代理进行了重命名，这会导致与 "neutron agent-list" 命令的结果不一致，Neutron 会报告一个“没有足够 L3 代理来实现 L3 HA”错误。在这个版本中，NeutronScale 资源被从 Overcloud Heat 模板和计划中删除。NeutronScale 不会再出现在 "neutron agent-list" 命令结果中，Neutron 不会报告任何错误。

以前，undercloud 的 admin 用户没有服务租户的 'swiftoperator' 角色。这会导致 CloudForms Management Engine (CFME) 无法访问 swift 对象（因为 CFME 使用 admin 用户）。

在这个版本更新中，undercloud 的 admin 用户被分配了服务租户的 'swiftoperator' 角色。现在，通过在 API 请求中指定服务租户，admin 用户可以访问 swift 对象。

以前，undercloud 的 admin 用户没有服务租户的 'swiftoperator' 角色。这会导致 CloudForms Management Engine (CFME) 无法访问 swift 对象（因为 CFME 使用 admin 用户）。

在这个版本更新中，undercloud 的 admin 用户被分配了服务租户的 'swiftoperator' 角色。现在，通过在 API 请求中指定服务租户，admin 用户可以访问 swift 对象。

以前，NeutronScale 资源对 Controller 节点上的 neutron 代理进行了重命名，这会导致与 "neutron agent-list" 命令的结果不一致，Neutron 会报告一个“没有足够 L3 代理来实现 L3 HA”错误。在这个版本中，NeutronScale 资源被从 Overcloud Heat 模板和计划中删除。NeutronScale 不会再出现在 "neutron agent-list" 命令结果中，Neutron 不会报告任何错误。

以前，NeutronScale 资源对 Controller 节点上的 neutron 代理进行了重命名，这会导致与 "neutron agent-list" 命令的结果不一致，Neutron 会报告一个“没有足够 L3 代理来实现 L3 HA”错误。在这个版本中，NeutronScale 资源被从 Overcloud Heat 模板和计划中删除。NeutronScale 不会再出现在 "neutron agent-list" 命令结果中，Neutron 不会报告任何错误。

在这个发行版本中，为 Block Storage 服务增加了 NFS 后端，从而使它可以提供更多的 Block Storage 后端选择。

现在，Overcloud Block Storage 服务可以被配置为带有以下参数的 NFS 后端：

* CinderEnableNfsBackend
* CinderNfsMountOptions
* CinderNfsServers

在这个发行版本中，为 Block Storage 服务增加了 NFS 后端，从而使它可以提供更多的 Block Storage 后端选择。

现在，Overcloud Block Storage 服务可以被配置为带有以下参数的 NFS 后端：

* CinderEnableNfsBackend
* CinderNfsMountOptions
* CinderNfsServers

以前，glance 后端以“硬代码”的形式设置为使用 swift，这意味着您无法选择使用其它文件系统类型，如 NFS。在这个版本中，增加了 glance 使用 NFS 后端的功能。您可以使用以下参数来把 Overcloud 的 glance 服务配置为使用 NFS 后端：

* GlanceBackend
* GlanceFilePcmkManage
* GlanceFilePcmkDevice
* GlanceFilePcmkOptions

以前，glance 后端以“硬代码”的形式设置为使用 swift，这意味着您无法选择使用其它文件系统类型，如 NFS。在这个版本中，增加了 glance 使用 NFS 后端的功能。您可以使用以下参数来把 Overcloud 的 glance 服务配置为使用 NFS 后端：

* GlanceBackend
* GlanceFilePcmkManage
* GlanceFilePcmkDevice
* GlanceFilePcmkOptions

OpenStack Dashboard（Horizon）现在成为了高可用性架构的一部分。现在，Dashboard 是一个由 Pacemaker 管理的资源。

OpenStack Dashboard（Horizon）现在成为了高可用性架构的一部分。现在，Dashboard 是一个由 Pacemaker 管理的资源。

以前，Pacemaker 和 ironic 会相互争夺对电源管理的控制，这会导致隔离（fencing）功能出现问题。在这个版本中，/etc/ironic/ironic.conf 中默认设置了 force_power_state_during_sync=False。这可以防止在同步的过程中 ironic 自动恢复节点的电源状态。现在，Pacemaker 可以成功地隔离节点。

以前，Pacemaker 和 ironic 会相互争夺对电源管理的控制，这会导致隔离（fencing）功能出现问题。在这个版本中，/etc/ironic/ironic.conf 中默认设置了 force_power_state_during_sync=False。这可以防止在同步的过程中 ironic 自动恢复节点的电源状态。现在，Pacemaker 可以成功地隔离节点。

没有 CLI 参数可以被用来设置 NeutronExternalNetworkBridge，这会在分配浮动 IP 时出现问题。当前设置这个参数的唯一方法是通过网络隔离的自定义环境文件进行。例如：

parameters:
  # Set to "br-ex" if External is on native VLAN
  Controller-1::NeutronExternalNetworkBridge: "''"

parameter_defaults:
  # Set to "br-ex" if External is on native VLAN
  NeutronExternalNetworkBridge: "''"


如果浮动 IP 网络在一个 VLAN 上，把两个参数都设为 ''；如果在一个 br-ex 网桥的 native VLAN 上，则把它们都设置为 'br-ex'。这个配置将使 Neutron 桥接映射在环境中可以正常工作。相关信息包括在 Red Hat Enterprise Linux OpenStack Platform 7 Director 安装和使用指南中。

没有 CLI 参数可以被用来设置 NeutronExternalNetworkBridge，这会在分配浮动 IP 时出现问题。当前设置这个参数的唯一方法是通过网络隔离的自定义环境文件进行。例如：

parameters:
  # Set to "br-ex" if External is on native VLAN
  Controller-1::NeutronExternalNetworkBridge: "''"

parameter_defaults:
  # Set to "br-ex" if External is on native VLAN
  NeutronExternalNetworkBridge: "''"


如果浮动 IP 网络在一个 VLAN 上，把两个参数都设为 ''；如果在一个 br-ex 网桥的 native VLAN 上，则把它们都设置为 'br-ex'。这个配置将使 Neutron 桥接映射在环境中可以正常工作。相关信息包括在 Red Hat Enterprise Linux OpenStack Platform 7 Director 安装和使用指南中。

以前，ipxe-bootimgs 软件包没有包括在默认的 Red Hat Enterprise Linux 仓库（repository）中，它只包括在 Red Hat Enterprise Linux - Optional 仓库中。这意味着，没有 Optional 频道的部署会失败。在这个版本中，这个软件包被加入到 director 频道中。现在，在没有启用 Optional 频道的情况下，部署也可正常工作。

以前，ipxe-bootimgs 软件包没有包括在默认的 Red Hat Enterprise Linux 仓库（repository）中，它只包括在 Red Hat Enterprise Linux - Optional 仓库中。这意味着，没有 Optional 频道的部署会失败。在这个版本中，这个软件包被加入到 director 频道中。现在，在没有启用 Optional 频道的情况下，部署也可正常工作。

以前，NeutronScale 资源对 Controller 节点上的 neutron 代理进行了重命名，这会导致与 "neutron agent-list" 命令的结果不一致，Neutron 会报告一个“没有足够 L3 代理来实现 L3 HA”错误。在这个版本中，NeutronScale 资源被从 Overcloud Heat 模板和计划中删除。NeutronScale 不会再出现在 "neutron agent-list" 命令结果中，Neutron 不会报告任何错误。

以前，NeutronScale 资源对 Controller 节点上的 neutron 代理进行了重命名，这会导致与 "neutron agent-list" 命令的结果不一致，Neutron 会报告一个“没有足够 L3 代理来实现 L3 HA”错误。在这个版本中，NeutronScale 资源被从 Overcloud Heat 模板和计划中删除。NeutronScale 不会再出现在 "neutron agent-list" 命令结果中，Neutron 不会报告任何错误。

以前，Overcloud 对它的 Heat 组件配置不正确，缺少对 heat_stack_user_role、stack_domain_admin 和 stack_domain_admin_password 的设置。在这个版本中，user 和 admin 角色在 /etc/heat/heat.conf 中被正确配置。

以前，Overcloud 对它的 Heat 组件配置不正确，缺少对 heat_stack_user_role、stack_domain_admin 和 stack_domain_admin_password 的设置。在这个版本中，user 和 admin 角色在 /etc/heat/heat.conf 中被正确配置。

以前，部署的 Overclouds 把 Heat CloudFormation API 配置为使用 auth_url 指向 localhost。但是，Keystone 不会监听 localhost，这会导致 Heat CloudFormation API 无法使用。在这个版本中，/etc/heat/heat.conf 中的 auth_url 选项被设置为指向 Keystone 在 Internal API 网络中监听的 IP 地址。Heat CloudFormation API 现在可以正常工作。

以前，部署的 Overclouds 把 Heat CloudFormation API 配置为使用 auth_url 指向 localhost。但是，Keystone 不会监听 localhost，这会导致 Heat CloudFormation API 无法使用。在这个版本中，/etc/heat/heat.conf 中的 auth_url 选项被设置为指向 Keystone 在 Internal API 网络中监听的 IP 地址。Heat CloudFormation API 现在可以正常工作。

以前，Overcloud 为 heat 服务配置了 instance_user=heat-admin。这意味着，到由 heat 部署的虚拟机的 SSH 通讯需要使用 heat-admin 用户。在这个版本中，instance_user 被设置为空。现在，可以使用默认的镜像用户 SSH 到虚拟机。

以前，Overcloud 为 heat 服务配置了 instance_user=heat-admin。这意味着，到由 heat 部署的虚拟机的 SSH 通讯需要使用 heat-admin 用户。在这个版本中，instance_user 被设置为空。现在，可以使用默认的镜像用户 SSH 到虚拟机。

到数据库的连接数量会受到 Controller 的数量，以及每个 Controller 所具有的内核的限制。在一个有 3 个 controller，每个 controller 有多于 12 个内核的 HA 环境中，数据库的连接数量可能会达到 max_connections 的默认值（1024），这可能会出现对服务的请求没有响应的问题。作为一个临时的解决办法，您可以使用以下命令增加 max_connections 的值：

$ openstack management plan set [tuskar_plan_uuid] -P "Controller-1::MysqlMaxConnections=4096"

使用实际的计划 UUID 替换 [tuskar_plan_uuid]，计划的 UUID 可以使用以下命令找到：

$ openstack management plan list

要在部署时使用 --templates 参数来增加 max_connections 的值，为部署命令提供包括以下内容的额外自定义环境文件

parameters:
  MysqlMaxConnections: 4096

把它添加到 deploy 命令中：

$ openstack management deploy --plan overcloud -e /path/to/custom_environment_file.yaml

到数据库的连接数量会受到 Controller 的数量，以及每个 Controller 所具有的内核的限制。在一个有 3 个 controller，每个 controller 有多于 12 个内核的 HA 环境中，数据库的连接数量可能会达到 max_connections 的默认值（1024），这可能会出现对服务的请求没有响应的问题。作为一个临时的解决办法，您可以使用以下命令增加 max_connections 的值：

$ openstack management plan set [tuskar_plan_uuid] -P "Controller-1::MysqlMaxConnections=4096"

使用实际的计划 UUID 替换 [tuskar_plan_uuid]，计划的 UUID 可以使用以下命令找到：

$ openstack management plan list

要在部署时使用 --templates 参数来增加 max_connections 的值，为部署命令提供包括以下内容的额外自定义环境文件

parameters:
  MysqlMaxConnections: 4096

把它添加到 deploy 命令中：

$ openstack management deploy --plan overcloud -e /path/to/custom_environment_file.yaml

过去，不是所有节点都被配置为可以访问所需要的服务器（如 NTP、DNS），这会导致因为没有访问 NTP 服务器，节点间出现不同步的现象。在这个版本中，Undercloud 被设置为非控制器节点（non-Controller node）的网关。这样，非控制器节点就可以访问外部服务（如 DNS 和 NTP），从而避免了节点不同步现象的出现。

过去，不是所有节点都被配置为可以访问所需要的服务器（如 NTP、DNS），这会导致因为没有访问 NTP 服务器，节点间出现不同步的现象。在这个版本中，Undercloud 被设置为非控制器节点（non-Controller node）的网关。这样，非控制器节点就可以访问外部服务（如 DNS 和 NTP），从而避免了节点不同步现象的出现。

以前，SELinux 在 Ceph OSD 节点上被设置为 enforcing 模式。但是，根据 Ceph 的官方文件，SELinux 在 Ceph OSD 节点上应该被设置为 permissive 模式。在这个版本中，Ceph OSD 节点上的 SELinux 被设置为 permissive。

以前，SELinux 在 Ceph OSD 节点上被设置为 enforcing 模式。但是，根据 Ceph 的官方文件，SELinux 在 Ceph OSD 节点上应该被设置为 permissive 模式。在这个版本中，Ceph OSD 节点上的 SELinux 被设置为 permissive。

以前，Pacemaker 服务的启动时间超时值被设置为 20 秒。有些时候，启动时间会超过这个限制，从而导致部署停止。在这个版本中，这个值被增加到 60 秒。现在，Pacemaker 服务可以正确启动，部署可以完成。

以前，Pacemaker 服务的启动时间超时值被设置为 20 秒。有些时候，启动时间会超过这个限制，从而导致部署停止。在这个版本中，这个值被增加到 60 秒。现在，Pacemaker 服务可以正确启动，部署可以完成。