第 4 章 技术备注

在这个版本以前，更新配置文件时独立的锁定文件会被使用。另外，命令项在更新时无法被正确同步。
因此，如果在进行处理的过程中出现故障，将可能会导致在以后的配置更新操作中出现死锁问题；或在一些特别的情况下，会出现被破坏（空）的配置文件。
这个版本在 'crudini' 工具程序中添加了更加稳定的锁定和同步机制，从而解决了上面提到的、在系统出现故障时会导致的问题。

在这个版本以前，更新配置文件时独立的锁定文件会被使用。另外，命令项在更新时无法被正确同步。
因此，如果在进行处理的过程中出现故障，将可能会导致在以后的配置更新操作中出现死锁问题；或在一些特别的情况下，会出现被破坏（空）的配置文件。
这个版本在 'crudini' 工具程序中添加了更加稳定的锁定和同步机制，从而解决了上面提到的、在系统出现故障时会导致的问题。

这个 rebase 软件包包括了版本 5.5.42 的一个显著的错误修正：
* 以下错误已被解决：对于一个设置了自动增加的主键（auto-incrementing primary key）的表，当一个正常的 Galera 节点使用 INSERT 命令时，另外一个当前已被移出集群的 Galera 也在使用同一个表中的 INSERT 命令时，会产生一个 "DUPLICATE PRIMARY KEY" 错误。这会导致，在一个 Galera 故障转移正在进行时，OpenStack 应用无法创建新数据库记录的问题。

这个 rebase 软件包包括了版本 5.5.42 的一个显著的错误修正：
* 以下错误已被解决：对于一个设置了自动增加的主键（auto-incrementing primary key）的表，当一个正常的 Galera 节点使用 INSERT 命令时，另外一个当前已被移出集群的 Galera 也在使用同一个表中的 INSERT 命令时，会产生一个 "DUPLICATE PRIMARY KEY" 错误。这会导致，在一个 Galera 故障转移正在进行时，OpenStack 应用无法创建新数据库记录的问题。

在以前的 'alarm-history' 版本中，没有包括提示（alarm）的严重性在什么时间被改变（如从  'low' 变为 'critical'）的信息。它所包括的信息只显示了一个改变已发生，而没有其它任何详细信息。
在这个版本中包括了显示严重性改变详情的代码。
'alarm-history' 现在会在 alarm-history 的输出中包括严重性改变的详细信息。

在以前的 'alarm-history' 版本中，没有包括提示（alarm）的严重性在什么时间被改变（如从  'low' 变为 'critical'）的信息。它所包括的信息只显示了一个改变已发生，而没有其它任何详细信息。
在这个版本中包括了显示严重性改变详情的代码。
'alarm-history' 现在会在 alarm-history 的输出中包括严重性改变的详细信息。

在以前的版本中，当一个 ceilometer 轮询扩展（polling extension）无法被加载时，会在日志中记录一个 ERROR 信息。因为在某些情况下，加载模块失败是所期望的结果（如一个扩展模块是可选的，或它的依赖模块不可用），所以这个错项信息在某些时候会产生误导。现在，这个事件的日志信息级别已改为 WARN，从而表明它不是一个严重的错误。

在以前的版本中，当一个 ceilometer 轮询扩展（polling extension）无法被加载时，会在日志中记录一个 ERROR 信息。因为在某些情况下，加载模块失败是所期望的结果（如一个扩展模块是可选的，或它的依赖模块不可用），所以这个错项信息在某些时候会产生误导。现在，这个事件的日志信息级别已改为 WARN，从而表明它不是一个严重的错误。

在这个版本中，增加了对 NetApp Cmode 和 7mode iSCSI 驱动的扩展卷管理和非管理的支持。这为使用这些驱动提供了新的功能。

在这个版本中，增加了对 NetApp Cmode 和 7mode iSCSI 驱动的扩展卷管理和非管理的支持。这为使用这些驱动提供了新的功能。

在这个版本中，增加了对 NetApp e-series 驱动的管理/非管理卷的支持。您可以使用 '--source-name' 参数指定没有由 Block Storage 管理机制管理的卷的输入。

在这个版本中，增加了对 NetApp e-series 驱动的管理/非管理卷的支持。您可以使用 '--source-name' 参数指定没有由 Block Storage 管理机制管理的卷的输入。

这个版本为 cinder-backup 服务增加了 NFS 后端。现在，可以把卷备份到一个 NFS 存储后端。

这个版本为 cinder-backup 服务增加了 NFS 后端。现在，可以把卷备份到一个 NFS 存储后端。

这个版本为 'cinder-manage db' 增加了一个功能：现在可以安全地从 Cinder 数据库中永久删除（purge）老的、已被删除的（"deleted" ）数据。这将可以减少对数据库存储空间的使用，并可以增加虚拟机的性能。

这个版本为 'cinder-manage db' 增加了一个功能：现在可以安全地从 Cinder 数据库中永久删除（purge）老的、已被删除的（"deleted" ）数据。这将可以减少对数据库存储空间的使用，并可以增加虚拟机的性能。

在以前的版本中，SQLAlchemy 对象会错误地被多个 'cinder-volume' 进程共享。 
因此，在使用多后端 Block Storage 时，SQLAlchemy 连接会失败。这会在卷服务中导致与数据库相关的错误。
现在，在 fork  'cinder-volume' 子进程时，SQLAlchemy 连接会被重新初始化。 
因此，多后端可以正常运行。

在以前的版本中，SQLAlchemy 对象会错误地被多个 'cinder-volume' 进程共享。 
因此，在使用多后端 Block Storage 时，SQLAlchemy 连接会失败。这会在卷服务中导致与数据库相关的错误。
现在，在 fork  'cinder-volume' 子进程时，SQLAlchemy 连接会被重新初始化。 
因此，多后端可以正常运行。

在以前的版本中，从一个镜像创建卷会失败。在一个带有大量扇区的虚拟磁盘中，扇区数量会在某些情况下被错误处理，造成转换 QEMU 镜像失败（"invalid argument" 错误）。

现在，一个更新的 QEMU-img 版本解决了这个问题。从镜像创建卷现在可以正常完成。

在以前的版本中，从一个镜像创建卷会失败。在一个带有大量扇区的虚拟磁盘中，扇区数量会在某些情况下被错误处理，造成转换 QEMU 镜像失败（"invalid argument" 错误）。

现在，一个更新的 QEMU-img 版本解决了这个问题。从镜像创建卷现在可以正常完成。

现在，Image Service 的日志功能进行了改进，它可以为用户提供更好的信息。另外，敏感的信息也被从日志中删除，日志信息的级别设置也更准确。这个改变只对操作者可见。

现在，Image Service 的日志功能进行了改进，它可以为用户提供更好的信息。另外，敏感的信息也被从日志中删除，日志信息的级别设置也更准确。这个改变只对操作者可见。

在这个版本中，可以通过对 'glance-*' 进程发送 SIGHUP 信号来动态地重新加载 Image 服务的配置信息。这个信号会要求进程重新读取配置文件并加载新的配置信息。因此，现在不再需要重启整个的 Image 服务来引用配置改变。

在这个版本中，可以通过对 'glance-*' 进程发送 SIGHUP 信号来动态地重新加载 Image 服务的配置信息。这个信号会要求进程重新读取配置文件并加载新的配置信息。因此，现在不再需要重启整个的 Image 服务来引用配置改变。

在这个版本中，底层的异步任务引擎已改变。现在，它基于 taskflow 库。虽然这没有改变 API 或工作流程，但它增加了以下的配置选项：

[taskflow_executor]
engine_mode = serial # or parallel

在这个版本中，底层的异步任务引擎已改变。现在，它基于 taskflow 库。虽然这没有改变 API 或工作流程，但它增加了以下的配置选项：

[taskflow_executor]
engine_mode = serial # or parallel

以前，glance-manage 工具程序是通过 'glance-api.conf' 或 'glance-registry.conf' 进行配置的。在这个版本中包括了一个名为 'glance-manage.conf' 的新配置文件，使用它可以配置 glance-manage。您仍然可以使用 'glance-api.conf' 或 'glance-registry.conf' 来配置 glance-manage，但 'glance-manage.conf' 中的设置会被优先使用。

以前，glance-manage 工具程序是通过 'glance-api.conf' 或 'glance-registry.conf' 进行配置的。在这个版本中包括了一个名为 'glance-manage.conf' 的新配置文件，使用它可以配置 glance-manage。您仍然可以使用 'glance-api.conf' 或 'glance-registry.conf' 来配置 glance-manage，但 'glance-manage.conf' 中的设置会被优先使用。

在以前的版本中，Image 服务的 'swift' 存储会在一个单一的容器中存储所有镜像。虽然这个方法可以正常工作，但是会在大型部署中产生一个性能瓶颈。

在这个版本中，可以使用多个 Object Storage 容器来存储 'glance' 镜像。要使用这个功能，您需要把 'swift_store_multiple_containers_seed' 设为大于 '0' 的值。您可以通过启用 'swift_uer_multi_tenant' 参数来禁止使用多容器，这会使这些容器基于每个租户进行分离。

在以前的版本中，Image 服务的 'swift' 存储会在一个单一的容器中存储所有镜像。虽然这个方法可以正常工作，但是会在大型部署中产生一个性能瓶颈。

在这个版本中，可以使用多个 Object Storage 容器来存储 'glance' 镜像。要使用这个功能，您需要把 'swift_store_multiple_containers_seed' 设为大于 '0' 的值。您可以通过启用 'swift_uer_multi_tenant' 参数来禁止使用多容器，这会使这些容器基于每个租户进行分离。

