技术委员会亮点 2015 年 10 月 7 日

 

2015 年 10 月 8 日

在峰会预热和发布前的这段繁忙的一周，让我们直接进入主题吧。

本周技术委员会选举

本次技术委员会选举六个月周期内有 19 名候选人 竞选 6 个职位。活跃的技术贡献者 (ATC) 应该会在他们的收件箱中收到一封用于投票的邮件。登录 review.openstack.org，然后转到设置 > 联系信息，找到您首选的电子邮件地址，投票邮件将发送到该地址。请在 2015 年 10 月 9 日 23:59 UTC 之前投票。

峰会上的跨项目会议

请在 10 月 9 日星期五之前将您对跨项目会议的建议添加到此网站：http://odsreg.openstack.org/，点击“Suggest session”（建议会议）。10 月 12 日星期一，技术委员会将审核所有提交的内容，并将它们安排到峰会上的跨项目时间段中。目前大约有 26 个提案，大约有 二十个 40 分钟的时间段。

申请 OpenStack 治理

一个团队的申请引发了关于项目是否应该立即申请技术委员会，或者是否应该先具备作为 OpenStack 项目运行一段时间的历史的讨论。对于该申请的共识是，我们应该等待并先让项目启动。该团队是 Kosmos，一个新项目，最初由 Designate (DNS as a Service) 和 Neutron Load Balancing as a Service 团队的成员组成，他们希望提前申请治理，以便开始工作。我们对“我们认识的人”与“展示你的工作”之间的思考进行了充分的讨论，最终决定要求他们等待并提供更多证据证明他们的工作正在进行。我们认识到，团队需要治理才能访问某些服务，例如文档托管和集成测试。

九月底的最后一周，我们讨论了 CloudKitty 和 Juju Charms for Ubuntu 的应用程序。我们决定在仓库中有实质性内容之前推迟对 Juju charms 应用程序的决定，因为现在它们可以在没有“官方”的情况下设置。这也有助于理解任何许可复杂性。CloudKitty，一个 OpenStack 的计费解决方案，已被接受治理。

Astara 又名 Akanda

本周另一个有趣的申请讨论来自 Akanda 公司的 Neutron 驱动程序 Astara，他们要求在“大帐篷”下进行治理，而不是将他们的驱动程序作为仓库添加到 neutron 团队。技术委员会与即将离任和即将上任的 PTL 合作，因为这对每个人来说都是一个新概念。我们批准了他们的治理申请，现在正在审查该系列中的第二个补丁，将 Astara 驱动程序添加到 Neutron 仓库集合。

从“大帐篷”中移除项目

在 PTL 选举期间，我们发现 MagnetoDB 在上次发布中没有贡献者，并决定停止该项目。我们讨论了如何将该政策正式化，并确保关于移除的沟通清晰。由于更容易的包含政策到位，平稳地淘汰项目也更有意义。

东京提供 OpenStack 培训课程

 

2015 年 10 月 5 日

OpenStack 东京峰会即将到来，我们想向您更新一些将在峰会日期（10 月 27 日至 30 日）在东京举行的 OpenStack 培训和认证课程。对于那些旅行的人来说，您可能想利用这些优惠，充分利用您的访问。

培训课程

PLUMgrid 提供的 OpenStack 网络基础 Express
  • 日期：2015 年 10 月 26 日
  • 时长：1 天
  • 时间：上午 9 点 - 下午 5 点
  • 地点：日本东京，文京区小石川 2-6-1 饭田桥第一大厦，邮编 112-8560
  • 注册 这里
PLUMgrid 提供的 OpenStack 网络 Bootcamp Express
  • 日期：2015 年 10 月 30 日
  • 时长：1 天
  • 时间：上午 9 点 - 下午 5 点
  • 地点：日本东京，文京区小石川 2-6-1 饭田桥第一大厦，邮编 112-8560
  • 注册 这里
Midokura 提供的 MidoDay Tokyo
  • 日期：2015 年 10 月 26 日
  • 时长：1 天
  • 时间：上午 9 点 - 下午 7 点
  • 地点：日本东京，港区赤坂 1-12-32 ARK Hills 的 ARK Mori Buidling，邮编 107-6001
  • 注册 这里
