这篇文章是 OpenStack 开放麦克风系列的一部分，旨在突出那些帮助 OpenStack 取得成功的人，以此庆祝该项目的第三个生日。在七月期间的每一天，一位新的贡献者将站上麦克风，回答关于 OpenStack、云、职业以及他们业余爱好等五个问题。
Dirk 是 SUSE 的 OpenStack 高级工程师，他接触 OpenStack 的各个方面。
1. 你的第一次提交或贡献是什么，你为什么要做它？
那大约半年前，在我提交第一个评审 (https://review.openstack.org/#/c/19830/) 的时候，紧接着我的 CLA 申请被批准，并且在我开始参与 OpenStack 后的两天。我的主要原因是测试在 OpenStack 上贡献代码有多容易。我通过实践学习，所以贡献代码是我学习如何贡献的方式，而且我感到很惊喜，它非常容易。我也感谢那位“神秘”的 Jenkins 先生，在他给予 +1 的时候。
2. 哪些其他的 OpenStack 开发者值得表扬，因为他们在社区中做出的工作？ 谁是我们的默默无闻的英雄？ 你自己的呢？
我接触最多的三个领域是那些致力于在线文档工作的人（它在不断改进，而且已经非常有用！）、无数志愿审查代码变更并几乎总是提出改进补丁建议的人，以及最后但并非最不重要的是 Stefano（以及所有帮助他的人）负责社区简报，这对像我这样忙碌的人来说，至少可以了解正在发生的事情。我只能勉强预料到他们付出的努力，任何为这些做出贡献的人都值得我的掌声。
3. 你认为云软件在未来一年内要被广泛采用的最关键功能是什么？
最关键的功能不是一个蓝图，而是所有朝着易于安装、配置和一致使用方向发展的一切。OpenStack 在拆分由各个项目管理的组件方面做得很好，但为了获得完整的特性体验，所有这些组件都需要由管理员（“用户”）重新组合起来，并且在第一次从头开始进行这些步骤时，人们会遇到很多问题。例如，在各个项目之间略有不一致的事情，比如配置选项做同样的事情但名称不同，或者项目之间的默认值不同，或者客户端的命令行略有不同。已经有很多工作正在进行中，但为了真正成功，OpenStack 作为一个整体需要共同努力。我相信一致性并不意味着有一种“正确”的做法。即使是“错误”的做法，如果至少在所有项目之间保持一致，并且可以在一个地方一目了然地更改，也稍微好一些。
4. 你认为开放、社区驱动的开发方法有哪些好处？
我认为的主要好处是它将代码和功能的决策权放在那些从事工作的人的肩上。那些不积极审查或积极贡献代码的人对项目的方向和单个实现细节的影响较小。这感觉很自然和激励人心，并且也保持了项目中的健康务实性。唯一的缺点是，一个人可能只有在体验过非开放性的缺点之后，才会重视开放性，即在不受决策影响的情况下进行指导。
5. 你最喜欢的提高生产力的技巧是什么？ 秘密技巧？ 你有点不好意思承认的快捷方式？
我在编辑器中使用 F10 作为热键，执行一个一次性“doit.sh”，它自动执行构建、重新部署和执行重现原始问题所需的步骤，例如，只是再次运行我当前正在努力的那个测试用例。
总的来说，我追求的主要生产力“技巧”是，只要我重复做某件事第三次，我就开始编写脚本或至少编写脚本化检查，并尽可能地自动化它。这需要相当大的自制力，但通过记住完美执行重复性任务不是人类的优势，它总是会得到回报。
6. 你经常听到关于 OpenStack 的最常见的误解是什么？
这可能是 OpenStack 只是另一种管理虚拟化的方式的看法，而没有意识到云解决方案以及 OpenStack 特别背后的不同理念。云提供自助服务、自我管理、使用计量，以及被设计为将故障视为一种特性。
7. 你对 OpenStack 社区在未来 5 年内的最大希望是什么？ 真正令人惊叹的是什么？
你的意思是“O”版本之后会是什么（我将投票支持将其命名为“OpenStack 发布”，这将使 Triple-O 最终成为 Quad-O）？ 好吧，我最大的希望是，之后有一个带有“P”字母的发布版本，其中也包含平台服务。或者我们已经远远超出了这一点，并且有一个“S”版本？！ 让我们一起找到答案！
发表评论