SuccessBot 说

• Pabelanger: bare-precise 已被 ubuntu-precise 取代。DIB 万岁
• bknudson: Keystone CLI 终于消失了。OpenStack CLI 万岁。
• Jrichli: swift 刚刚合并了一个开始于一年前的大型工作，它将促进新的功能 – 例如加密
• 全部

R-20 周发布倒计时，5月16日至20日

• 重点
  • 团队应该已经将峰会会议的总结发布到 openstack-dev 邮件列表。
  • 规范编写
  • 审查优先级功能
• 通用说明
  • 发布公告邮件将被标记为 ‘new’ 而不是 ‘release’。
  • 发布周期模型标签现在明确说明发布团队管理发布。
• 发布操作
  • 发布联络人应将他们的姓名和联系信息添加到此列表 [1]。
  • 新的联络人应了解发布说明 [2]。
  • 希望更改其发布模型的项目团队应在 R-18 的第一个里程碑之前进行更改。
• 重要日期
  • Newton 1 里程碑：R-18 6月2日
  • Newton 发布计划 [3]

收集我们的 Wiki 用例

• 最初，社区一直在使用 wiki [4] 作为默认的社区信息发布平台。
• 存在的问题是
  • 保持更新。
  • 防止被恶意破坏。
  • 过时的流程。
  • 不再存在的项目。
• 这些过时的信息可能会使其使用起来令人困惑，尤其是对于搜索引擎会提供引用指向它的新用户而言。
• 已经发生了一些努力，将信息从 wiki 推送到适当的文档指南，例如
  • 基础设施指南 [5]
  • 项目团队指南 [6]
• 经过同行评审的参考网站
  • 发布 [7]
  • 安全 [8]
• 有很多用例 wiki 是一个好的解决方案，我们可能需要一个像 wiki 这样的轻量级发布平台来涵盖这些用例。
• 如果您在您的 OpenStack 工作中使用 wiki，请确保将其记录在此 etherpad 中 [9]。
• 完整线程

支持 Go (续)

• 继续之前的 Dev Digest [10]。
• 在 Go 1.5 之前（没有 -buildmode=shared），它不支持共享库的概念。因此，当库升级时，发布团队必须为每个反向依赖项触发重建。
• 对于 Swift 而言，考虑 Go，很难用 Python 编写一个网络服务，在网络和块设备之间传递数据，并有效地利用所有可用硬件。
  • 使用 eventlet 通过协作并发进行 fork() 子进程效果很好，但管理许多核心和许多驱动器上的所有异步操作非常困难。Python 中没有有效的接口。我们谈论的是适合手头工作的有效工具。
  • Eventlet、asyncio 或任何其他单线程程序都会遇到相同的问题，文件系统 syscalls 需要很长时间，并且调用线程可能会被阻塞。例如
    • 调用 select()/epoll() 以等待与许多文件描述符发生某些事情。
    • 对于每个就绪的文件描述符，如果文件描述符 socket 可读，则读取它，否则内核返回 EWOULDBLOCK，并移动到下一个文件描述符。
• Designate 团队解释了他们选择 Go 的原因
  • MiniDNS 是一个组件，由于其工作方式，很难进行重大改进。
  • 该组件获取数据并在每次记录集更新时发送区域传输。这是一个完整的 (AXFR) 区域传输，其中每个区域中的每个记录都发送到最终用户可以访问的每个 DNS 服务器。
    • 存在一种用于增量更改的 DNS 标准，但它实现起来很复杂，并且经常最终恢复到完整的区域传输。
  • Ns[1-6].example.com 可能是数十或数百台服务器位于 anycast Ips 和负载均衡器之后。
  • 内部或外部区域可能非常大。想想 200-300Mb。
  • 一个区域可能具有高流量，其中每个启动/销毁都会添加/删除一个记录。
  • Designate 团队规模很小，在查看选项后，考虑到可用的开发人员工时，决定使用不同的语言。
• 查看 Designate 的实现，可以进行一些立竿见影的改进
  • 停止为每个请求生成一个线程。
  • 停止为每个请求实例化 Oslo 配置对象。
  • 避免每个请求进行 3 次数据库往返。这里的大部分请求时间并没有在 Python 中花费。由于 Designate 知道何时使缓存数据失效，因此此数据应该很容易缓存。
    • 在实际用例中，由于多个 miniDNS 服务器的 shuffle 顺序，可能会发生缓存未命中。
• Designate 团队在没有缓存的情况下，对于 2000 条记录的 AXFR 实现了 10 倍的改进。缓存也可能加速 Go 实现。
• Go 历史上在多核方面性能较差 [11]。
  • 该语言的主要优势可能是 CSP 模型。
  • Twisted 可以很好地做到这一点，但我们作为一个社区始终支持 eventlet。Eventlet 具有线程编程模型，这不适合 Swift 的情况。
  • PyPy 在 6 年前对 Twisted 的 DNS 组件的基准测试中获得了比 Cpython 高 40% 的性能提升 [12]。
• 现在我们的堆栈已经具有依赖关系 C、Python、Erlang、Java、Shell 等。
• 最终用户绝不在乎服务器 API 使用什么语言编写。他们想要稳定性、性能和功能。
• 与 Go 的可靠构建、打包等相关的基础设施问题正在解决中 [13]
• Swift 已经测试了在 PyPy 下运行，并得出了一些结论
  • 假设 PyPy 和 OpenStack 的生产就绪稳定性，每个人都应该使用 PyPy 而不是 CPython。
    • 它就是更快。
    • 在 Swift 的使用中，仍然有一些与垃圾收集相关的问题需要解决。
    • 有一些补丁可以更好地处理 Swift 中的套接字，在 PyPy 下运行效果更好。
  • PyPy 只有在您拥有受 CPU 限制的环境时才会有所帮助。
  • Swift 中的 GoLang 目标与有效的线程管理 syscalls 和 IO 相关。
  • 请参阅奥斯汀会议上的相关演讲 [14]。
• 完整线程