Big Switch Networks 提供的 OpenStack 与 Big Cloud Fabric 的集成
  • 日期：2015 年 10 月 27 日至 30 日
  • 时长：30 分钟
  • 时间：按需
  • 地点：在线
  • 注册 这里
Mirantis OpenStack Bootcamp (OS100)
  • 日期： 10 月 24 日 - 10 月 26 日
  • 时长：3 天
  • 时间： 上午 9 点 – 下午 5 点
  • 地点： 日本东京，待定
  • 注册这里
如果您对上述培训和认证有任何疑问，请直接联系成员公司以获取更多信息。

 

我们将在东京与您相见！

 

标签：

OpenStack 每周社区新闻简报 (9 月 26 日 – 10 月 2 日)

 

2015 年 10 月 2 日

OpenStack Liberty 中新增的 53 个功能

又一个秋天，又一个 OpenStack 版本。OpenStack 的第 12 个版本 Liberty 将于 10 月 15 日发布，并且候选版本已经在发布中。那么，在过去六个月的开发中，我们可以期待什么？

App 开发者：第一个 OpenStack 教程需要您

指导新开发者将其第一个应用程序部署到 OpenStack 的教程已经完成，适用于 Apache Libcloud，需要帮助支持新的语言和 SDK。

通往东京之路

社区反馈

OpenStack 一直对反馈和社区贡献感兴趣，如果您希望在 OpenStack 每周社区新闻通讯 中看到新的部分，或者对内容呈现方式有想法，请与我们联系：[email protected].

之前活动的报告 

  • 本周没有

截止日期和贡献者通知

安全公告和通知 

技巧 ‘n 窍门 

即将举行的活动 

开发者列表中的重要信息

PTL 选举结果公布！

拟议的设计峰会轨道/房间/时间分配

OpenStack 每周社区新闻简报 (9 月 19 日 – 25 日)

 

2015年9月25日

注册 OpenStack Summit Tokyo 2015

全面访问注册价格将于 9 月 29 日太平洋时间晚上 11:59 提高

这堆用户故事突出了人们在 OpenStack 中想要的东西

产品工作组最近启动了一个 Git 仓库，用于收集从加密存储到滚动升级的需求。

容器中的存储工作原理

FICO 云服务工程高级总监 Nick Gerasimatos 深入探讨了容器缺乏持久存储的问题，以及 Docker 卷和数据容器如何提供解决方案。

通往东京之路

社区反馈

OpenStack 一直对反馈和社区贡献感兴趣，如果您希望在 OpenStack 每周社区新闻通讯 中看到新的部分，或者对内容呈现方式有想法，请与我们联系：[email protected].

之前活动的报告 

截止日期和贡献者通知

安全公告和通知 

技巧 ‘n 窍门 

即将举行的活动 

开发者列表中的重要信息

处理没有 PTL 候选人的项目

  • 技术委员会将任命一个 PTL [1]，如果没有已识别的合格候选人。
  • 任命的 PTL
    • Robert Clark 提名安全 PTL
    • Serg Melikyan 提名 Murano PTL
    • Douglas Mendizabal 提名 Barbican PTL
    • Magnum PTL 选举在 Adrian Otto 和 Hongbin Lu 之间进行
  • MagnetoDB 被放弃，没有选择 PTL。相反，它将加速从 OpenStack 官方项目列表中移除 [2]。

需要发布帮助 – 我们彼此不兼容

  • Robert Collins 指出，我们用来识别不兼容组件的约束系统正在工作，但发布团队需要社区的帮助来修复现有的不兼容性，以便我们可以切断完整的 Liberty 版本。
  • 存在的问题
    • OpenStack 客户端无法创建镜像。
      • 补丁已合并 [3]。

