OpenStack 社区每周简讯（9 月 12 日 – 18 日）

 

2015 年 9 月 18 日

正在运行 OpenStack？ 您有权影响路线图

请在 9 月 25 日之前完成用户调查

Outreachy 导师招募

如果您是全职贡献者，请考虑分享您的时间和知识经验，使我们的社区更加多元化，并有机会结识新的优秀人才。请在 Freenode 的 #OpenStack-opw 频道咨询更多信息。

DefCore 入门指南，OpenStack 的互操作性项目

DefCore 委员会联合主席 Rob Hirschfeld 分享了更多关于 DefCore 的信息，DefCore 定义了功能、代码和必须通过的测试，为标记为 OpenStack 的产品创建最低标准

通往东京之路

之前活动的报告 

  • 本周没有

截止日期和贡献者通知

安全公告和通知 

  • 本周没有

技巧 ‘n 窍门 

即将举行的活动 

开发者列表中的重要信息

PTL 提名已结束，让我们开始选举！

  • 五个项目没有候选人。根据 OpenStack 治理，TC 将任命新的 PTL [1]。
    •   Barbican
    •   MagnetoDB
    •   Magnum
    •   Murano
    •   Security
  • 七个项目将进行选举
    •   Cinder
    •   Glance
    •   Ironic
    •   Keystone
    •   Mistral
    •   Neutron
    •   Oslo   
  •  由于对 UTC 的理解存在混淆，以及如何通过 Gerrit 提交提名，但TC 将与 Magnum、Barbican、Murano、Security 中的候选人合作。 
  • Doug Hellmann 表示 MagnetoDB 将因不活动而被讨论移除。​ [1]

Glance 的优先事项建议

  • 根据在 Ops 中期会议和关于 Glance 问题的邮件线程中的讨论，Doug Hellmann 整理了一份 Glance 团队的优先事项建议清单
    • 关注 DefCore：
      • DefCore 目标：确保所有 OpenStack 部署在 REST 级别上具有互操作性（用户可以为 OpenStack 云编写软件，并在不更改代码的情况下迁移到另一个云）。
      • 提供具有良好文档的 API，其参数不会根据部署选择而更改。
      • Tempest 中的集成测试，直接测试 Glance 的 API，而不仅仅是当前通过 Nova 和 Cinder 进行代理的测试。
      • 一旦合并到 DefCore 中，API 需要在一段时间内保持稳定，并遵循 Nova 和 Cinder 中完全采用 V2 定义的弃用时间表。
    • 在 Nova 中，一些规范未在 Liberty 中实现。双方团队需要共同努力。
    • 在 Cinder 中，工作已经基本完成，但需要审查 API 是否使用正确。
    • 安全审计和错误修复
      • 最近的 18 份安全报告中有 5 份与 Glance 相关 [2]
  • 将镜像上传到 Glance V2 的两种方法
    • 将镜像位 POST 到 Glance API 服务器。
      • 部署不广泛。潜在的 DOS 向量。
    • 任务 API，让 Glance 异步下载它。
      • 部署不广泛。
      • 假设您知道哪些云支持哪些“类型”的任务，以及预期的参数（例如，Glance 文档给出了一个源的 URL，但 Rackspace 给出了 Swift 位置作为源）。

新的建议“默认”网络模型

  • Monty Taylor 讨厌浮动 IP。
    • 观察了 5 个公共云，需要您使用浮动 IP 才能获得出站地址。其他云直接将您连接到公共网络。
    • 有些允许您创建一个私有网络并将虚拟机连接到 它，创建一个带有网关的路由器。
  •  Monty 希望有一种更简单的方法，让虚拟机位于云的面向外部的网络上。用户不应该 学习如何使用浮动 IP 来实现这一点。这应该在公共云中保持一致的行为。Mitaka 将努力解决 Monty 的请求 [3]。这将 适用于“nova boot”并与多个网络一起工作。
    •  如果您有更复杂的网络设置，此规范不适用于您。

 基本功能弃用策略

  • Thierry Carrez 提出了一种标准方法来沟通和执行用户可见的行为和功能移除。
    • 我们现在有一些，但没有写成“要移除一个功能，您需要在 n 个版本中将其标记为已弃用，然后将其移除”。
    • 标记建议 [4]。
  • 我们需要调查现有项目，看看它们的弃用策略是什么。
  • 弃用周期的建议选项
    • 对于功能和能力，n+2；对于配置选项，n+1
    • 对于所有内容，n+1
    • 对于所有内容，n+2
  • Ben Swartzlander 认为此讨论还需要涵盖长期支持 (LTS)。
    • Fungi 认为现在还为时过早。Icehouse 稳定分支在没有足够努力使其正常工作的情况下，存在了 14 个月才被放弃。
  • 一致认为“配置选项和功能必须在至少一个稳定分支和至少 3 个月内标记为已弃用”。

team:danger-not-diverse 标签

  • Josh Harlow 担心大多数项目一开始规模小且不具多样性，并且该标签 [5] 会为这些项目产生负面含义。
  • Thierry 提出重要的是要了解标签的意图，而不是它的名称。
    • 标签系统旨在帮助我们的生态系统通过 提供一些信息来驾驭大帐篷。
    • 信息示例：投资某个项目有多大风险？
      • 有些项目依赖于一家公司，并且可能因 CEO 的决定而在一两天内消失。
  • 因此，Thierry 支持描述团队*极其*脆弱的项目。
  • 因此，大帐篷更具包容性。另一方面，我们需要告知我们的生态系统，有些项目不太成熟。否则，您就是在隐藏这些信息。

[1] – http://lists.openstack.org/pipermail/openstack-dev/2015-September/074837.html 

[2] – https://security.openstack.org/search.html?q=glance&check_keywords=yes&area=default

[3] – https://blueprints.launchpad.net/neutron/+spec/get-me-a-network

[4] – https://review.openstack.org/#/c/207467/

[5] – https://review.openstack.org/#/c/218725/

其他新闻 

OpenStack 反馈

 

当人们说他们部署了完整的、Active:Active、HA OpenStack 时

 

使用 logstash.openstack.org 和单元测试日志来查找阻止 gate 的竞争条件

发表评论

您的电子邮件地址将不会被公开。 必填字段已标记 *