在这个版本中，glance_store 库支持更多的存储功能。您可以对在特定 store 中可以进行什么操作进行更精细的控制。这个版本包括了以下访问控制：

 - READ_ACCESS：一般的读访问 
 - WRITE_ACCESS：一般的写访问
 - RW_ACCESS ：READ_ACCESS 和 WRITE_ACCESS
 - READ_OFFSET：从一个 offset 中读所有位（包括 READ_ACCESS） 
 - WRITE_OFFSET：对一个 offset 写所有位（包括 WRITE_ACCESS） 
 - RW_OFFSET：READ_OFFSET 和 WRITE_OFFSET
 - READ_CHUNK：读所需的位长度（包括 READ_ACCESS）  
 - WRITE_CHUNK：写所需的位长度（包括 WRITE_ACCESS） 
 - RW_CHUNK：READ_CHUNK 和 WRITE_CHUNK  
 - READ_RANDOM：READ_OFFSET 和 READ_CHUNK  
 - WRITE_RANDOM：WRITE_OFFSET 和 WRITE_CHUNK
 - RW_RANDOM：RW_OFFSET 和 RW_CHUNK  
 - DRIVER_REUSABLE：驱动是无状态的，它的实例可以被安全地重新使用

在这个版本中，glance_store 库支持更多的存储功能。您可以对在特定 store 中可以进行什么操作进行更精细的控制。这个版本包括了以下访问控制：

 - READ_ACCESS：一般的读访问 
 - WRITE_ACCESS：一般的写访问
 - RW_ACCESS ：READ_ACCESS 和 WRITE_ACCESS
 - READ_OFFSET：从一个 offset 中读所有位（包括 READ_ACCESS） 
 - WRITE_OFFSET：对一个 offset 写所有位（包括 WRITE_ACCESS） 
 - RW_OFFSET：READ_OFFSET 和 WRITE_OFFSET
 - READ_CHUNK：读所需的位长度（包括 READ_ACCESS）  
 - WRITE_CHUNK：写所需的位长度（包括 WRITE_ACCESS） 
 - RW_CHUNK：READ_CHUNK 和 WRITE_CHUNK  
 - READ_RANDOM：READ_OFFSET 和 READ_CHUNK  
 - WRITE_RANDOM：WRITE_OFFSET 和 WRITE_CHUNK
 - RW_RANDOM：RW_OFFSET 和 RW_CHUNK  
 - DRIVER_REUSABLE：驱动是无状态的，它的实例可以被安全地重新使用

在这个版本中，添加了一个全新的 Image 服务搜索功能 API，它提高了列出和搜索操作的性能，特别是现在可以和 UI 进行交流。

用户可以使用搜索 API 进行搜索查询，并返回查询的结果。查询的条件可以是作为参数的一个简单查询字符串，也可以是一个请求的内容（body）。所有的查询 API 可以应用于一个索引中的多个类型，也可以应用于支持多索引语法的多索引。

请注意：在 RHEL OpenStack Plaform 8 (Liberty) 发行版本中，这个功能会从 Image 服务中删除。

在这个版本中，添加了一个全新的 Image 服务搜索功能 API，它提高了列出和搜索操作的性能，特别是现在可以和 UI 进行交流。

用户可以使用搜索 API 进行搜索查询，并返回查询的结果。查询的条件可以是作为参数的一个简单查询字符串，也可以是一个请求的内容（body）。所有的查询 API 可以应用于一个索引中的多个类型，也可以应用于支持多索引语法的多索引。

请注意：在 RHEL OpenStack Plaform 8 (Liberty) 发行版本中，这个功能会从 Image 服务中删除。

在以前的版本中，每个到 policy.enforce 的调用都会传递一个空的字典（dictionary）作为目标。因为目标总是一个空字典，操作者将无法使用 policy.json 文件中的、特定租户的限制规则。如果您试图限制一些操作来使镜像的所有者（带有正确租户 ID 的用户）可以执行操作，检查的过程会失败。这是因为目标是正确的，但它是一个空的字典。

在这个版本中，您可以把带有镜像的 ImageTargeton 实例传递给 enforcer，从而使这些规则可以被使用并被强制执行。您可以基于租户（例如，owner:%(tenant)）来为镜像的所有者正确地分配权限。如果没有这个前缀，Image 服务中唯一可以正常工作的检查是 RoleCheck（例如，role:admin）。

在以前的版本中，每个到 policy.enforce 的调用都会传递一个空的字典（dictionary）作为目标。因为目标总是一个空字典，操作者将无法使用 policy.json 文件中的、特定租户的限制规则。如果您试图限制一些操作来使镜像的所有者（带有正确租户 ID 的用户）可以执行操作，检查的过程会失败。这是因为目标是正确的，但它是一个空的字典。

在这个版本中，您可以把带有镜像的 ImageTargeton 实例传递给 enforcer，从而使这些规则可以被使用并被强制执行。您可以基于租户（例如，owner:%(tenant)）来为镜像的所有者正确地分配权限。如果没有这个前缀，Image 服务中唯一可以正常工作的检查是 RoleCheck（例如，role:admin）。

在这个版本中，可以对列出操作的结果根据多个过滤选项进行过滤，并以不同的顺序排序。例如：

  /images?sort=status:asc,name:asc,created_at:desc

以上会返回一列镜像，它们会根据状态、名称和创建时间进行排序（排序顺序分别是升序、升序和降序）。

在这个版本中，可以对列出操作的结果根据多个过滤选项进行过滤，并以不同的顺序排序。例如：

  /images?sort=status:asc,name:asc,created_at:desc

以上会返回一列镜像，它们会根据状态、名称和创建时间进行排序（排序顺序分别是升序、升序和降序）。

在这个版本中，可以对列出操作的结果根据多个过滤选项进行过滤，并以不同的顺序排序。例如：

  /images?sort=status:asc,name:asc,created_at:desc

以上会返回一列镜像，它们会根据状态、名称和创建时间进行排序（排序顺序分别是升序、升序和降序）。

在这个版本中，可以对列出操作的结果根据多个过滤选项进行过滤，并以不同的顺序排序。例如：

  /images?sort=status:asc,name:asc,created_at:desc

以上会返回一列镜像，它们会根据状态、名称和创建时间进行排序（排序顺序分别是升序、升序和降序）。

Orchestration 服务现在包括了一个 "OS::Heat::Stack" 资源类型。这个原生的 OpenStack 资源被用来在一个模板中明确地创建一个子堆栈。"OS::Heat::Stack" 资源类型包括了带有一个 'region_name' 子属性的 'context' 属性，允许 Orchestration 服务在不同的区域中管理堆栈。

Orchestration 服务现在包括了一个 "OS::Heat::Stack" 资源类型。这个原生的 OpenStack 资源被用来在一个模板中明确地创建一个子堆栈。"OS::Heat::Stack" 资源类型包括了带有一个 'region_name' 子属性的 'context' 属性，允许 Orchestration 服务在不同的区域中管理堆栈。

现在，当它们的规则被改变后，AWS::EC2::SecurityGroup 类型资源可以被更新。这和 CloudFormation 中的 AWS::EC2::SecurityGroup 相一致。以前，当它们的规则被改变后，安全组会被替代。

现在，当它们的规则被改变后，AWS::EC2::SecurityGroup 类型资源可以被更新。这和 CloudFormation 中的 AWS::EC2::SecurityGroup 相一致。以前，当它们的规则被改变后，安全组会被替代。

现在，Heat 支持 hook，用户可以使用它在特定点上暂停堆栈操作，把自己的操作加入到 Heat 的流程中。hook 通过堆栈的环境文件附加到资源中，当前支持的 hook 类型是 'pre-create' 和 'pre-update'。

现在，Heat 支持 hook，用户可以使用它在特定点上暂停堆栈操作，把自己的操作加入到 Heat 的流程中。hook 通过堆栈的环境文件附加到资源中，当前支持的 hook 类型是 'pre-create' 和 'pre-update'。

现在，OS::Nova::Server 资源类型包括了一个 'console_urls' 属性。这可以使用户从资源中获得服务器的控制台（如 VNC 控制台）的 URL。

现在，OS::Nova::Server 资源类型包括了一个 'console_urls' 属性。这可以使用户从资源中获得服务器的控制台（如 VNC 控制台）的 URL。

现在，当使用 Orchestration API 对资源进行查询时，用户可以要求在输出中包括资源的一个或多个属性值。通过这个功能，用户在不修改堆栈模板的情况下就可以随时在输出中获得任何资源的数据，这将有助于对系统进行故障排除。

现在，当使用 Orchestration API 对资源进行查询时，用户可以要求在输出中包括资源的一个或多个属性值。通过这个功能，用户在不修改堆栈模板的情况下就可以随时在输出中获得任何资源的数据，这将有助于对系统进行故障排除。

现在，OS::Cinder::Volume 资源类型包括了一个 'scheduler_hints' 属性，使用它，可以在创建卷时把 scheduler hint 传递给 Block Storage 服务。这需要 Block Storage API 的版本是 v2。

现在，OS::Cinder::Volume 资源类型包括了一个 'scheduler_hints' 属性，使用它，可以在创建卷时把 scheduler hint 传递给 Block Storage 服务。这需要 Block Storage API 的版本是 v2。

现在，heat-manage 命令包括了一个 "heat-manage service-list" 子命令。这个子命令会显示活动的 "heat-engine" 进程的信息，如它们在哪里运行、它们当前的状态。

现在，heat-manage 命令包括了一个 "heat-manage service-list" 子命令。这个子命令会显示活动的 "heat-engine" 进程的信息，如它们在哪里运行、它们当前的状态。

现在，OS::Neutron::Port 资源类型支持一个 'binding:vnic_type' 属性，具有适当权限的用户可以使用它来为 OpenStack Networking 指定 VNIC 类型。

现在，OS::Neutron::Port 资源类型支持一个 'binding:vnic_type' 属性，具有适当权限的用户可以使用它来为 OpenStack Networking 指定 VNIC 类型。

现在，AWS::AutoScaling::AutoScalingGroup 资源类型支持一个 'InstanceId' 属性。使用它，可以使一个 autoscaling 组的启动配置通过克隆一个存在的服务器获得，而不是克隆一个 AWS::AutoScaling::LaunchConfiguration 资源。

现在，AWS::AutoScaling::AutoScalingGroup 资源类型支持一个 'InstanceId' 属性。使用它，可以使一个 autoscaling 组的启动配置通过克隆一个存在的服务器获得，而不是克隆一个 AWS::AutoScaling::LaunchConfiguration 资源。