Semver 和依赖关系更改

  • Robert Collins 说，目前我们没有提供关于当项目的唯一更改是依赖关系更改时会发生什么情况的指导。
    • 今天发布团队将依赖关系更改视为“功能”而不是错误修复。（例如，如果之前的版本是 1.2.3，需求同步发生，下一个版本是 1.3.0。）
    • 背后的原因很复杂，需要一些指导来回答问题
      • 此需求更改是 API 中断吗？
      • 此需求更改是功能工作吗？
      • 此需求更改是错误修复吗？
    • 所有这些问题都可能是真的。一些例子
      • 如果库 X 将库 Y 作为其 API 的一部分公开，并且库 Y 的依赖关系从 Y>=1 更改为 Y>=2。X 这样做是因为它需要 Y==2 的功能。
      • 库 Y 未在库 X 的 API 中公开，但是，X 的 Y 依赖关系的变化会影响独立使用 Y 的用户。（忽略此处围绕 PIP 的复杂性。）
    • 提议
      • 无 -> 需求 -> 主要版本更改
      • 1.x.y -> 2.0.0 -> 主要版本更改
      • 1.2.y -> 1.3.0 -> 次要版本更改
      • 1.2.3. -> 1.2.4 -> 补丁版本更改
    • Thierry Carrez 同意最后两个建议。默认情况下进行主要版本升级似乎有些过头了。
    • Doug Hellmann 提醒我们不能假设依赖关系本身使用 semver。我们需要其他东西来确定 API 是否实际上发生了中断。
    • 由于这个问题非常复杂，Doug 宁愿过度简化需求更新的分析，直到我们更好地识别自己的 API 中断更改并区分功能和错误修复。这将使我们保持一致，即使不是 100% 正确。

应用漏洞：managed 标签的标准

  • 几个月前，漏洞管理流程被带到“大帐篷” [4]。
  • 最初，我们列出了漏洞管理团队 (VMT) 跟踪漏洞的仓库。
    • TC 决定将此从仓库更改为交付物，因为根据仓库的标签被认为是不合适的。
  • Jeremy Stanley 提供了关于交付物如何获得此标签的透明度
    • 给定交付物中的所有仓库都必须符合条件。如果有一个仓库不符合，那么在给定的交付物中它们都不符合。
    • 联系人
      • 交付物必须有一个指定的联系人。
        • VMT 将与此联系人联系以处理报告。
      • 核心审查员小组应成为 <project>-corsec 团队的一部分，并将
        • 确认错误是否准确/适用。
        • 提供与报告相关的补丁的预先批准。
    • 交付物的 PTL 应同意充当（或委托）漏洞管理联络人，以供 VMT 升级。
    • 交付物仓库中的错误跟踪器应配置为最初向 VMT 提供对私有报告的漏洞的访问权限。
      • VMT 将确定漏洞是否报告在正确的交付物上，并在可能的情况下重定向。
    • 交付物仓库应经过第三方审查/审计，以查找不安全的设计或风险实施的明显迹象。
      • 这旨在减少 VMT 的工作量。
      • 尚未确定谁将执行此审查。也许是 OpenStack 安全项目团队？
  • 此提案的审查已发布 [5]。

