[ English | 日本語 | Deutsch | Indonesia ]
使用Roadmap¶
好消息：OpenStack 在提供有关即将发布的信息方面具有前所未有的透明度。坏消息：每个发布周期进展非常迅速。本附录的目的是突出显示一些有用的跟踪页面，并对下一个发布周期以及更长远未来的内容做出明智的猜测。
OpenStack 遵循六个月的发布周期，通常每年四月/五月和十月/十一月发布。在每个周期的开始，社区会在一个地点举行项目团队会议 (PTG)。在 PTG 上，讨论、确定优先级并计划即将发布的特性。下图显示了一个示例发布周期，其中包含显示里程碑发布、代码冻结和字符串冻结日期的日期，以及峰会发生时间的示例。里程碑是周期内的中间发布，可作为软件包下载和测试。代码冻结是指停止向发布中添加新特性。字符串冻结是指停止更改源代码中的任何字符串。
可用的信息¶
有几个很好的信息来源可供您跟踪 OpenStack 开发需求。
影响Roadmap¶
OpenStack 真正欢迎您的想法（和贡献），并高度重视来自软件实际用户的反馈。通过了解驱动功能开发的过程，您可以参与其中，并可能获得您想要的功能。
功能请求通常从 Etherpad（一种协作编辑工具）开始，该工具用于在特定于该功能的的设计峰会期间记录协调笔记。然后，这会导致在 Launchpad 网站上为特定项目创建蓝图，用于更正式地描述该功能。项目团队成员批准蓝图，然后可以开始开发。
因此，获得您的功能请求考虑的最快方法是在 Etherpad 中写下您的想法，并向 PTG 提出会议建议。如果 PTG 已经通过，您也可以直接创建蓝图。阅读这篇 关于如何使用蓝图的博客文章，作者是开发实习生 Victoria Martínez。
正在开发的下一个版本的Roadmap 可以在 Releases 上查看。
要确定未来版本中可能包含的功能，或查看以前实现的功能，请查看现有的蓝图，例如 OpenStack Compute (nova) 蓝图、OpenStack Identity (keystone) 蓝图和发布说明。
除了直接到蓝图的途径外，还有另一种非常受人尊敬的机制可以影响开发Roadmap：用户调查。该调查位于 OpenStack 用户调查，允许您提供有关您的部署和需求的详细信息，默认情况下匿名。每个周期，用户委员会都会分析结果并生成报告，包括向技术委员会和项目团队负责人提供具体信息。
需要关注的方面¶
您希望关注 OpenStack 中正在改进的领域。 “观察”每个项目的Roadmap 的最佳方法是查看正在批准用于里程碑发布的工作的蓝图。您还可以从每年两次 OpenStack 峰会后的 PTL 网络研讨会中学习。
驱动程序质量改进¶
Block Storage、Compute 和 Networking 中的驱动程序和插件都进行了重大的质量改进。特别是，需要专有或硬件产品的 Compute 和 Networking 驱动程序的开发人员现在需要在开发过程中提供自动化的外部测试系统。
更轻松的升级¶
OpenStack 启动以来最常要求的特性之一（对于 Object Storage 以外的组件，后者往往“即刻可用”）：更轻松的升级。在所有最新版本中，内部消息通信都已版本化，这意味着服务理论上可以回退到向后兼容的行为。这允许您运行某些组件的较新版本，同时保持其他组件的较旧版本。
此外，数据库迁移现在使用 Turbo Hipster 工具进行测试。该工具在真实用户数据库的副本上测试数据库迁移性能。
这些更改促进了第一个适当的 OpenStack 升级指南，位于 升级，并将继续在下一个版本中改进。
弃用 Nova Network¶
随着 OpenStack Networking (neutron) 在 Folsom 版本中提供的完整软件定义网络堆栈的引入，Compute 组件中剩余的初始网络代码的开发工作逐渐减少。虽然许多人仍在生产中使用 nova-network，但长期计划是删除该代码，以支持更灵活和功能齐全的 OpenStack Networking。
在 Havana 版本中尝试弃用 nova-network，但由于缺乏等效功能（例如本指南中提到的 FlatDHCP 多主机高可用模式）、缺乏版本之间的迁移路径、测试不足以及在传统上支持的更简单的用例中简单性，该弃用被中止。尽管已经付出了巨大的努力来解决这些问题，但 nova-network 未在 Juno 版本中被弃用。此外，在一定程度上，对 nova-network 的补丁再次被接受，例如在 Juno 中添加每个网络的设置功能和 SR-IOV 支持。
这给您在设计云时留下了一个重要的决策点。OpenStack Networking 足够健壮，可以用于一些限制（某些场景下的性能问题，仅提供第 3 层系统的基本高可用性），并提供比 nova-network 更多的功能。但是，如果您没有能够从更全面的软件定义网络功能中受益的更复杂的用例，或者对引入的新概念不满意，nova-network 在接下来的 12 个月内可能仍然是一个可行的选择。
同样，如果您拥有现有的云并希望从 nova-network 升级到 OpenStack Networking，您应该可以选择在此期间延迟升级。但是，OpenStack 的每个版本都带来了重大的创新，无论您使用哪种网络方法，最好在每个版本发布后合理的时间范围内开始规划升级。
如前所述，目前无法从 nova-network 干净地迁移到 neutron。我们建议您记住迁移，并在发布适当的迁移路径时考虑该过程。
分布式虚拟路由器¶
OpenStack Networking 的长期抱怨之一是第 3 层组件缺乏高可用性。Juno 版本引入了分布式虚拟路由器 (DVR)，旨在解决此问题。
初步迹象表明，它对于一组基本场景（例如使用 ML2 插件和 Open vSwitch、一个扁平外部网络和 VXLAN 租户网络）可以很好地做到这一点。但是，似乎在使用 VLAN、IPv6、浮动 IP、高南北流量场景和大量计算节点时存在问题。预计这些问题将在下一个版本中得到显着改善，但对特定问题的错误报告非常受欢迎。
用模块化第 2 层插件替换 Open vSwitch 插件¶
模块化第 2 层插件是一个框架，允许 OpenStack Networking 同时利用复杂现实世界数据中心中发现的各种第 2 层网络技术。它当前适用于现有的 Open vSwitch、Linux Bridge 和 Hyper-V L2 代理，旨在替换并弃用与这些 L2 代理相关的单体插件。
新的 API 版本¶
Compute API 的第三个版本在 Havana 和 Icehouse 发布周期中得到了广泛讨论和工作。当前讨论表明，V2 API 将保持许多版本，下一个迭代的 API 将被称为 v2.1，并具有与现有 v2.0 相似的属性，而不是全新的 v3 API。现在是评估所有 API 并提供评论的好时机，因为下一代 API 正在定义中。成立了一个新的工作组专门用于 改进 OpenStack API 并创建设计指南，欢迎您加入。
OpenStack on OpenStack (TripleO)¶
该项目不断改进，您可能会考虑将其用于 Greenfield 部署，但根据最新的用户调查结果，它仍未得到广泛采用。
OpenStack 的数据处理服务 (sahara)¶
一个解决大数据问题的长期要求的答案，一个专门的团队在 Hadoop-as-a-Service 项目上取得了稳步进展。
裸机部署 (ironic)¶
裸机部署受到了广泛赞扬，并且开发仍在继续。Juno 版本将 OpenStack 裸机驱动程序引入了 Compute 项目，目标是在 Kilo 中弃用现有的裸机驱动程序。如果您是裸机驱动程序的当前用户，需要关注的一个蓝图是 弃用裸机驱动程序
数据库即服务 (trove)¶
OpenStack 社区已经开发了一段时间的数据库即服务工具，我们在 Icehouse 中看到了它的第一个集成版本。从发布之日起，它能够以高度可用方式部署数据库服务器，最初仅支持 MySQL。Juno 引入了对 Mongo（包括集群）、PostgreSQL 和 Couchbase 的支持，以及 MySQL 的复制功能。在 Kilo 中，交付了更高级的集群功能，以及与 OpenStack 其他组件（如 Networking）的更好集成。
消息服务 (zaqar)¶
发布了一个提供消息和通知队列的服务。
DNS 服务 (designate)¶
一个长期要求的服务，提供操纵与 OpenStack 资源关联的 DNS 条目的能力，已经获得了一批追随者。 designate 项目也已发布。
调度器改进¶
Compute 和 Block Storage 都依赖调度器来确定虚拟机关或卷的位置。在 Havana 中，Compute 调度器得到了显着改进，而在 Icehouse 中，Block Storage 中的调度器得到了提升。进一步地，一个本周期开始的努力旨在创建一个涵盖两者的整体调度器将最终实现。Kilo 项目下可以找到所做的一些工作 Gantt 项目。
Block Storage 改进¶
Block Storage 被认为是一个稳定的项目，具有广泛的应用和长期质量驱动程序记录。该团队在峰会上讨论了许多工作领域，包括更好的错误报告、自动发现和稀疏配置功能。
朝向 Python SDK¶
虽然许多人成功地使用各种 python-*client 代码作为与 OpenStack 交互的有效 SDK，但一致性和文档可用性却时好时坏。为了解决这个问题，已经开始了一项 改进体验的努力。OpenStack 中的跨项目开发工作历来存在一些问题，例如 统一客户端项目 已经多次失败。但是，SDK 项目的早期迹象令人鼓舞，我们预计将在 Juno 周期中看到成果。
