OpenStack Project Update 2020

Despite being a very different year than most, the Open Infrastructure community, which has over 110,000 community members, made it a productive and successful year. One of the biggest milestones that happened in the global community last year was that OpenStack, one of the top three most active open source projects with 15 million cores in production, marked its 10th anniversary in 2020.


On May 13th, with the help of over 1,000 contributors spanning 50 countries, the OpenStack community released its 21st version, Ussuri. The focus areas of the release were reliability of the core infrastructure layer, enhanced security and encryption, and versatility for emerging use cases like edge and container environments. As a community, our goals were to make OpenStack’s codebase be python3-only (dropped Python 2.7 support ) and standardize our approaches to project specific contributor documentation.


Later in 2020, the OpenStack community released Victoria, OpenStack’s 22nd version. Native Kubernetes integration was one of the primary focus points; Kuryr, for example, implemented support for custom resource definitions so that it won’t have to use annotations to store data about the OpenStack object in the k8s API. More generally, there were also features added to support more diverse architectures and standards, such as direct programming of FPGA’s and additional TLS support. Other community goals for the release were migrating upstream CI/CD testing to the new Ubuntu LTS Focal and switching the last of the legacy Zuul jobs that were automatically derived from their Jenkins job to native Zuul v3 jobs. 160 orgnanizations, 45 countries, and almost 800 community members worked together to make the VIctoria release a success! We thank every one of them for their hard work and dedication to OpenStack.

New SIGs


The Testing and Collaboration Tools (TaCT) SIG was created to serve the role previously occupied by the OpenStack Infrastructure team and support OpenStack’s project-specific testing and collaboration tooling and services. The OpenStack Infrastructure team formerly existed to care for the continuous integration and collaboration infrastructure on which the OpenStack community relies. With the rise of the OpenDev Collaboratory, the majority of the Infrastructure team’s former systems, administration activities, and configuration management repositories were no longer occurring under the authority of OpenStack. The TaCT SIG maintains, in cooperation with the OpenDev project, the tooling, and infrastructure needed to support the development process and testing of the OpenStack project.

Large Scale

This group was formed to facilitate running OpenStack at a large scale, answer questions that OpenStack operators have as they need to scale-up and scale-out, and help address some of the limitations operators encounter in large OpenStack clusters. The work of the group is organized along the various stages in the scaling journey for someone growing an OpenStack deployment.

It focuses from the starting configuration stages and goes through monitoring, scaling up, scaling out and upgrading and maintaining. That path was successfully traveled by many before. The job of the SIG is to extract that knowledge and provide answers for those who come next.

Hardware Vendor

The goals of this SIG is to provide a place where vendors, and those interested in vendor-specific things like drivers and supporting libs, can work together and collaborate openly to enable OpenStack services to integrate and work well on all hardware platforms.The Hardware Vendor SIG is still forming and growing and it currently owns and manages the Python client for Dell’s DRAC. The SIG is currently welcoming for other vendors to host their projects too.

Technical Committee Changes

Merging of TC/UC

For a long time, the OpenStack community has had two committees helping to direct their efforts. While it was great to have two perspectives giving guidance, unfortunately this approach recently lead to some siloing within our community. In 2020, the Technical Committee and User Committee meld into one group, which also resulted in some changes of the election process for the TC. Starting August 1st of 2020, when Technical Committee elections are held, Active User Contributors are also included in the the electorate so that they have equal say in their representation. Having the Technical Committee as a united group removes the distinction between developers and operators even more and makes them all equal contributors. This means that operators can run for seats in the committee, where they only need to make contributions to be eligible, that can be reporting bugs, making code or documentation changes, etc. At the same time the developers in the community and on the Technical Committee are encouraged to take on active user contributor tasks and ensure equal representation of operators.

TC Size Change

Throughout 2020, at each of the technical elections, we reduced the size of the Technical Committee by two people down to our current size of 9 members. The size of the TC is a trade-off between getting enough community representation and keeping enough members engaged and active. Before this change, the size (13 members) was defined in 2013, as we moved from 5 directly-elected seats + all PTLs (which would have been 14 people) to a model that could better cope with our explosive growth. Since then, 13 had worked well to ensure that new members could come in at every cycle untill recently. To avoid burning people out, and keep infusions of new contributors being cycled into the committee, we decided to reduce the size. As a result, the committee has been joined by long term developers and operators like Dan Smith and Belmiro Moreira.

Project Changes

As a continuously evolving project OpenStack went through a few governance and process related changes over 2020 to ensure maintainable and efficient operation of the comunity and the project teams.

The concept of distributed project leadership was announced during the second half of the year to help the teams to share responsibilities among themselves better. If a project team opts in to this model that means they will not have a dedicated Project Team Lead (PTL). The necessary tasks to guide the project are taken on by liaisons; the three required roles are release, tact-sig and security liaison. There is no guideline if one or more people fill in these roles. There are also some additional recommended roles to take on to perform tasks such as preparing the team for events or ensure a smooth process to onboard new contributors to the team. The distributed leadership model doesn’t affect existing models, such as PTL with liaisons.

In order to make the Technical Committee more efficient the process of making updates to a project became faster. Changes, like adding a new repository to a project or adding a tag to its repositories, required a one week waiting period even if enough votes from the TC were added to the review faster. In the new process two votes from TC members in favor to the change is enough for the chair to approve the request without a waiting period. In case there is a disagreement once the change is merged it can be reverted which than goes through the ‘formal vote’ process to ensure that enough discussion happens before making a decision.


Supports Standalone

While OpenStack services work well together, there are users that might not want to run all of them and might prefer other technologies over some of the core components of the project. As a result, some services have been modified so that they can be operated independent from the rest of OpenStack (e.g. Cinder Storage with a Kubernetes cluster) without losing their core functionality. In order to easily identify which services are able to be run standalone without other OpenStack services they are marked with the ‘Supports Standalone’ tag.

Kubernetes Starterkit

Kubernetes has become the go-to container orchestration system to run containerized applications, most commonly on top a cloud platform. As one of these platforms OpenStack can supply multitenant isolation between different Kubernetes clusters. As OpenStack has a number of services to build infrastructure with, it can be challenging to decide the minimum set to use as a base for Kubernetes. The Kubernetes starter kit tag recommends a minimal set of OpenStack services to provide the necessary resources to Kubernetes and the workloads to operate.

The Open Infrastructure Foundation would like to extend a huge thanks to the global community for all of the work that went into 2020 and is continuing in 2021 to help people build and operate open infrastructure. Check out the OpenStack community’s achievements in 2020 from the OpenInfra Foundation Annual Report and join us to build the next decade of open infrastructure!

Let’s cheer on the new year and to the successful growth of the seeds planted over these past years.

Leave a Reply

Your email address will not be published. Required fields are marked *