所有 API 上一致支持 SSL 终止代理

  • 在调试一个错误 [6] 时，发现一个问题，即位于执行 SSL 终止的代理后面的 API 将不会生成正确的重定向（http 而不是 https）。
    • 已经给出审查 [7]，提供了一个配置选项“secure_proxy_ssl_header”，允许 API 服务根据标头 X-Forwarded-Proto 检测 ssl 终止。
  • 2014 年还有一个相同的错误 [8]。
    • 几个项目应用了补丁来修复此问题，但并不一致
      • Glance 添加了 public_endpoint 配置
      • Cinder 添加了 public_endpoint 配置
      • Heat 添加了 secure_proxy_ssl_header 配置（通过 heat.api.openstack:sslmiddleware_filter）
      • Nova 添加了 secure_proxy_ssl_header 配置
      • Manila 添加了 secure_proxy_ssl_header 配置（通过 oslo_middleware.ssl:SSLMiddleware.factory）
      • Ironic 添加了 public_endpoint 配置
      • Keystone 添加了 secure_proxy_ssl_header 配置
  • Ben Nemec 评论说，在服务级别解决这个问题是错误的，因为这需要在许多不同的 API 服务中进行更改。相反，应该在将流量转换为 http 的代理中修复。
    • Sean Dague 指出，这应该在服务目录中完成。服务发现是所有服务在相互通信时都应使用的基本功能。有一个 OpenStack 规范 [9]，试图解决这个问题
    • Mathieu Gagné 指出这行不通。服务目录中存在“拆分视图”，其中内部管理节点具有特定的目录，而公共节点（供用户使用）具有不同的目录。
      • 建议使用 oslo 中间件 SSL 来支持“secure_proxy_ssl_header”配置，以解决问题，代码量很少。
      • Sean 同意需要考虑拆分视图，但是，不应该让另一层工作决定服务目录是否是跟踪我们的服务 URL 的好方法。我们不应该推动一个 Keystone 是可选的模型。
      • Sean 指出，虽然“secure_proxy_ssl_header”配置解决方案支持存在一个 HA 代理与 SSL 终止到 1 个 API 服务的情况，但它可能不适用于 1 个 API 服务到 N 个 HA 代理的情况
        • 客户端需要正确理解“Location:”标头。
        • 像 request/phatomjs 这样的库可以遵循 REST 文档中提供的链接，并且它们是正确的。
        • 少数几个可以选择“不依赖关键组件”运行的服务能够正常工作。
      • ZZelle 提到，当服务本身充当代理（例如 nova image-list）时，此解决方案不起作用。
      • 此解决方案是否适用于 HA Proxy 的情况，即多个后端服务器对应一个终止地址？
        • 是的，通过尊重 HTTP 代理设置的 X-Forwarded-Host 和 X-Forwarded-Port 头部，使 WSGI 应用程序不知道它们前面存在请求。
  • Jamie Lennox 说，同样的问题出现在 Devstack 补丁中，目的是在 gate 中使用 HA Proxy 进行 TLS 测试，从而导致阻塞。
    • 更长期的解决方案是，将服务过渡到使用相对链接。
      • 这是一个相当重要的改变。我们一直返回绝对 URL，因此假设所有客户端代码都会使用相对代码是一个很大的假设。这绝对是主要版本。
  • Sean 同意，我们已经具备了足够的组件，可以在 Mitaka 中使用代理头部获得更好的效果。如果清理服务目录的使用，我们可以处理剩余的边缘情况。

[1] – http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html

[2] – https://review.openstack.org/#/c/224743/

[3] – https://review.openstack.org/#/c/225443/

[4] – http://governance.openstack.org/reference/tags/vulnerability_managed.html

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

[6] – https://bugs.launchpad.net/python-novaclient/+bug/1491579

[7] – https://review.openstack.org/#/c/206479/

[8] – https://bugs.launchpad.net/glance/+bug/1384379

[9] – https://review.openstack.org/#/c/181393/

技术委员会亮点 2015 年 9 月 25 日

 

标记多样性和弃用策略

自从标记项目以显示一定比例的多样性以来，我们也在讨论一个 反向标记，以指示缺乏多样性。我们 TC 的一些成员不确定缺乏多样性是否表明项目没有用或不成功，尤其是在项目成熟的早期阶段。另一些人希望表明缺乏多样性可能意味着支持很容易被撤回。

我们通过了一个 “遵循标准弃用”标签，项目可以使用它来表明其弃用策略遵循所有 OpenStack 项目的标准。目前还没有项目声明遵循此标签，但我们希望社区知道我们已经编写了配置选项和潜在功能弃用的策略。

行为准则 (CoC)

Cindy Pallares 联系了技术委员会，提出改进 OpenStack 当前 CoC 的建议。在审查了其他社区的 CoC 并听取了 Cindy 和其他成员的反馈后，OpenStack 的 CoC 将得到更新和改进，使其按上下文组织，例如在线或在活动中。请保持联系并密切关注此讨论，因为它将对整个社区产生影响。我们已经在两种情况下都制定了行为准则，但我们积极审查这些准则，因为社区不断发展、多样化和成熟，以确保它满足所有成员的需求。