现在，AWS::AutoScaling::LaunchConfiguration 资源类型支持一个 'InstanceId' 属性。使用它，可以使一个 autoscaling 组的启动配置通过克隆一个存在的服务器获得。

现在，AWS::AutoScaling::LaunchConfiguration 资源类型支持一个 'InstanceId' 属性。使用它，可以使一个 autoscaling 组的启动配置通过克隆一个存在的服务器获得。

以前，在堆栈更新时，如果一个环境的 'files' 项的内容发生了变化，Orchestration 服务会通过综合新文件和旧的堆栈定义来决定当前的状态。这么做的目的是把以前的状态和新文件以及新模板进行比较。
作为结果，Orchestration 服务没有发现所包括的文件的变化，那些因文件变化而需要进行的更新将不会发生。另外，如果在堆栈更新过程中以前指定的文件被从环境中删除，堆栈更新会失败（尽管以后使用相同数据进行的更新将会成功）。

在这个版本中，Orchestration 服务使用带有旧文件的旧堆栈与新模板和新文件进行比较。当在更新过程中编辑了在环境中包括的文件，更新操作仍然可以正常工作。

以前，在堆栈更新时，如果一个环境的 'files' 项的内容发生了变化，Orchestration 服务会通过综合新文件和旧的堆栈定义来决定当前的状态。这么做的目的是把以前的状态和新文件以及新模板进行比较。
作为结果，Orchestration 服务没有发现所包括的文件的变化，那些因文件变化而需要进行的更新将不会发生。另外，如果在堆栈更新过程中以前指定的文件被从环境中删除，堆栈更新会失败（尽管以后使用相同数据进行的更新将会成功）。

在这个版本中，Orchestration 服务使用带有旧文件的旧堆栈与新模板和新文件进行比较。当在更新过程中编辑了在环境中包括的文件，更新操作仍然可以正常工作。

在以前的版本中，Orchestration 服务无法识别对一个模板资源（如基于堆栈但没有被明确指定的资源）中的模板绝对路径的改变。这会导致一个问题：当资源模板被重命名，或被删除时，基于嵌套堆栈的模板资源无法被更新。 

在这个版本中，Orchestration 服务可以发现这种变化，从而使嵌套的堆栈可以被更新。

在以前的版本中，Orchestration 服务无法识别对一个模板资源（如基于堆栈但没有被明确指定的资源）中的模板绝对路径的改变。这会导致一个问题：当资源模板被重命名，或被删除时，基于嵌套堆栈的模板资源无法被更新。 

在这个版本中，Orchestration 服务可以发现这种变化，从而使嵌套的堆栈可以被更新。

现在，Bare Metal 可以通过使用 iLO client python 库来支持 HP ProLiant Services 的管理接口，这将允许 Bare Metal 执行管理操作（如获取/设置一个启动设备）。

现在，Bare Metal 可以通过使用 iLO client python 库来支持 HP ProLiant Services 的管理接口，这将允许 Bare Metal 执行管理操作（如获取/设置一个启动设备）。

现在，Bare Metal 服务可以使用 cloud-init 和相似的早期初始化工具在实例中插入用户数据。在以前，需要设置一个元数据服务来实现这个功能。

在这个版本中，Bare Metal 可以在部署过程中在本地磁盘（被标识为 'config-2' 的设备）上插入实例元数据。然后，再配置早期初始化工具来找到这个设备，并从中获取相关数据。

现在，Bare Metal 服务可以使用 cloud-init 和相似的早期初始化工具在实例中插入用户数据。在以前，需要设置一个元数据服务来实现这个功能。

在这个版本中，Bare Metal 可以在部署过程中在本地磁盘（被标识为 'config-2' 的设备）上插入实例元数据。然后，再配置早期初始化工具来找到这个设备，并从中获取相关数据。

