距离我们上次的亮点文章已经有一段时间了，所以这次的文章包含了很多更新。
新的发布标签：cycle-trailing
这是添加到描述发布模型的标签集合中的一个新标签。该标签旨在允许特定项目在 OpenStack 发布完成后进行发布。对于需要等待“最终”OpenStack 发布才能发布的项目来说，这个标签很有用。例如，Kolla、TripleO、Ansible 等项目。
重组跨项目工作协调
跨项目团队是审查跨项目规范的参考团队。 此决议 授予跨项目团队对跨项目规范的批准权，从而能够合并此类规范，而无需技术委员会的干预。这是朝着技术委员会使命迈出的重要一步，即尽可能地使社区实现自主化。此决议将 openstack-specs 的审查者识别为一个团队。
项目添加和移除
– 添加 OpenStack Salt：该项目带来了用于安装和运行 OpenStack 云部署的 SaltStack 公式。该项目的主要重点是以简单、可扩展和可预测的方式设置开发、测试和生产 OpenStack 部署。
– 添加 OpenStack Vitrage：该项目旨在组织、分析和可视化 OpenStack 警报和事件，从而洞察问题的根本原因，并在问题直接检测到之前推断其存在。
– 添加 OpenStack Watcher：Watcher 的目标是为基于 OpenStack 的多租户云提供灵活且可扩展的资源优化服务。
– 移除 OpenStack Cue：Cue 项目团队的活动量已降至低于官方 OpenStack 项目团队的预期水平。因此，它已被从官方项目列表中移除。
关于 DefCore 验证测试位置的建议
一项新决议 已被合并，其中建议 DefCore 团队将 Tempest 的仓库作为验证测试的中央仓库。在峰会上，讨论了两种不同的方案作为可能的建议
- 单独使用 Tempest git 仓库中的测试。
- 通过允许项目使用 Tempest 的插件功能在其树中托管测试，来扩展 Tempest 测试。
通过建议使用 Tempest 仓库，社区将倾向于集中这些测试，这将改善 DefCore 相关事项的协作，并提高 API 验证所用测试的一致性。
任务声明更新
一方面，Magnum 在奥斯汀峰会上讨论后 缩小了其任务声明。团队决定 Magnum 应该专注于管理容器编排引擎 (COE)，而不是管理容器生命周期。另一方面，Kuryr 已经 扩展了其任务 声明，也包括容器的存储抽象管理。
扩展 OpenStack 项目中的技术选择
表面上看，这个请求很简单。“我们能在 OpenStack 中使用 golang 吗？” 技术委员会在 此治理补丁审查 中被问到。
这是一个是或否的问题。它为我们设定了非黑即白的定义，尽管无论答案如何，其连锁反应都是很多的。
是意味着项目之间的专业知识共享减少以及一定的隔离。我们希望某些技术决策是在我们社区和 OpenStack 方式的最佳利益下做出的。我们将信任项目制定一个计划，以应对受技术选择影响的所有操作员和用户。是意味着信任我们所有的项目（目前超过五十五个）不要浪费时间追逐最新的技术或进行无用的重写，并相信技术选择的自由比共享共同的知识和专业知识更重要。对于一些人来说，这意味着我们正在作为技术人员进化和创新。
这里的否决意味着，如果你想用另一种语言开发，你应该在 OpenStack 之外建立你的新语言社区。即使投了否决票，项目仍然可以使用我们的开发基础设施，例如邮件列表、Gerrit、Zuul 等。对语言选择的否决意味着团队的交付成果只是在技术委员会治理监督之外，并且不由我们的跨项目团队（例如发布、文档、质量）处理。为了你的用户群的利益，你应该确保所有技术影响，就像是票一样，但你的团队不需要在技术委员会的监督下工作。
关于从否到是的可能性呢？这是否意味着我们希望你留在 OpenStack 社区，但请插件那些在构建过程中没有考虑整个社区的部分？
我们讨论了额外的灰色区域答案。这是范围
- 是，没有限制。
- 是，但受到我们治理中概述的限制。
- 否，请记住，使用其他语言编写的外部依赖项是完全可以的。
- 否，不遵守我们技术标准的项目不会利用 OpenStack 提供的共享资源，因此它们可以在 OpenStack 之外工作。
我们驳回了是和否的极端描述。本周我们继续讨论内部是和内部否的描述，但没有一个选项真正令人满意。经过大量的讨论，我们最终选择了否定的答案，放弃了补丁，同时寻求在限制范围内实现是的输入。
基本上，我们的答案是关于关注我们共同拥有的东西，定义我们的东西。它与定义“OpenStack 项目”为由一个连贯的社区使用 OpenStack 方式开发的项目的开放式方法一致。这是关于分享更多东西。我们容忍甚至拥抱必要的差异，但这并不意味着该项目必须生活在帐篷里。它可以是友好的邻居，而不是进入并导致帐篷分成更小的子帐篷。
发表评论