OpenStack got its start at NASA, but open source communities have given it life. OpenStack's architecture is made up of numerous open source projects steered by IT professionals around the world. Red Hat takes part in many of those projects and continues to be a top corporate contributor to the OpenStack community. So, which projects within the OpenStack community matter most to telecommunications service providers? This Q&A with Thomas Nadeau, Red Hat’s technical director for NFV, explores the OpenStack community and telco-centric projects, the work the community is doing now, and how to get involved.

What does Red Hat’s “upstream first” philosophy mean for Red Hat’s customers?

This philosophy means that the code used to create our enterprise-class, fully supported downstream products – either direct distribution of upstream projects or aggregates of multiple projects combined into a single, supported product – is shared and developed with the work done by the full OpenStack community.

This is quite important as it puts all the cards on the table so to speak about agendas or features. There are many advantages to this, including, but not limited to, building and developing solutions from these distributions within a larger ecosystem that includes our partners and customers. It also means that along with our upstream partners, we can more easily build solutions that are bigger (and we believe better) than any single corporation can hope to build and maintain. Kubernetes, which we use to create our downstream product called Red Hat OpenShift Container Platform, and Red Hat OpenStack Platform (OSP), are perfect examples. (Here’s a great description of Red Hat’s upstream philosophy.)

Why is the community so critical to OpenStack development and adoption, and how involved is Red Hat in the OpenStack community?

The upstream community is critical for many reasons. First, as I explained earlier, it would be very difficult for any one organization to develop and maintain such a massive project on its own. Not only would they need sizable  engineering resources to work on the code, but also other supporting functions, such as sales, support, and testing.

Secondly, a community that builds projects like this often builds them in ways that suit a wider set of end customer use cases simply because of the diversity of the contributors’ downstream customers. This makes the project more broadly applicable and allows the project to enjoy a certain economy of scale. To illustrate this, imagine starting two OpenStack projects with similar outcome goals. Then consider the impact the combined teams would have and the overhead eliminated with a single, cohesive project.  

Finally, the code for these projects is often high quality. Attracting the best and brightest developers is tough on such a large project. However communities often solve this by having developers and contributors from a diverse pool of backgrounds and companies.

How does the community work? What’s the process for getting involved? It is first important to understand that any open source project’s community has many components beyond the obvious software developers. There are project managers, marketing, CI/CD, testing, and documentation components that are all critical to the success of these projects. individuals can get involved in any of these areas.

To get started, visit the OpenStack Community welcome page to find the sections that best suit your interests. From there you can dive into the subproject or area of your choice.  

How are new projects created, and how does the work done in the projects progress into documentation and implementation?

New open source projects are created in different ways depending on the umbrella organization shepherding the project (i.e., The Apache Software Foundation, The Linux Foundation, etc.). That said, a project typically starts with the creation of a sub-organization that has some form of governance rules and a charter. Then, the primary project creators often make an initial code drop. For OpenStack, projects are first created in a few ways. One way is to informally create a project.

As the code grows in functionality, the community reaches a critical mass around it. At that point, a blueprint for the project is created and proposed to the Technical Steering Committee (TSC) for formal inclusion. Alternatively the TSC can create a project by invoking its blueprint as part of their formal planning process ahead of each major release. Those blueprints are vetted and voted for by the TSC.

There are probably more community projects important to telco than we have time to discuss, but what are some of the key projects today’s service providers (SPs) should be aware of? What problems are these projects aiming to solve for SPs and their customers?

We have significant investment and efforts in a wide range of open source networking projects that pertain to telecommunications service providers. They include our downstream products as well as some more forward-looking ones that do not have downstream products at this time. Many can be found in the Linux Foundation’s Networking (LFN) umbrella area.

The importance of any project to SPs really depends on each provider’s specific goals. I would say there is no one most important project, but some of the key projects we at Red Hat are working on are OpenDaylight Project, Open Virtual Switch (OVS), FD.io, Open Platform for Network Functions Virtualization (OPNFV), Open Network Automation Platform (ONAP), Akraino Edge Stack, and Data Plane Development Kit (DPDK). We also have significant efforts in the Cloud Native Container Foundation.

Why should SPs be involved in the OpenStack community?

SPs should definitely get involved because it is a way for them to  be part of the community and drive what functions and features are added to projects. Since those projects form downstream products offered by Red Hat and others, they can influence products they consume through bringing requirements to the project, helping with project testing, or directly contributing source code to the projects themselves.

The latest OpenStack release – Rocky – came out this past August. What can you tell us about the benefits and advantages it will bring SPs?

Rocky provides important operational enhancements for ease of use and adds better support for “bare metal” deployments, “remote” clusters, and support for containers. Look for further enhancements to these functions as we move to the next release.

Looking ahead, what are some of the most exciting developments underway in the OpenStack community?

I have to say that I am most excited about the support for container functions, as well as the networking enhancements to support them. As a project matures, new functionality for it often wanes. These days the rapid rate of technology evolution means that any pause in development that lasts too long could quickly make a platform irrelevant. The OpenStack community realized that support for containers was “the next big thing,” rapidly moved to add it and is continuing to enhance it.