尽管这一年与往常非常不同,但拥有超过 11 万社区成员的 Open Infrastructure 社区仍然将其打造成为一个高效且成功的年份。去年全球社区最大的里程碑之一是 OpenStack,作为最活跃的三大开源项目之一,拥有 1500 万个核心在生产环境中运行,在 2020 年迎来了它的 10 周年。
Ussuri
5 月 13 日,在来自 50 个国家的 1000 多名贡献者的帮助下,OpenStack 社区发布了它的第 21 个版本,Ussuri。该版本的重点是核心基础设施层的可靠性、增强的安全性和加密性,以及对边缘和容器环境等新兴用例的通用性。作为社区,我们的目标是使 OpenStack 的代码库仅支持 python3(放弃 Python 2.7 支持)并标准化我们针对项目特定贡献者文档的方法。
- https://openstack.org/software/ussuri/
- https://governance.openstack.org/tc/goals/selected/ussuri/index.html
Victoria
在 2020 年晚些时候,OpenStack 社区发布了 Victoria,OpenStack 的第 22 个版本。原生 Kubernetes 集成是主要关注点之一;例如,Kuryr 实现了对自定义资源定义的支持,因此它不必使用注释来存储有关 OpenStack 对象的信息到 k8s API 中。更普遍地说,还添加了功能以支持更多样化的架构和标准,例如 FPGA 的直接编程和额外的 TLS 支持。该版本的其他社区目标是将上游 CI/CD 测试迁移到新的 Ubuntu LTS Focal,并将最后从 Jenkins 作业自动派生的旧 Zuul 作业切换到原生 Zuul v3 作业。160 个组织、45 个国家和近 800 名社区成员共同努力使 Victoria 版本取得成功!我们感谢他们为 OpenStack 做的辛勤工作和奉献精神。
- https://openstack.org/software/victoria/
- https://governance.openstack.org/tc/goals/selected/victoria/index.html
新的 SIG
TaCT
Testing and Collaboration Tools (TaCT) SIG 的创建是为了承担 OpenStack Infrastructure 团队以前的角色,并支持 OpenStack 项目特定的测试和协作工具和服务。OpenStack Infrastructure 团队以前存在是为了维护 OpenStack 社区赖以生存的持续集成和协作基础设施。随着 OpenDev Collaboratory 的兴起,Infrastructure 团队以前的系统、管理活动和配置管理存储库不再受 OpenStack 的管辖。TaCT SIG 与 OpenDev 项目合作,维护支持 OpenStack 项目开发过程和测试所需的工具和基础设施。
Large Scale
该小组的成立是为了促进 OpenStack 在大规模上的运行,解答 OpenStack 运维人员在需要扩展和缩放时遇到的问题,并帮助解决大型 OpenStack 集群中运维人员遇到的限制。该小组的工作围绕着 OpenStack 部署增长过程中的各个阶段展开。
它从起始配置阶段开始,涵盖监控、扩展、缩放和升级维护。许多人已经成功地走过了这条道路。SIG 的工作是提取这些知识,并为后来者提供答案。
Hardware Vendor
该 SIG 的目标是提供一个供供应商以及对供应商特定事物(如驱动程序和支持库)感兴趣的人们合作和公开协作的地方,以使 OpenStack 服务能够集成并与所有硬件平台良好地协同工作。Hardware Vendor SIG 仍在形成和发展中,目前拥有并管理 Dell DRAC 的 Python 客户端。该 SIG 目前欢迎其他供应商托管他们的项目。
Technical Committee 变更
TC/UC 合并
长期以来,OpenStack 社区一直有两个委员会帮助指导他们的工作。虽然拥有两个视角提供指导是好的,但不幸的是,这种方法最近导致了我们社区内的孤立。2020 年,Technical Committee 和 User Committee 合并为一个组织,这也导致了 TC 选举过程的一些变化。从 2020 年 8 月 1 日开始,当举行 Technical Committee 选举时,Active User Contributors 也包含在选民中,以便他们对自己的代表拥有平等的发言权。将 Technical Committee 作为统一的组织消除了开发人员和运维人员之间的区别,使他们都成为平等的贡献者。这意味着运维人员可以竞选委员会席位,他们只需要做出贡献即可获得资格,例如报告错误、进行代码或文档更改等。同时,社区和 Technical Committee 中的开发人员被鼓励承担积极用户贡献者的任务,并确保运维人员的平等代表性。
TC 规模变更
在 2020 年全年,在每次技术选举中,我们将 Technical Committee 的规模减少了两个人,降至目前的 9 名成员。TC 的规模是在获得足够的社区代表性和保持足够的成员参与度和活跃度之间的权衡。在此次变更之前,规模(13 名成员)是在 2013 年定义的,当时我们从 5 个直接选举的席位 + 所有 PTL(这将是 14 人)转变为能够更好地应对我们爆炸性增长的模型。从那时起,13 人在确保每个周期都有新成员加入方面都做得很好。为了避免人员倦怠,并保持新贡献者不断地进入委员会,我们决定减少规模。因此,委员会迎来了 Dan Smith 和 Belmiro Moreira 等长期开发人员和运维人员的加入。
项目变更
作为一个不断发展的项目,OpenStack 在 2020 年进行了一些治理和流程相关的变更,以确保社区和项目团队的可维护性和高效运行。
分布式项目领导力概念在下半年宣布,以帮助团队更好地在彼此之间分担责任。如果一个项目团队选择这种模式,这意味着他们将没有专门的项目团队负责人 (PTL)。指导项目所需的任务由联络人承担;三个必需的角色是发布、tact-sig 和安全联络人。一个人或多个人可以担任这些角色没有明确的指导。还有一些建议的角色可以承担,以执行诸如为活动准备团队或确保顺利的新贡献者入职流程等任务。分布式领导力模式不影响现有的模式,例如 PTL 与联络人。
为了提高 Technical Committee 的效率,对项目进行更新的过程变得更快。例如,向项目添加新存储库或向其存储库添加标签,即使 TC 已经添加了足够的投票,也需要等待一周的时间。在新流程中,TC 成员对变更投赞成票即可由主席批准请求,无需等待期。如果合并变更后存在异议,则可以撤销该变更,然后通过“正式投票”流程,以确保在做出决定之前进行充分的讨论。
- 分布式领导力
- 加快添加项目流程
- 项目退役?
- 简化?
- 为新项目腾出空间?
标签
支持独立运行
虽然 OpenStack 服务协同工作良好,但有些用户可能不想运行所有服务,并且可能更喜欢其他技术来替代项目的某些核心组件。因此,一些服务已被修改,以便它们可以独立于 OpenStack 的其余部分运行(例如,Cinder Storage 与 Kubernetes 集群),而不会失去其核心功能。为了轻松识别哪些服务可以独立运行而无需其他 OpenStack 服务,它们被标记为“支持独立运行”。
Kubernetes Starterkit
Kubernetes 已成为运行容器化应用程序的首选容器编排系统,通常在云平台之上运行。作为这些平台之一,OpenStack 可以为不同的 Kubernetes 集群提供多租户隔离。由于 OpenStack 具有构建基础设施的许多服务,因此确定用作 Kubernetes 基本的最小集合可能具有挑战性。Kubernetes starter kit 标签推荐了一组最小的 OpenStack 服务,以向 Kubernetes 和工作负载提供必要的资源来运行。
Open Infrastructure 基金会衷心感谢全球社区为 2020 年所做的一切工作,并继续在 2021 年努力帮助人们构建和运营开放基础设施。请查看 OpenInfra 基金会年度报告中 OpenStack 社区在 2020 年的成就,并加入我们,共同构建未来十年的开放基础设施!
https://openstack.org/annual-reports/2020-openstack-foundation-annual-report
让我们为新的一年欢呼,并为过去几年播下的种子取得的成功发展干杯!
发表评论