考虑其他编程语言

有一个新的 决议，定义了应该如何评估用其他编程语言编写的项目。该决议讨论了我们主要包含和计划 Python 项目，同时 JavaScript（Dashboard）和 bash（DevStack）也随着时间的推移被启用。讨论在几会前开始，强调和讨论了大帐篷、社区影响、基础设施影响、技术影响等问题。由于此主题影响整个社区，我们感谢我们收到的意见，并欢迎大家阅读和理解该决议。我们得出结论，我们确实考虑其他语言，但需要确保基础设施、测试和文档的通用流程和工具，特别是对于 OpenStack 服务。

处理没有候选 PTL 的项目团队

我们克服了最近候选人轮次中时区混淆问题，并批准了这些项目的 PTL。

  • 安全：Robert Clark
  • 密钥管理器 (barbican)：Douglas Mendizabal
  • 应用目录 (murano)：Serg Melikyan

对于容器 (magnum) 项目，两位候选人 Hongbin Lu 和 Adrian Otto 同意进行选举，以解决候选人提交时间上的问题。选举官员同意他们可以为 magnum 运行另一次 PTL 选举，因此如果您在过去六个月内参与了 magnum 代码库的工作，请查看您的收件箱中的投票。

MagnetoDB 没有收到任何候选人。不幸的是，该项目已经有一段时间没有收到贡献了，并且正在考虑从 Big Tent 中删除。请阅读更多关于当前讨论的内容 在 review 中。

提醒一下，我们的 章程目前规定，“给定项目 PTL 选举的投票者是活跃的项目贡献者（“APC”），他们是基金会个人会员的一个子集。在过去两个 6 个月发布周期内，对项目存储库进行过提交的个人会员被认为是该项目团队的 APC。” 项目的存储库名称保存在 openstack/governance 存储库中的 projects.yaml 文件中。

应用程序正在进入并受到欢迎

我们一直忙于审查进入 OpenStack 管理的应用程序。

Monasca 项目被要求继续致力于其开放流程，并使其应用程序保持在队列中。对其考虑的三点反馈是：1) 集成测试应作为 gate 作业使用 OpenStack CI 工具运行，使用 devstack 作为引导。2) 将源代码托管在 gerrit (review.openstack.org) 中，以便充分理解所有组件和测试。3) 更好地与社区集成，使用更多沟通模式并进行跨项目联络工作。

我们讨论了 Kosmos 项目的申请，这是一个非常新的项目，最初由 Designate 和 Neutron LBaaS 的成员组成，旨在为 OpenStack 云提供全局服务器负载均衡。TC 的一些成员更希望看到更多关于他们工作的证据，另一些人认为新的 OpenStack 工作方式定义应该使他们能够申请并被接受。

我们正在考虑 CloudKitty 申请和 Juji Charms for Ubuntu 申请进入 OpenStack 管理，并将考虑在下一次 TC 会议上进行。作为时间安排的指导，我们将在星期五 0800 UTC 之前提交的动议添加到下一次星期二会议议程中进行讨论。

跨项目轨道

在即将到来的 Mitaka 会议上，社区将有一个专门用于跨项目讨论的轨道。提案期现已开放，将持续到 10 月 9 日。可以在 ODSREG 上提交会话提案。更多信息可以在此 线程 中找到。

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 的方式
    • 将镜像位发布到 Glance API 服务器。
      • 部署不广泛。潜在的 DOS 向量。
    • 任务 API，让 Glance 异步下载它。
      • 部署不广泛。
      • 假设您知道哪些云支持哪些“任务”类型，以及预期的参数（例如，Glance 文档给出了一个源的 URL，但 Rackspace 给出了 Swift 位置作为源）。

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

  • Monty Taylor 讨厌浮动 IP。
    • 观察了 5 个公共云，需要您使用浮动 IP 才能获得出站地址。其他云直接将您连接到公共网络。
    • 一些允许您创建一个私有网络并将虚拟机连接到它，创建一个带有网关的路由器。
  •  Monty 希望有一种更简单的方法，让虚拟机位于云的面向外部的网络上。用户不应该 学习如何使用浮动提示使其工作。这应该是在公共云中的一致行为。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 的竞争条件

