OpenStack 每周社区新闻简报 (10 月 10 日 - 16 日)

OpenStack 的第 12 个版本 Liberty 昨日发布

Liberty 版本共有 1,933 名个人贡献者和 164 个组织参与贡献,它提供了更精细的管控能力、大型部署的性能增强以及更强大的工具来管理生产环境中的新技术,例如容器:了解更多

打破孤岛,OpenStack

华为技术公司的资深软件架构师、OpenStack 社区活跃成员 Rochelle Grober 表示:“各个项目需要共同努力,开发一致的格式、方法和信息传递方式。”

通往东京之路

社区反馈

OpenStack 始终欢迎反馈和社区贡献。如果您希望在 OpenStack 每周社区新闻中看到新的版块,或者对内容呈现方式有任何想法,请与我们联系:[email protected].

之前活动的报告 

  • 本周没有

截止日期和贡献者通知

安全公告和通知 

  • 本周没有

技巧 ‘n 窍门 

即将举行的活动 

开发者列表中的重要信息

Success Bot Says

  • ttx: 又一个 OpenStack 版本发布!
  • 在 jesusaurus 的帮助下,基础设施团队部署了 Kibana 3。升级 elastic search 集群的初步步骤。
  • shamail: 产品工作组 wiki 已完全更新 [1]
  • tristanC: 选举出了 6 名新的 TC 成员 [2]
  • AJaeger: OpenStack API 快速入门已转换为 RST [3],并翻译成德语 [4] 和日语 [5]。
  • reed: OpenStack Shade 教程的第 2 和第 3 部分已合并。现在开始处理第 [6] 部分。
  • sirushti: Heat 刚刚宣布支持 Python 3.4 [7]。
  • AJaegar: 所有文档手册已更新为 Liberty 的内容 [8]。

升级到 Gerrit 2.11

  • OpenStack 基础设施团队希望从 Gerrit 2.8 升级到 2.11。
  • 计划在 Mitaka 峰会之后不久进行升级。
  • 动机:利用一些新的 REST API、ssh 命令和流事件功能。
  • Gerrit 2.11 中有一个很大的 UI 变化,Gerrit 2.8 包含旧的和新的样式。
  • 预览 2.11 [9]。
  • 如果您不喜欢 Gerrit 2.11,请尝试 Gertty [10]。

服务目录:下一代 (续)

  • 从上周的总结开始…
  • Sean Dague 意识到,虽然人们希望朝着更激进的方向发展,但我们应该小心。这不是一张白纸,因为有足够多的用户在使用它,我们必须进行谨慎的转变,从而实现类似于旧事物的新事物。
    • 至少在未来 6 到 12 个月内,远离 REST 是不可行的。
    • 通过 REST 获取服务目录,而无需身份验证或租户 ID,可以让我们找到一种弄清 DNS 表示形式的方法。

为 Mitaka 建立发布联络人

  • Doug Hellmann 写道,发布管理团队依赖于每个项目的联络人,以便为所有团队之间的工作进行协调。
    • 发布联络人的职责 [11]。
    • 注册 [12]。

Mitaka 期间的发布沟通

  • Doug Hellmann 开始发送许多电子邮件,描述我们处理 Mitaka 周期发布管理方式的变化。
  • 过去,我们存在沟通问题,项目团队负责人没有看到或注意发布相关的公告。
  • 此电子邮件已发送到列表和各个项目团队负责人,以提高所有人都能看到它的几率。
  • 将在 openstack-dev 邮件列表中使用“[release]”主题标签。
    • 所有项目团队负责人和发布联络人应配置他们的电子邮件客户端,以确保消息可见。

Requests + urllib3 + distro 包 (续)

  • 继续上周的讨论…
  • Robert Collins 评论一个简单的解决方法是始终使用虚拟环境,而不是系统站点包。
    • OpenStack 基础设施团队是否考虑过使用系统站点包?
      • 是的,但我们利用 Python 生态系统将新版本上传到 PyPI。然后我们可以立即测试我们的软件与依赖项新版本的兼容性。
  • 一种前进的方法是
    • 让发行版修复其 requests Python 依赖项
      • Ubuntu [13]
      • Fedora [14][15][16]
      • 修复 pip 中现有的已知错误,这些错误在某些操作中违反了此类依赖项。
    • 停止使用 vendorized 版本的 requests 并 fork 该项目以使用它应该从一开始就使用的依赖项。
    • 说服上游停止 vendorizing urllib3。
    • 始终使用发行版包的 requests,而不是来自虚拟环境。

调度器提案 (续)

  • 继续上周的总结…
  • Ed 注意到 Josh Harlow 的解决方案与当前主机将其状态发送到调度器的设计没有太大区别。
  • 提出 Cassandra 的原因是消除重复,并让资源被调度器和调度器本身都使用相同的数据。
    • 这是当前设计的意图。数据永远不可能完美,所以使用你所拥有的,并希望系统的其余部分处理你的错误并优雅地重试。(例如,计划的计算节点不再有资源来容纳请求。)
    • 为了使这个解决方案对下游发行版和/或 OpenStack 用户可行,你必须解决
      • Cassandra 开发者上游应该开始关心 OpenJDK。
      • 或者 Oracle 应该使其 JVM 免费软件。
    • Clint 注意到 Cassandra 不推荐使用 OpenJDK [17]。
      • Thomas 补充说
        • 上游不会针对 OpenJDK 进行测试。
        • 当它只影响 OpenJDK 时,他们会在不修复的情况下关闭错误。
  • Thierry 通常对 Java 解决方案持负面态度,这是原因之一 [18]。免费软件 JVM 与非免费 JVM 不相当。然后我们间接迫使我们的用户使用非免费依赖项。当 Java 解决方案是解决某个问题的唯一解决方案时,这可能仍然是一个不错的权衡,而不是重新发明轮子。但是,对于分布式锁和共享状态,还有其他一些不错的选择。
    • Clint 提到 Zookeeper 与 Cassandra 不同。他使用 OpenJDK 取得了成功。它也适用于 Debian/Ubuntu,使开发人员更容易访问。

[1] – https://wiki.openstack.org/wiki/ProductTeam

[2] – https://wiki.openstack.org/wiki/TC_Elections_September/October_2015#Results

[3] – https://developer.openstack.org/api-guide/quick-start/

[4] – https://developer.openstack.org/de/api-guide/quick-start/

[5] – https://developer.openstack.org/api-guide/quick-start/
[6] – https://review.openstack.org/#/c/232810/

[7] – https://review.openstack.org/231557

[8] – https://docs.openstack.org/liberty/

[9] – http://review-dev.openstack.org

[10] – https://pypi.python.org/pypi/gertty

[11] – https://docs.openstack.org/project-team-guide/release-management.html#release-liaisons

[12] – https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management

[13] – https://bugs.launchpad.net/ubuntu/+source/python-requests/+bug/1505038

[14] – https://bodhi.fedoraproject.org/updates/FEDORA-2015-20de3774f4

[15] – https://bodhi.fedoraproject.org/updates/FEDORA-2015-1f580ccfa4

[16] – https://bodhi.fedoraproject.org/updates/FEDORA-2015-d7c710a812

[17] – https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StartupChecks.java#L153-L155

[18] – https://twitter.com/mipsytipsy/status/596697501991702528

OpenStack 反馈

将 keystone 的 authtoken 中间件插入到服务中“如此优雅”

发表回复

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