现在，Bare Metal 服务可以使用 UEFI (http://www.uefi.org) 的 Secure Boot 功能部署节点。Secure Boot 可以保证节点只引导信任的软件。

因此，整个引导链可以在引导时被验证。然后，您可以配置节点来只引导经过授权的镜像，从而达到增强安全性的目的。

现在，Bare Metal 服务可以使用 UEFI (http://www.uefi.org) 的 Secure Boot 功能部署节点。Secure Boot 可以保证节点只引导信任的软件。

因此，整个引导链可以在引导时被验证。然后，您可以配置节点来只引导经过授权的镜像，从而达到增强安全性的目的。

现在，Bare Metal 实例包括了一个名为 'maintenance_reason' 的新项，它可以被用来解释一个节点处于维护状态的原因。

现在，Bare Metal 实例包括了一个名为 'maintenance_reason' 的新项，它可以被用来解释一个节点处于维护状态的原因。

现在，Bare Metal 服务支持 Fujitsu iRMC（集成的远程管理控制器）硬件。因此，Bare Metal 现在可以管理这种系统的电源状态。

现在，Bare Metal 服务支持 Fujitsu iRMC（集成的远程管理控制器）硬件。因此，Bare Metal 现在可以管理这种系统的电源状态。

现在，所有 Ironic 驱动都支持通过 IPA ramdisk 进行部署。IPA 是使用 Python 语言开发的，它比 BASH ramdisk 支持更多的功能，并作为一个服务运行。因此，在一般情况下，通过 IPA 部署的节点更易进行部署、故障排除和管理。

现在，所有 Ironic 驱动都支持通过 IPA ramdisk 进行部署。IPA 是使用 Python 语言开发的，它比 BASH ramdisk 支持更多的功能，并作为一个服务运行。因此，在一般情况下，通过 IPA 部署的节点更易进行部署、故障排除和管理。

以前，DRAC 卡中的 WSMAN 接口可以在 11g 硬件和 12g 硬件间改变。
因此，当在 11g 硬件上使用 DRAC 驱动时，`get_boot_device` 和 `set_boot_device` 调用在 OpenStack Bare Metal Provisioning (Ironic) 上会失败。
在这个版本中，DRAC 启动会检查 Lifecycle 控制器的版本，并根据版本的不同使用相应的方法来管理引导设备。
因此，`get_boot_device` 和 `set_boot_device` 操作可以在 11g 节点上正常工作。

以前，DRAC 卡中的 WSMAN 接口可以在 11g 硬件和 12g 硬件间改变。
因此，当在 11g 硬件上使用 DRAC 驱动时，`get_boot_device` 和 `set_boot_device` 调用在 OpenStack Bare Metal Provisioning (Ironic) 上会失败。
在这个版本中，DRAC 启动会检查 Lifecycle 控制器的版本，并根据版本的不同使用相应的方法来管理引导设备。
因此，`get_boot_device` 和 `set_boot_device` 操作可以在 11g 节点上正常工作。

在任何时候，Compute 服务都应该可以删除一个实例。但是，Bare Metal 实例只能在特定阶段（处于 'DEPLOYWAIT' 状态）被停止。因此，当 Compute 服务试图删除一个没有处于 DEPLOYWAIT 状态的 Bare Metal 实例时，操作会失败。实例可能会被固定在特定的状态，并需要对数据库进行修改才可以解决这个问题。

在这个版本中，虽然 Bare Metal 服务在没有处于 DEPLOYWAIT 状态时仍然无法终止实例，但 Bare Metal 实例不再会被固定在特定状态。

在任何时候，Compute 服务都应该可以删除一个实例。但是，Bare Metal 实例只能在特定阶段（处于 'DEPLOYWAIT' 状态）被停止。因此，当 Compute 服务试图删除一个没有处于 DEPLOYWAIT 状态的 Bare Metal 实例时，操作会失败。实例可能会被固定在特定的状态，并需要对数据库进行修改才可以解决这个问题。

在这个版本中，虽然 Bare Metal 服务在没有处于 DEPLOYWAIT 状态时仍然无法终止实例，但 Bare Metal 实例不再会被固定在特定状态。

以前，OpenStack Bare Metal Provisioning (Ironic) 中的 DRAC 驱动会错误地把任务状态 'completed with errors' 作为 'in-progress' 状态。这会导致 `get_boot_device` 和 `set_boot_device` 操作失败，因为它们需要没有状态为 in-progress 的任务存在。
这个版本解决了这个问题。它把 'completed with errors' 加入到成功完成状态列表中。因此，`get_boot_device` 和 `set_boot_device` 可以在 DRAC 卡上具有状态为 'completed with errors' 的任务时，仍然正常工作。

以前，OpenStack Bare Metal Provisioning (Ironic) 中的 DRAC 驱动会错误地把任务状态 'completed with errors' 作为 'in-progress' 状态。这会导致 `get_boot_device` 和 `set_boot_device` 操作失败，因为它们需要没有状态为 in-progress 的任务存在。
这个版本解决了这个问题。它把 'completed with errors' 加入到成功完成状态列表中。因此，`get_boot_device` 和 `set_boot_device` 可以在 DRAC 卡上具有状态为 'completed with errors' 的任务时，仍然正常工作。

以前，DRAC `vendor_passthru interface` 缺少了 `pass_bootloader_install_info` 这个方法。当本地引导被启用时，PXE 部署任务会失败。
在这个版本中，标准 PXE 接口中的 `pass_bootloader_install_info` 被添加到 `DRAC vendor_passthru` 中。当本地引导被启用时，部署可以成功。

以前，DRAC `vendor_passthru interface` 缺少了 `pass_bootloader_install_info` 这个方法。当本地引导被启用时，PXE 部署任务会失败。
在这个版本中，标准 PXE 接口中的 `pass_bootloader_install_info` 被添加到 `DRAC vendor_passthru` 中。当本地引导被启用时，部署可以成功。

在以前的版本中，OpenStack Bare Metal Provisioning (Ironic) 操作（如 'Power off'）会过长地锁定一个节点。
作为结果，一些操作会失败，因为节点仍然被认为处于锁定状态。
在这个版本中，重新尝试的超时时间被调整为 2 分钟。因此，不会出现节点锁定错误。

在以前的版本中，OpenStack Bare Metal Provisioning (Ironic) 操作（如 'Power off'）会过长地锁定一个节点。
作为结果，一些操作会失败，因为节点仍然被认为处于锁定状态。
在这个版本中，重新尝试的超时时间被调整为 2 分钟。因此，不会出现节点锁定错误。

现在，Identity Service (keystone) 可以重新授权信任关系。具有信任权利的信任者（trustee）可以创建另外一个信任关系来把他们的角色授权给其它用户。另外，一个计时器会列出信任可以被重新授权的次数。
这个功能允许一个信任者把包括在令牌中的角色重新授权给其它信任者。初始创建信任的用户可以控制一个信任是否可以被重新授权。

现在，Identity Service (keystone) 可以重新授权信任关系。具有信任权利的信任者（trustee）可以创建另外一个信任关系来把他们的角色授权给其它用户。另外，一个计时器会列出信任可以被重新授权的次数。
这个功能允许一个信任者把包括在令牌中的角色重新授权给其它信任者。初始创建信任的用户可以控制一个信任是否可以被重新授权。

现在，Identity Service (keystone) 允许明确请求无范围令牌（unscoped token）。
在以前的版本中，一个被分配了默认项目的用户无法获取一个无范围令牌。如果这个用户在请求令牌时没有指定范围，它的范围会被自动定为默认项目。
在这个版本中，所有用户（包括指定了默认项目的用户）都可以获得无范围令牌。

现在，Identity Service (keystone) 允许明确请求无范围令牌（unscoped token）。
在以前的版本中，一个被分配了默认项目的用户无法获取一个无范围令牌。如果这个用户在请求令牌时没有指定范围，它的范围会被自动定为默认项目。
在这个版本中，所有用户（包括指定了默认项目的用户）都可以获得无范围令牌。

在这个版本中，Identity Service (keystone) 通过在项目资源中指定 'parent_id' 来创建一个项目的分级结构。
以前，Identity 服务只支持平面的项目模式，而分级结构的项目会有更大的灵活性，可以更好地与实际的组织结构相对应。
现在，项目可以定义一个父项目，这就实现了项目的分级结构。

在这个版本中，Identity Service (keystone) 通过在项目资源中指定 'parent_id' 来创建一个项目的分级结构。
以前，Identity 服务只支持平面的项目模式，而分级结构的项目会有更大的灵活性，可以更好地与实际的组织结构相对应。
现在，项目可以定义一个父项目，这就实现了项目的分级结构。

现在，Identity 服务允许无范围联邦令牌（unscoped federation token）使用 'token' 验证方法获得一个有范围令牌（scoped token）。

在使用 Identity 服务的 federation 扩展时，会返回一个无范围联邦令牌作为初始验证。然后，它可以被交换为一个有范围令牌。在以前的版本中，无范围联邦令牌需要使用 'saml2' 或 'mapped' 验证来获取一个有范围令牌。这和把普通的无范围令牌交换为有范围令牌的过程（使用 'token' ）不一致。

现在，为无范围联邦令牌交换一个有范围令牌的过程也使用 'token' 验证方法，这和为普通无范围令牌进行交换的方法保持了一致。

现在，Identity 服务允许无范围联邦令牌（unscoped federation token）使用 'token' 验证方法获得一个有范围令牌（scoped token）。

在使用 Identity 服务的 federation 扩展时，会返回一个无范围联邦令牌作为初始验证。然后，它可以被交换为一个有范围令牌。在以前的版本中，无范围联邦令牌需要使用 'saml2' 或 'mapped' 验证来获取一个有范围令牌。这和把普通的无范围令牌交换为有范围令牌的过程（使用 'token' ）不一致。

现在，为无范围联邦令牌交换一个有范围令牌的过程也使用 'token' 验证方法，这和为普通无范围令牌进行交换的方法保持了一致。

现在，Identity 服务对重新设定令牌范围的操作进行限制，它只允许无范围令牌被交换为有范围令牌。

Identity 服务允许一个存在的令牌使用 'token' 验证方法来获得一个新令牌。在以前的版本中，如果用户具有一个有效的、范围是某个项目的令牌，这个用户就可以使用这个令牌获得范围为另外一个项目的有效令牌。这将允许具有用户令牌的用户访问这个用户可以访问的任何项目，而不是只可以访问令牌范围内的项目。而从提高安全性的角度来看，应该不允许这个行为。
 
现在，添加了一个新的 'allow_rescope_scoped_token' 配置选项，使用它可以限制重新设定令牌范围的操作。只有在启用了这个选项时，使用无范围令牌进行验证的重设令牌范围的操作才被允许。

现在，Identity 服务对重新设定令牌范围的操作进行限制，它只允许无范围令牌被交换为有范围令牌。

Identity 服务允许一个存在的令牌使用 'token' 验证方法来获得一个新令牌。在以前的版本中，如果用户具有一个有效的、范围是某个项目的令牌，这个用户就可以使用这个令牌获得范围为另外一个项目的有效令牌。这将允许具有用户令牌的用户访问这个用户可以访问的任何项目，而不是只可以访问令牌范围内的项目。而从提高安全性的角度来看，应该不允许这个行为。
 
现在，添加了一个新的 'allow_rescope_scoped_token' 配置选项，使用它可以限制重新设定令牌范围的操作。只有在启用了这个选项时，使用无范围令牌进行验证的重设令牌范围的操作才被允许。

现在，Identity 服务对一个名为 'fernet' 的新令牌格式提供了试验性的支持。

Identity 服务当前所支持的令牌格式需要签发的令牌持久存在于数据库的表中，随着时间的推移，这个数据库表可能变得很大，这就需要对数据库进行相应的调整并执行删除任务来保证 Identity 服务的性能。新的 'fernet' 令牌格式被设计为可以不使用数据库表，从而避免了表数据过大的问题。'fernet' 令牌格式当前还是作为一个试验功能被支持。

现在，Identity 服务对一个名为 'fernet' 的新令牌格式提供了试验性的支持。

Identity 服务当前所支持的令牌格式需要签发的令牌持久存在于数据库的表中，随着时间的推移，这个数据库表可能变得很大，这就需要对数据库进行相应的调整并执行删除任务来保证 Identity 服务的性能。新的 'fernet' 令牌格式被设计为可以不使用数据库表，从而避免了表数据过大的问题。'fernet' 令牌格式当前还是作为一个试验功能被支持。

在以前的版本中，当在一个 Open vSwitch (OVS) 代理上手工切换通道源 IP 地址时，其它代理会为这个代理保持开放两个通道：一个是它的旧 IP 地址，一个是它的新 IP 地址。
作为结果，在运行 OVS 代理的云中的所有虚拟机监控程序（hypervisor）上会积累过多的元数据。
现在，为了解决这个问题，Network 节点会监测到主机上的 IP 地址发生改变的情况，记录下相应信息，并把 IP 地址的改变通知给其它代理。

在以前的版本中，当在一个 Open vSwitch (OVS) 代理上手工切换通道源 IP 地址时，其它代理会为这个代理保持开放两个通道：一个是它的旧 IP 地址，一个是它的新 IP 地址。
作为结果，在运行 OVS 代理的云中的所有虚拟机监控程序（hypervisor）上会积累过多的元数据。
现在，为了解决这个问题，Network 节点会监测到主机上的 IP 地址发生改变的情况，记录下相应信息，并把 IP 地址的改变通知给其它代理。

在以前的版本中，当附加到一个 LBaaS 池中的子网被计划外删除时，OpenStack Dashboard LBaaS 池的详情页无法正确处理这个变化。
作为结果，如果您创建了一个网络、子网、路由和负载均衡设备（load balancer），然后删除了网络、子网和路由但保留了负载均衡设备，OpenStack Dashboard LBaaS 详情页会返回代码为 500 的错误。
在这个版本中解决了这个问题，如果出现以上情况，LBaaS 详情页会正确处理，并显示一个警告信息。

在以前的版本中，当附加到一个 LBaaS 池中的子网被计划外删除时，OpenStack Dashboard LBaaS 池的详情页无法正确处理这个变化。
作为结果，如果您创建了一个网络、子网、路由和负载均衡设备（load balancer），然后删除了网络、子网和路由但保留了负载均衡设备，OpenStack Dashboard LBaaS 详情页会返回代码为 500 的错误。
在这个版本中解决了这个问题，如果出现以上情况，LBaaS 详情页会正确处理，并显示一个警告信息。

在这个版本中，管理员可以查看每个节点（运行活动实例）的高可用性路由的状态。
在以前的版本中，管理员无法查看高可用性路由的状态信息，这为维护（如把一个 HA 路由从一个代理移到另外一个代理上；或评估把一个节点设置为维护模式将会造成的影响）造成了困难。
这个新功能也被作为一个健全检查来保证路由确实只在一个节点上是活跃的。现在，管理员可以在高可用性路由上运行 'neutron l3-agent-list-hosting-router <router_id>' 命令来查看活跃的实例运行于哪个节点。

在这个版本中，管理员可以查看每个节点（运行活动实例）的高可用性路由的状态。
在以前的版本中，管理员无法查看高可用性路由的状态信息，这为维护（如把一个 HA 路由从一个代理移到另外一个代理上；或评估把一个节点设置为维护模式将会造成的影响）造成了困难。
这个新功能也被作为一个健全检查来保证路由确实只在一个节点上是活跃的。现在，管理员可以在高可用性路由上运行 'neutron l3-agent-list-hosting-router <router_id>' 命令来查看活跃的实例运行于哪个节点。

现在，带有分布式路由的 OpenStack Networking 部署允许租户创建他们自己的、带有 VLAN 段的网络。
在以前的版本中，分布式路由只支持通道网络（tunnel network），而许多部署倾向使用 VLAN 租户网络。
在这个版本中，分布式路由可以支持通道网络和 VLAN 网络。

现在，带有分布式路由的 OpenStack Networking 部署允许租户创建他们自己的、带有 VLAN 段的网络。
在以前的版本中，分布式路由只支持通道网络（tunnel network），而许多部署倾向使用 VLAN 租户网络。
在这个版本中，分布式路由可以支持通道网络和 VLAN 网络。

Red Hat Enterprise Linux OpenStack Platform 7 使用 libreswan 替代了 openswan，但 OpenStack Networking (neutron) openswan VPNaaS 驱动无法和 libreswan 一起正常工作。
在这个版本中，您可以在 vpnagent.ini 中启用 libreswan 的驱动：
[vpnagent]
vpn_device_driver=neutron_vpnaas.services.vpn.device_drivers.libreswan_ipsec.LibreSwanDrive

作为结果，VPNaaS 现在可以正常工作。

Red Hat Enterprise Linux OpenStack Platform 7 使用 libreswan 替代了 openswan，但 OpenStack Networking (neutron) openswan VPNaaS 驱动无法和 libreswan 一起正常工作。
在这个版本中，您可以在 vpnagent.ini 中启用 libreswan 的驱动：
[vpnagent]
vpn_device_driver=neutron_vpnaas.services.vpn.device_drivers.libreswan_ipsec.LibreSwanDrive

作为结果，VPNaaS 现在可以正常工作。

因为 'python-neutron-fwaas' 软件包中的一个已知问题（缺少了数据库升级的 'versions' 目录），防火墙即服务（Firewall-as-a-Service，简称 FWaaS）可能无法正常工作。
另外，在不同的发行版本间升级数据库 schema 当前可能还无法正常工作。

因为 'python-neutron-fwaas' 软件包中的一个已知问题（缺少了数据库升级的 'versions' 目录），防火墙即服务（Firewall-as-a-Service，简称 FWaaS）可能无法正常工作。
另外，在不同的发行版本间升级数据库 schema 当前可能还无法正常工作。

因为 'python-neutron-fwaas' 软件包中的一个已知问题（缺少了数据库升级的 'versions' 目录），防火墙即服务（Firewall-as-a-Service，简称 FWaaS）可能无法正常工作。
另外，在不同的发行版本间升级数据库 schema 当前可能还无法正常工作。

因为 'python-neutron-fwaas' 软件包中的一个已知问题（缺少了数据库升级的 'versions' 目录），防火墙即服务（Firewall-as-a-Service，简称 FWaaS）可能无法正常工作。
另外，在不同的发行版本间升级数据库 schema 当前可能还无法正常工作。

在以前的版本中，dnsmasq 不会把租赁（lease）信息保存在具有持久性的存储设备中。当它被重启时，租赁信息会丢失。这是因为删除了 dnsmasq 的 '--dhcp-script' 选项所造成的（BZ#1202392）。
作为结果，实例会被长时间固定在网络引导过程中。另外，NACK 信息会被记录在 dnsmasq 日志中。
这个发行版本解决了以上问题，它删除了验证选项，在对 DHCPREQUEST 进行响应时不会把 NAKs 发送到其它服务器。通过这个改变，日志文件中将不再包括 DHCPNAK 信息。

在以前的版本中，dnsmasq 不会把租赁（lease）信息保存在具有持久性的存储设备中。当它被重启时，租赁信息会丢失。这是因为删除了 dnsmasq 的 '--dhcp-script' 选项所造成的（BZ#1202392）。
作为结果，实例会被长时间固定在网络引导过程中。另外，NACK 信息会被记录在 dnsmasq 日志中。
这个发行版本解决了以上问题，它删除了验证选项，在对 DHCPREQUEST 进行响应时不会把 NAKs 发送到其它服务器。通过这个改变，日志文件中将不再包括 DHCPNAK 信息。

在 Kilo 中，Neutron 服务会使用 rootwrap 守护进程执行外部命令（如 'ip' 或 'sysctl'）。守护进程会预先缓存 rootwrap 过滤器，从而可以极大地提高代理的整体性能。

对于 RHEL-OSP7，rootwrap 进程被默认启用。如果您不想使用它，而是使用其它 root 权限分离机制（如 'sudo'），则需要在 neutron.conf 文件的 [agent] 段中设置 'root_helper_daemon =' 来禁用这个守护进程。

在 Kilo 中，Neutron 服务会使用 rootwrap 守护进程执行外部命令（如 'ip' 或 'sysctl'）。守护进程会预先缓存 rootwrap 过滤器，从而可以极大地提高代理的整体性能。

对于 RHEL-OSP7，rootwrap 进程被默认启用。如果您不想使用它，而是使用其它 root 权限分离机制（如 'sudo'），则需要在 neutron.conf 文件的 [agent] 段中设置 'root_helper_daemon =' 来禁用这个守护进程。

在以前的版本中，'neutron-lbaasv2-agent' 服务缺少了 .service 文件。
因此，在 systemd 的控制下无法启动代理。
在这个版本中，添加了 .service 文件。
作为结果，'systemctl start neutron-lbaasv2-agent' 命令现在可以启动服务。

在以前的版本中，'neutron-lbaasv2-agent' 服务缺少了 .service 文件。
因此，在 systemd 的控制下无法启动代理。
在这个版本中，添加了 .service 文件。
作为结果，'systemctl start neutron-lbaasv2-agent' 命令现在可以启动服务。

现在，您可以使用 VMWare vSAN 数据存储。这些存储允许您为实例使用虚拟机监控程序本地存储的同时使用 vMotion。

现在，您可以使用 VMWare vSAN 数据存储。这些存储允许您为实例使用虚拟机监控程序本地存储的同时使用 vMotion。

现在，您可以使用 VMware 存储策略来管理如何把存储配置给不同的实例。使用这个功能，您可以在带有多个数据存储（data store）的 VMware 基础架构的环境中为实例分配最佳存储。

现在，您可以使用 VMware 存储策略来管理如何把存储配置给不同的实例。使用这个功能，您可以在带有多个数据存储（data store）的 VMware 基础架构的环境中为实例分配最佳存储。

在以前的版本中，Compute 数据库少了一个对 virtual_interfaces 表的索引。因此，当增加了大量对这个表的操作时，会需要大量时间来进行处理，从而会出现超时错误。

在这个版本中，加上了对 virtual_interfaces 表的索引，从而提高了对这个表进行操作的性能。

在以前的版本中，Compute 数据库少了一个对 virtual_interfaces 表的索引。因此，当增加了大量对这个表的操作时，会需要大量时间来进行处理，从而会出现超时错误。

在这个版本中，加上了对 virtual_interfaces 表的索引，从而提高了对这个表进行操作的性能。

增加了对已经被分配了一个主机 PCI 设备的客户机（guest）的智能 NUMA 节点放置功能，现在，PCI I/O 设备（如网卡）可以更紧密地关联到某个处理器。因为访问直接附加到某个处理器上的内存会和访问直接附加到同一个服务器上的其它处理器上的内存有不同的性能和延迟特征，所以这个功能对提升系统性能有好处。在这个版本中，Openstack 客户机的放置操作可以被优化，从而可以保证绑定了特定 PCI 设备的客户机被调度为在与这个客户机的 pCPU 和内存分配相关联的 NUMA 节点上运行。例如，如果一个客户机的资源需要包括在一个单一 NUMA 节点中，则这个客户机的所有资源都将会和同一个 NUMA 节点相关联。

增加了对已经被分配了一个主机 PCI 设备的客户机（guest）的智能 NUMA 节点放置功能，现在，PCI I/O 设备（如网卡）可以更紧密地关联到某个处理器。因为访问直接附加到某个处理器上的内存会和访问直接附加到同一个服务器上的其它处理器上的内存有不同的性能和延迟特征，所以这个功能对提升系统性能有好处。在这个版本中，Openstack 客户机的放置操作可以被优化，从而可以保证绑定了特定 PCI 设备的客户机被调度为在与这个客户机的 pCPU 和内存分配相关联的 NUMA 节点上运行。例如，如果一个客户机的资源需要包括在一个单一 NUMA 节点中，则这个客户机的所有资源都将会和同一个 NUMA 节点相关联。

当把 Red Hat Enterprise Linux OpenStack Platform 从版本 6 完全升级到版本 7 后（所有节点都运行版本 7 的代码），您需要启动一个后台的 PCI 设备 NUMA 节点信息迁移操作，把这些信息从旧的位置迁移到新的位置。版本 7 的 conductor 节点会在需要的时候自动进行这个操作，但是其它处于空闲状态的数据需要在后台进行迁移。这个操作需要在版本 8 发行前完成，因为版本 8 将不再支持旧的位置。使用 'nova-manage migrate-rhos-6-pci-device-data' 来进行这个操作。
请注意，这只适用于使用 Compute 的 PCI pass-through 功能的用户。

当把 Red Hat Enterprise Linux OpenStack Platform 从版本 6 完全升级到版本 7 后（所有节点都运行版本 7 的代码），您需要启动一个后台的 PCI 设备 NUMA 节点信息迁移操作，把这些信息从旧的位置迁移到新的位置。版本 7 的 conductor 节点会在需要的时候自动进行这个操作，但是其它处于空闲状态的数据需要在后台进行迁移。这个操作需要在版本 8 发行前完成，因为版本 8 将不再支持旧的位置。使用 'nova-manage migrate-rhos-6-pci-device-data' 来进行这个操作。
请注意，这只适用于使用 Compute 的 PCI pass-through 功能的用户。

在以前的版本中，当试图在一个由 staypuft/openstack-foreman-installer 配置的 nova-network 计算节点上启动实例时，会出现一个错误。这是因为在安装程序（installer）中缺少了 conntrack-tools 软件包。

现在，在 openstack-nova.spec 中添加了相应的内容来为 nova-network 的服务安装 conntrack-tools 软件包。Nova-network 现在可以配置网络，从而避免了以上错误的产生。

在以前的版本中，当试图在一个由 staypuft/openstack-foreman-installer 配置的 nova-network 计算节点上启动实例时，会出现一个错误。这是因为在安装程序（installer）中缺少了 conntrack-tools 软件包。

现在，在 openstack-nova.spec 中添加了相应的内容来为 nova-network 的服务安装 conntrack-tools 软件包。Nova-network 现在可以配置网络，从而避免了以上错误的产生。

在以前的版本中，当到 Cinder iSCSI 卷的主路径失效时，这个卷将无法被附加到实例上，即使 Compute 和 Block Storage 后端的多路径功能已经被启动。这意味着，云系统用户无法附加一个卷，或无法从一个卷引导服务器。

在这个版本中，主机有一个单独的配置选择，它可以被用来指定块设备的流量是否由一个独立的网络处理，从而可以实现通过从路径（secondary path）附加卷。

在以前的版本中，当到 Cinder iSCSI 卷的主路径失效时，这个卷将无法被附加到实例上，即使 Compute 和 Block Storage 后端的多路径功能已经被启动。这意味着，云系统用户无法附加一个卷，或无法从一个卷引导服务器。

在这个版本中，主机有一个单独的配置选择，它可以被用来指定块设备的流量是否由一个独立的网络处理，从而可以实现通过从路径（secondary path）附加卷。

当部署一个使用 IPv6 的 OpenStack 环境时，因为 websocketproxy 无法验证原始的头数据（header），VNC 控制台会加载失败并产生一个异常 - "handler exception: Origin header does not match this host.”。

在这个版本中，websocketproxy 代码已被更新来处理 IPv6。现在，当所有服务都被配置为使用 IPv6 时，用户可以成功地连接到 VNC 控制台。

当部署一个使用 IPv6 的 OpenStack 环境时，因为 websocketproxy 无法验证原始的头数据（header），VNC 控制台会加载失败并产生一个异常 - "handler exception: Origin header does not match this host.”。

在这个版本中，websocketproxy 代码已被更新来处理 IPv6。现在，当所有服务都被配置为使用 IPv6 时，用户可以成功地连接到 VNC 控制台。

在以前的版本中，因为更新端口绑定失败，会导致在使用 neutron 时，撤离（evacuate）nova 中的虚拟机操作失败。这个问题同样会出现在使用 FloatingIP 的 nova-network 中。因此，由于创建所需的虚拟接口失败，会导致虚拟机无法被撤离。

在这个版本中，nova 可以在以上所提到的两种网络设置中正确配置虚拟机。现在，用户可以成功进行虚拟机撤离操作。

在以前的版本中，因为更新端口绑定失败，会导致在使用 neutron 时，撤离（evacuate）nova 中的虚拟机操作失败。这个问题同样会出现在使用 FloatingIP 的 nova-network 中。因此，由于创建所需的虚拟接口失败，会导致虚拟机无法被撤离。

在这个版本中，nova 可以在以上所提到的两种网络设置中正确配置虚拟机。现在，用户可以成功进行虚拟机撤离操作。

在以前的版本中，libvirt 驱动使用 libguestfs 进行特定的虚拟机检查和修改任务。但是，libguestfs 是一个外部的程序库，它无法被 eventlet 的 monkey patch 更新。因此，在进行 libguestfs API 调用时，eventlet greenthreads 没有运行，从而导致 nova-compute 服务在调用的整个过程中都处于无响应的状态。在系统安装或更新后，对 libguestfs 的初始调用会持续几秒钟，在这个期间，openstack-nova-compute 将无法提供正常的服务。

在这个版本中，对 libguestfs 的调用会被放入到一个独立的、非 Eventlet 的 threadpool 中。这些调用会异步执行，从而不会影响到 openstack-nova-compute 的运行。

在以前的版本中，libvirt 驱动使用 libguestfs 进行特定的虚拟机检查和修改任务。但是，libguestfs 是一个外部的程序库，它无法被 eventlet 的 monkey patch 更新。因此，在进行 libguestfs API 调用时，eventlet greenthreads 没有运行，从而导致 nova-compute 服务在调用的整个过程中都处于无响应的状态。在系统安装或更新后，对 libguestfs 的初始调用会持续几秒钟，在这个期间，openstack-nova-compute 将无法提供正常的服务。

在这个版本中，对 libguestfs 的调用会被放入到一个独立的、非 Eventlet 的 threadpool 中。这些调用会异步执行，从而不会影响到 openstack-nova-compute 的运行。

在以前的版本中使用了不正确的数据版本，从而造成 PCI 设备数据模式以不正确的格式发送。这就使得当有任何 PCI-passthrough 设备处于白名单（whitelist）中时，openstack-nova-compute 服务无法启动。

在这个版本中，使用了正确的数据版本，从而允许 openstack-nova-compute 启动并注册白名单中的 PCI 设备。

在以前的版本中使用了不正确的数据版本，从而造成 PCI 设备数据模式以不正确的格式发送。这就使得当有任何 PCI-passthrough 设备处于白名单（whitelist）中时，openstack-nova-compute 服务无法启动。

在这个版本中，使用了正确的数据版本，从而允许 openstack-nova-compute 启动并注册白名单中的 PCI 设备。

这个功能增加了 Packstack 对 IPv6 的支持，Packstack 可以在网络相关的参数中（如 CONFIG_CONTROLLER_HOST、CONFIG_COMPUTE_HOSTS 和 CONFIG_NETWORK_HOSTS）使用 IPv6 地址。

这个功能增加了 Packstack 对 IPv6 的支持，Packstack 可以在网络相关的参数中（如 CONFIG_CONTROLLER_HOST、CONFIG_COMPUTE_HOSTS 和 CONFIG_NETWORK_HOSTS）使用 IPv6 地址。

在以前的版本中，puppet-neutron 不允许自定义 neutron 的 dhcp_domain 设置。因此，undercloud DHCP 会向 overcloud 节点提供无效的域后缀。在这个版本中，可以对 neutron dhcp_domain 进行设置，默认是一个空的后缀。

在以前的版本中，puppet-neutron 不允许自定义 neutron 的 dhcp_domain 设置。因此，undercloud DHCP 会向 overcloud 节点提供无效的域后缀。在这个版本中，可以对 neutron dhcp_domain 进行设置，默认是一个空的后缀。

在以前的版本中，Telemetry 服务的 HAProxy 配置使用不正确的检查（HAProxy 配置没有有效的检查，并错误地使用 SSL 检查而不是 TCP 检查），这会导致 Telemetry 服务在 HA 部署中失败。

在这个版本中，修正了检查错误，确保 Telemetry 服务可以在 HA 部署中被正确地平衡，并启动。

在以前的版本中，Telemetry 服务的 HAProxy 配置使用不正确的检查（HAProxy 配置没有有效的检查，并错误地使用 SSL 检查而不是 TCP 检查），这会导致 Telemetry 服务在 HA 部署中失败。

在这个版本中，修正了检查错误，确保 Telemetry 服务可以在 HA 部署中被正确地平衡，并启动。

当在 undercloud 中部署启用了 SSL 的 Bare Metal 和 Telemetry 服务时，Director 会使用错误的 HAProxy 设置。这会导致一些节点无法进行注册。

为了解决这个问题，可以在安装 undercloud 后，在 /etc/haproxy/haproxy.cfg 文件的 Bare Metal 和 Telemetry 项中注释掉 'option ssl-hello-chk'。

当在 undercloud 中部署启用了 SSL 的 Bare Metal 和 Telemetry 服务时，Director 会使用错误的 HAProxy 设置。这会导致一些节点无法进行注册。

为了解决这个问题，可以在安装 undercloud 后，在 /etc/haproxy/haproxy.cfg 文件的 Bare Metal 和 Telemetry 项中注释掉 'option ssl-hello-chk'。

现在，在 HDP 2.0.6 插件中添加了 namenode 高可用性作为一个支持的选项。
用户可以通过传递一个带有法定数量的 zookeeper 服务器和 journalnodes，以及最少 2 个 namenode 的集群，来表明在 HA 模式中需要产生一个集群。例如：
"cluster_configs": {
   "HDFSHA": {
      "hdfs.nnha": true
   }
}

现在，在 HDP 2.0.6 插件中添加了 namenode 高可用性作为一个支持的选项。
用户可以通过传递一个带有法定数量的 zookeeper 服务器和 journalnodes，以及最少 2 个 namenode 的集群，来表明在 HA 模式中需要产生一个集群。例如：
"cluster_configs": {
   "HDFSHA": {
      "hdfs.nnha": true
   }
}

在这个版本中，Sahara API 现在可以完全支持 HTTPS 协议。

在这个版本中，Sahara API 现在可以完全支持 HTTPS 协议。

在这个版本以前，Sahara 的 'distributed' 模式功能是一个 alpha 测试的功能，Red Hat Enterprise Linux OpenStack Platform 没有单独打包或支持 'sahara-api' 和 'sahara-engine' 进程。
在这个版本中，'distributed' 模式功能已被认为是稳定的了，RHEL OpenStack Platform 为 'sahara-api' 和 'sahara-engine' 服务提供了 systemd 单元文件。
作为结果，用户可以使用分布模式运行带有独立 API 和引擎节点集群的 Sahara。

在这个版本以前，Sahara 的 'distributed' 模式功能是一个 alpha 测试的功能，Red Hat Enterprise Linux OpenStack Platform 没有单独打包或支持 'sahara-api' 和 'sahara-engine' 进程。
在这个版本中，'distributed' 模式功能已被认为是稳定的了，RHEL OpenStack Platform 为 'sahara-api' 和 'sahara-engine' 服务提供了 systemd 单元文件。
作为结果，用户可以使用分布模式运行带有独立 API 和引擎节点集群的 Sahara。

现在，通过使用与 API 项的名称相匹配的 GET 参数，可以根据任何项名对 Sahara 对象进行查询。

现在，通过使用与 API 项的名称相匹配的 GET 参数，可以根据任何项名对 Sahara 对象进行查询。

在这个版本中，增加了一个 CLI，使用它可以为每个主要的插件配置默认的集群模板。部署默认模板可以方便最终用户对 Sahara 的使用。
作为结果，管理员现在可以添加共享的默认模板，并可以被用户直接使用。

在这个版本中，增加了一个 CLI，使用它可以为每个主要的插件配置默认的集群模板。部署默认模板可以方便最终用户对 Sahara 的使用。
作为结果，管理员现在可以添加共享的默认模板，并可以被用户直接使用。

Sahara 的集成测试被重新设计来使用简单的、基于 YAML 的配置来定义 "scenarios"。

Sahara 的集成测试被重新设计来使用简单的、基于 YAML 的配置来定义 "scenarios"。

以前，任何 Linux 发行版本中的 Cloudera 都没有打包 cm_api 程序库。因为以前的 CDH 插件都需要依赖这个软件包，所以在以前的版本中，CDH 无法作为默认的插件被启用。现在，cm_api 程序库的一个子集被添加到 Sahara 的代码中，CDH 可以正常工作并被默认启用。

以前，任何 Linux 发行版本中的 Cloudera 都没有打包 cm_api 程序库。因为以前的 CDH 插件都需要依赖这个软件包，所以在以前的版本中，CDH 无法作为默认的插件被启用。现在，cm_api 程序库的一个子集被添加到 Sahara 的代码中，CDH 可以正常工作并被默认启用。

在以前的版本中，集群创建中的一些进程会无限期地进行轮询。现在，在集群创建和处理过程中增加了超时设置，当集群操作进行的时间超过了正常时间，用户会看到相关的错误信息。

在以前的版本中，集群创建中的一些进程会无限期地进行轮询。现在，在集群创建和处理过程中增加了超时设置，当集群操作进行的时间超过了正常时间，用户会看到相关的错误信息。

一个新端点（endpoint）被添加到 Sahara 来允许根据 Sahara 所支持的每个插件和版本的任务类型进行查询。这些信息可以用于 UI 的显示和过滤，以及 CLI 和 REST API 用户。

一个新端点（endpoint）被添加到 Sahara 来允许根据 Sahara 所支持的每个插件和版本的任务类型进行查询。这些信息可以用于 UI 的显示和过滤，以及 CLI 和 REST API 用户。

在这个版本以前，Sahara 的 "distributed" 模式功能是一个 alpha 测试的功能，Red Hat Enterprise Linux OpenStack Platform 没有单独打包或支持 sahara-api 和 sahara-engine 进程。在这个版本中，'distributed' 模式功能已被认为是稳定的了，RHEL OpenStack Platform 为 sahara-api 和 sahara-engine 服务提供了 systemd 单元文件。现在，用户可以使用分布模式运行带有独立 API 和引擎节点集群的 Sahara。

在这个版本以前，Sahara 的 "distributed" 模式功能是一个 alpha 测试的功能，Red Hat Enterprise Linux OpenStack Platform 没有单独打包或支持 sahara-api 和 sahara-engine 进程。在这个版本中，'distributed' 模式功能已被认为是稳定的了，RHEL OpenStack Platform 为 sahara-api 和 sahara-engine 服务提供了 systemd 单元文件。现在，用户可以使用分布模式运行带有独立 API 和引擎节点集群的 Sahara。

在以前的版本中，虽然插件和 araha-image-elements 软件包都不会使用 Extra Packages for Enterprise Linux (EPEL) 仓库，但 HDP 插件仍然会在集群产生的过程中安装这个仓库。这就在 HDP 集群创建中产生了一个可能造成潜在错误的、不需要的步骤，对这些集群进行更新时可能会使用不被支持的软件包。现在，这个仓库不再会被 HDP 插件安装。

在以前的版本中，虽然插件和 araha-image-elements 软件包都不会使用 Extra Packages for Enterprise Linux (EPEL) 仓库，但 HDP 插件仍然会在集群产生的过程中安装这个仓库。这就在 HDP 集群创建中产生了一个可能造成潜在错误的、不需要的步骤，对这些集群进行更新时可能会使用不被支持的软件包。现在，这个仓库不再会被 HDP 插件安装。

现在增加了一个 logrotate 文件来强制执行当前 Red Hat OpenStack 标准中对日志文件大小的限制，使用它可以防止日志文件在被重复使用前变得过大。

现在增加了一个 logrotate 文件来强制执行当前 Red Hat OpenStack 标准中对日志文件大小的限制，使用它可以防止日志文件在被重复使用前变得过大。

在以前的版本中，当 HDP 的 NameNode HA 可以正常工作后，Sahara 仍然会为所有任务把 Oozie 指向一个单一的 NameNode IP。
因此，Oozie 和 Sahara 的 EDP 只在一个特定节点活跃时（处于 A/P HA 模式）才可以正常工作。
在这个版本中，Oozie 会被重新指向一个名称解析服务器而不是一个 amenode，从而解决了以上问题。
现在，无论哪个 NameNode 是活跃的，Oozie 和 EDP 的任务都可以正常工作。

在以前的版本中，当 HDP 的 NameNode HA 可以正常工作后，Sahara 仍然会为所有任务把 Oozie 指向一个单一的 NameNode IP。
因此，Oozie 和 Sahara 的 EDP 只在一个特定节点活跃时（处于 A/P HA 模式）才可以正常工作。
在这个版本中，Oozie 会被重新指向一个名称解析服务器而不是一个 amenode，从而解决了以上问题。
现在，无论哪个 NameNode 是活跃的，Oozie 和 EDP 的任务都可以正常工作。

在以前的版本中，Neutron 会被绑定到不允许使用的端口上，所以 SELinux 会使 Neutron 无法工作。在这个版本中，Neutron 可以被连接到非保留的端口上进行运行，而不再会出现问题。

在以前的版本中，Neutron 会被绑定到不允许使用的端口上，所以 SELinux 会使 Neutron 无法工作。在这个版本中，Neutron 可以被连接到非保留的端口上进行运行，而不再会出现问题。

在以前的版本中，Neutron VPN 代理使用错误的上下文（context）启动，SELinux 会禁止 VPN 代理运行。在这个版本中，Neutron VPN 代理具有正确的上下文，它可以在 enforcing 模式中稳定运行。

在以前的版本中，Neutron VPN 代理使用错误的上下文（context）启动，SELinux 会禁止 VPN 代理运行。在这个版本中，Neutron VPN 代理具有正确的上下文，它可以在 enforcing 模式中稳定运行。

现在，通过在 OpenStack dashboard 用户界面中为实例选择一个新的 flavor，可以对 OpenStack Trove 实例的大小进行调整。

现在，通过在 OpenStack dashboard 用户界面中为实例选择一个新的 flavor，可以对 OpenStack Trove 实例的大小进行调整。

dashboard 中的 'API Access' 页（'Project > Compute > Access & Security > API Access'）现在可以提供更详细的、与用户凭证相关的信息。要查看这些信息，点 'View Credentials'。一个弹出界面会显示用户名、项目名、项目 ID、验证 URL、S3 URL、EC2 URL、EC2 访问和密钥。

dashboard 中的 'API Access' 页（'Project > Compute > Access & Security > API Access'）现在可以提供更详细的、与用户凭证相关的信息。要查看这些信息，点 'View Credentials'。一个弹出界面会显示用户名、项目名、项目 ID、验证 URL、S3 URL、EC2 URL、EC2 访问和密钥。

在 OpenStack dashboard 的  'Volumes' 标签页中添加了创建 Block Storage (cinder) 卷转移的选项。卷转移是指把所有权从一个项目移到另一个项目。一个赠与者（donor）创建一个卷转移，并获得结果转移 ID 和验证密钥，然后把这些信息通过电子邮件或短信传递给接受者（recipient）。接受者接受这个转移，提供转移 ID 和验证密钥。现在，所有者权限就从赠与者转移给接受者，相应的卷将不再对赠与者可见。

请注意，进行卷转移的 Block Storage API 有以下限制，它们会影响到 UI 的设计：
1. 当创建一个卷转移时，您不能指定谁会成为接受者，任何具有转移 ID 和验证密钥的人都可以声明成为接受者。因此，dashboard UI 不会提示输入接受者。
2. 当前的卷转移只对赠与者可见，其它项目中的用户无法看到这些转移。因为当前的转移不可见，所以 UI 没有包括一个项目表来查看和接受卷转移。而转移信息会被添加到卷的详情中，这对赠与者可见，卷的状态明确反映了一个转移已经被创建。另外，UI 同样无法为接受者显示一个包括可以接受的转移下拉列表。
3. 赠与者只有在响应创建转移的阶段可以看到验证密钥，在创建完成后，即使是赠与者也无法恢复验证密钥。因此，赠与者必须获得转移 ID 和验证密钥信息来发送给接受者。在转移被创建后，一个包括了这些信息的额外表格会被马上创建，赠与者从中获得相关信息。

在 OpenStack dashboard 的  'Volumes' 标签页中添加了创建 Block Storage (cinder) 卷转移的选项。卷转移是指把所有权从一个项目移到另一个项目。一个赠与者（donor）创建一个卷转移，并获得结果转移 ID 和验证密钥，然后把这些信息通过电子邮件或短信传递给接受者（recipient）。接受者接受这个转移，提供转移 ID 和验证密钥。现在，所有者权限就从赠与者转移给接受者，相应的卷将不再对赠与者可见。

请注意，进行卷转移的 Block Storage API 有以下限制，它们会影响到 UI 的设计：
1. 当创建一个卷转移时，您不能指定谁会成为接受者，任何具有转移 ID 和验证密钥的人都可以声明成为接受者。因此，dashboard UI 不会提示输入接受者。
2. 当前的卷转移只对赠与者可见，其它项目中的用户无法看到这些转移。因为当前的转移不可见，所以 UI 没有包括一个项目表来查看和接受卷转移。而转移信息会被添加到卷的详情中，这对赠与者可见，卷的状态明确反映了一个转移已经被创建。另外，UI 同样无法为接受者显示一个包括可以接受的转移下拉列表。
3. 赠与者只有在响应创建转移的阶段可以看到验证密钥，在创建完成后，即使是赠与者也无法恢复验证密钥。因此，赠与者必须获得转移 ID 和验证密钥信息来发送给接受者。在转移被创建后，一个包括了这些信息的额外表格会被马上创建，赠与者从中获得相关信息。

OpenStack Dashboard 现在使用 Block Storage (cinder) 版本 2 作为它的首选版本。
当请求 Block Storage 客户端时，如果没有特别指定，会使用 cinder 版本 2。

OpenStack Dashboard 现在使用 Block Storage (cinder) 版本 2 作为它的首选版本。
当请求 Block Storage 客户端时，如果没有特别指定，会使用 cinder 版本 2。

现在，您可以使用 dashboard 来查看、导入和关联可以被不同资源（images、artifacts、volumes、flavors、aggregates）使用的元数据定义。

现在，您可以使用 dashboard 来查看、导入和关联可以被不同资源（images、artifacts、volumes、flavors、aggregates）使用的元数据定义。

在 OpenStack Dashboard 中，实例的详情页现在可以显示主机节点。这些信息可以帮助用户进行系统诊断。

在 OpenStack Dashboard 中，实例的详情页现在可以显示主机节点。这些信息可以帮助用户进行系统诊断。

在这个版本中，为 OpenStack Dashboard 添加了部分的 Domain Admins 支持。另外，当使用 Identity Service (keystone) 版本 3 时，一个新创建的用户不需要指定主项目。

在这个版本中，为 OpenStack Dashboard 添加了部分的 Domain Admins 支持。另外，当使用 Identity Service (keystone) 版本 3 时，一个新创建的用户不需要指定主项目。

现在，您可以通过 dashboard 启用和禁用计算节点（在 'Admin > Hypervisors > Compute Host' 界面中点计算节点的 'Actions' 列）。

禁用一个计算主机后，调度器（scheduler）将无法使用这个主机启动实例。

现在，您可以通过 dashboard 启用和禁用计算节点（在 'Admin > Hypervisors > Compute Host' 界面中点计算节点的 'Actions' 列）。

禁用一个计算主机后，调度器（scheduler）将无法使用这个主机启动实例。

OpenStack dashboard 的 'Volumes' 标签页中添加了 'Manage/Unmanage' 选项。'Manage' 会获取一个已存在的、在 OpenStack 外创建的卷，使它可以被使用。'Unmanage' 会使卷在 OpenStack 中不可见，但并不删除实际的卷。

OpenStack dashboard 的 'Volumes' 标签页中添加了 'Manage/Unmanage' 选项。'Manage' 会获取一个已存在的、在 OpenStack 外创建的卷，使它可以被使用。'Unmanage' 会使卷在 OpenStack 中不可见，但并不删除实际的卷。

dashboard 中的 OpenStack Orchestration 服务 (heat) 的用户接口选项已被改进。例如，用户现在可以检查、挂起、恢复和预览堆栈。

dashboard 中的 OpenStack Orchestration 服务 (heat) 的用户接口选项已被改进。例如，用户现在可以检查、挂起、恢复和预览堆栈。

现在，可以对显示的 Data Processing 服务的结果数据进行过滤，从而可以使用户只看相关的数据。

现在，可以对显示的 Data Processing 服务的结果数据进行过滤，从而可以使用户只看相关的数据。

现在，可以通过 dashboard 把一个卷标记为 'Bootable'。

现在，可以通过 dashboard 把一个卷标记为 'Bootable'。

现在，OpenStack dashboard 可以使用自定义的主题。一个新设置（'CUSTOM_THEME_PATH'）被添加到 /etc/openstack_dashboard/local_settings 文件中。这个主题文件夹包括一个 _variables.scss 文件和一个 _styles.scss 文件。_variables.scss 文件包括了所有可以被用来设计图形用户界面的 bootstrap 变量以及和 Horizon 相关的变量；_styles.scss 文件包括了额外的图形界面显示分隔的信息。

现在，OpenStack dashboard 可以使用自定义的主题。一个新设置（'CUSTOM_THEME_PATH'）被添加到 /etc/openstack_dashboard/local_settings 文件中。这个主题文件夹包括一个 _variables.scss 文件和一个 _styles.scss 文件。_variables.scss 文件包括了所有可以被用来设计图形用户界面的 bootstrap 变量以及和 Horizon 相关的变量；_styles.scss 文件包括了额外的图形界面显示分隔的信息。

现在，SRIOV 可以在 OpenStack dashboard 中进行配置。在 'Port Details' 标签页中包括了更多的信息；在进行端口创建和更新时，可以选择端口类型。

现在，SRIOV 可以在 OpenStack dashboard 中进行配置。在 'Port Details' 标签页中包括了更多的信息；在进行端口创建和更新时，可以选择端口类型。

现在，可以在 OpenStack Dashboard (horizon) 中查看加密卷的加密元数据。一个用来显示加密元数据的功能被添加，用户可以通过点“加密”栏中的 "Yes" 来查看加密元数据。

现在，可以在 OpenStack Dashboard (horizon) 中查看加密卷的加密元数据。一个用来显示加密元数据的功能被添加，用户可以通过点“加密”栏中的 "Yes" 来查看加密元数据。

当通过 dashboard 上传一个镜像时，您可以选择 OVA 作为它的格式。在以前的版本中，无法选择 OVA。

当通过 dashboard 上传一个镜像时，您可以选择 OVA 作为它的格式。在以前的版本中，无法选择 OVA。

现在，dashboard 提供了向导程序来创建和配置 OpenStack Data Processing 所需的组件。这些向导程序可以帮助用户进行集群创建和任务执行操作。要使用这些向导程序，点 'Project > Data Processing > Guides'。

现在，dashboard 提供了向导程序来创建和配置 OpenStack Data Processing 所需的组件。这些向导程序可以帮助用户进行集群创建和任务执行操作。要使用这些向导程序，点 'Project > Data Processing > Guides'。

现在，在 OpenStack Dashboard  中添加了 ceilometer IPMI 计费器（meter）
6 个 ipmi 计费器被从 ceilometer 中导出，'list_ipmi' 和 '_get_ipmi_meters_info' 可以被用来获取计费器的数据。

现在，在 OpenStack Dashboard  中添加了 ceilometer IPMI 计费器（meter）
6 个 ipmi 计费器被从 ceilometer 中导出，'list_ipmi' 和 '_get_ipmi_meters_info' 可以被用来获取计费器的数据。

现在，可以通过 dashboard 查看 Orchestration 服务主机的详情（点 'Admin > System > System Information > Orchestration Services'）。这个页只在 Orchestration 服务已被部署的情况下才可见。

现在，可以通过 dashboard 查看 Orchestration 服务主机的详情（点 'Admin > System > System Information > Orchestration Services'）。这个页只在 Orchestration 服务已被部署的情况下才可见。

现在，基于 Ceph 的 ephemeral 磁盘快照可以使用 RBD 快照和克隆。在这个版本中，数据会在 Ceph 服务器中处理，而不需要在不同节点中进行传递，这可以提高 Ceph 快照的性能。

现在，基于 Ceph 的 ephemeral 磁盘快照可以使用 RBD 快照和克隆。在这个版本中，数据会在 Ceph 服务器中处理，而不需要在不同节点中进行传递，这可以提高 Ceph 快照的性能。

以前，当节点处于`locked`状态时，OpenStack Bare Metal Provisioning (Ironic) 中的特定操作会失败。
在这个版本中，为 Ironic 客户端添加了一个 `retry` 功能。现在，特定的操作会需要较长时间完成，但不会因为 `node locked` 造成运行失败。

以前，当节点处于`locked`状态时，OpenStack Bare Metal Provisioning (Ironic) 中的特定操作会失败。
在这个版本中，为 Ironic 客户端添加了一个 `retry` 功能。现在，特定的操作会需要较长时间完成，但不会因为 `node locked` 造成运行失败。

现在，python-openstackclient 软件包和上游社区的版本 1.0.3 代码进行了同步。它增强并改进了对 Identity service 服务 v3 API 的支持。

现在，python-openstackclient 软件包和上游社区的版本 1.0.3 代码进行了同步。它增强并改进了对 Identity service 服务 v3 API 的支持。

以前，在一个带有大量扇区的虚拟磁盘中，扇区数量会在某些情况下被错误处理，造成转换 QEMU 镜像失败（"invalid argument" 错误）。在这个版本中，这个错误已被解决。

以前，在一个带有大量扇区的虚拟磁盘中，扇区数量会在某些情况下被错误处理，造成转换 QEMU 镜像失败（"invalid argument" 错误）。在这个版本中，这个错误已被解决。

以前，因为不正确的可移植内存边界，当一个虚拟磁盘具有大量 I/O 负载时，QEMU 仿真器可能会被非正常终止。在这个版本中，QEMU 的线程可以被正确同步，从而解决了以上的问题。

以前，因为不正确的可移植内存边界，当一个虚拟磁盘具有大量 I/O 负载时，QEMU 仿真器可能会被非正常终止。在这个版本中，QEMU 的线程可以被正确同步，从而解决了以上的问题。

这个软件包允许用户创建可以在 RHEL OpenStack Platform 7 中使用的 HDP 2.0.6 和 CDH 5.3.0 镜像。

这个软件包允许用户创建可以在 RHEL OpenStack Platform 7 中使用的 HDP 2.0.6 和 CDH 5.3.0 镜像。

以前，创建 CDH 镜像在某些时候会失败，这是因为镜像创建的 wrapper 脚本在某些系统上为创建 CDH 镜像指定了太小的空间。现在，为创建 CDH 镜像增加了创建空间，镜像可以被成功创建。

以前，创建 CDH 镜像在某些时候会失败，这是因为镜像创建的 wrapper 脚本在某些系统上为创建 CDH 镜像指定了太小的空间。现在，为创建 CDH 镜像增加了创建空间，镜像可以被成功创建。

当在 Pacemaker 节点上使用 sosreport 工具程序时，MariaDB MySQL 服务器的一个日志文件不会被正确收集。在这个版本中，相应的代码已被修正，日志文件可以被正确收集。

当在 Pacemaker 节点上使用 sosreport 工具程序时，MariaDB MySQL 服务器的一个日志文件不会被正确收集。在这个版本中，相应的代码已被修正，日志文件可以被正确收集。

以前，sosreport 工具程序的多个 OpenStack 插件会不正确地以明文形式收集密码，使用 sosreport 所产生的压缩文件会包括未加密的可读密码。在这个版本中，为 sosreport OpenStack 插件的所有密码增加了混淆（obfuscation）处理，sosreport tarball 中的密码将不再以明文的形式出现。

以前，sosreport 工具程序的多个 OpenStack 插件会不正确地以明文形式收集密码，使用 sosreport 所产生的压缩文件会包括未加密的可读密码。在这个版本中，为 sosreport OpenStack 插件的所有密码增加了混淆（obfuscation）处理，sosreport tarball 中的密码将不再以明文的形式出现。