OpenStack 社区每周简讯（9 月 5 日 – 11 日）

 

2015年9月11日

现在就来体验 TryStack 的理由

免费的 OpenStack 测试沙箱回归了——而且比以往任何时候都更大、更强、更好。

Puppet OpenStack Liberty 周期回顾

OpenStack 的发展速度非常快；适时休息一下，记录一些回顾可能会有所帮助；这将有助于了解过去几个月 Puppet OpenStack 项目中发生的事情。

通往东京之路

之前活动的报告 

  • 本周没有

截止日期和贡献者通知

安全公告和通知 

技巧 ‘n 窍门 

即将举行的活动 

其他新闻

OpenStack 反馈

When the first patch of a big new feature finally merges after months of work!

经过数月的努力，一个大型新功能的第一个补丁终于合并了！

每周简报是社区了解 OpenStack 世界中各种活动的方式。

OpenStack 社区每周 Newsletter (8月29日 – 9月4日)

 

2015年9月4日

通往东京之路

之前活动的报告 

截止日期和贡献者通知

安全公告和通知 

技巧 ‘n 窍门 

即将举行的活动 

其他新闻

OpenStack 反馈

Ceilometer looking to consume messages from the queue

Ceilometer 正在寻找从队列中消费消息

每周简报是社区了解 OpenStack 世界中各种活动的方式。

技术委员会亮点 2015 年 9 月 2 日

 

新来者

自上次发布以来，有一些新的项目团队请求。以下是请求加入 OpenStack Big Tent 的新项目团队列表以及讨论摘要

OpenStack Community App Catalog 团队已请求加入 Big Tent，并且已被接受
RefStack 项目已请求从 Infra 子项目迁移到自己的团队，并且已被接受
OpenStack Debian 软件包现在已经组建了团队，并已被欢迎加入 Big Tent。
Monasca 项目已请求加入 Big Tent，但一些社区实践要求（例如会议不在 IRC 上进行）未得到满足。此外，关于编程语言支持和通用实践的新讨论由此产生，并促成了此决议，稍后将在本文中讨论。

项目团队指南

在本周期早期，一个名为“Project Team Guide”（项目团队指南）的工作组被创建，用于编写一份面向新项目和现有项目的指南，解释 OpenStack 项目团队的工作方式、OpenStack 的宗旨以及社区的许多其他方面。技术委员会和该工作组成员很高兴地宣布该指南已完成并发布。该指南的源代码位于项目团队指南仓库，欢迎贡献。请阅读并根据需要进行改进。

设置项目和服务名称的指南

命名是项目可以做的最困难的事情之一。好吧，不是真的，但给事物命名确实很难。考虑到这一点，前 Docs PTL Anne Gentle 编写了一套在记录和审查项目和服务名称时使用的指南。技术委员会可以在审查传入的项目申请时使用这些指南。现在撰写文档的每个人都有一个可供参考的文档，用于为每个受众编写关于这些服务的内容。主要指南是关于大写：对于服务名称，对服务名称中的每个单词使用首字母大写，并避免在服务名称中使用已经注册商标的名称。对于项目名称，使用小写，因为这是文档团队的历史指导方针，并且我们希望强调项目名称将不会被注册商标。

OpenStack 社区每周 Newsletter (8月22日 – 28日)

 

2015年8月28日

重要 + 时间敏感

掌握容器与 OpenStack：一份白皮书

随着容器获得重大进展，OpenStack 基金会发布了一份新的白皮书，重点介绍了如何成功使用它们。

深入研究一本专门介绍 Trove 的新书

在 Trove Day 之前，OpenStack 数据库即服务作者谈论了常见错误以及如何开始贡献。

通往东京之路

之前活动的报告 

截止日期和贡献者通知

安全公告和通知 

技巧 ‘n 窍门 

即将举行的活动 

其他新闻

每周简报是社区了解 OpenStack 世界中各种活动的方式。