OpenStack GitHub Repository: A Submodule Tracker for Tested Component Combinations

What This Repository Is and What It Is Not

OpenStack is a large open-source infrastructure platform that provides computing, networking, and storage resources through programmable APIs. The openstack/openstack repository on GitHub is a read-only mirror that represents the entire OpenStack project as a collection of git submodules. It does not contain the deployable OpenStack code itself; that lives in individual component repositories at opendev.org/openstack.

The README is explicit: "This repo is intended to be used in a read-only manner." Its purpose is to capture the specific sequence of component commits that the Zuul continuous integration system has tested together. A developer looking for the Nova compute service code should go to opendev.org/openstack/nova; someone looking for a specific combination of Nova, Neutron, and Cinder commits that have all passed integration testing together should look at a commit in this super-project.

The repository uses Gerrit's submodule tracking feature to update the super-project automatically whenever any subproject receives a tested commit from Zuul. The result is a timeline of verified combination snapshots.

How the Zuul CI System Creates the Submodule Timeline

OpenStack's continuous integration infrastructure uses Zuul, a project gating system that gates all contained projects in what the README describes as "an effective single timeline." When a change lands in one OpenStack component, Zuul tests it against the current heads of related components before merging. If the combination passes, both the component repository and the super-project are updated together.

This creates a practical tool for anyone who needs to answer the question: given a specific commit in one component, what commits in all other components were tested with it? Without the super-project, tracing that back is non-trivial because Zuul's testing history is not directly exported in a navigable format. With the super-project, a git log or git bisect on the super-project repo gives a chronological sequence of integration-tested states.

The .gitmodules file at the repository root defines the tracked submodules. The repository's top-level entries include dozens of OpenStack projects and related Ansible roles, covering services like Aodh (alarming), Barbican (key management), Blazar (reservations), Ceilometer (telemetry), Cinder (block storage), and many others, along with Ansible roles for system configuration tasks and charm packages for Juju deployments.

Because this is a mirror of opendev.org/openstack/openstack, releases are not published on GitHub. The project's last push was on 2026-09-27, confirming that submodule tracking remains active.

Who Should Use This Repository and How

The primary use case is reproducibility. An infrastructure operator deploying OpenStack who wants to know exactly which component versions have been tested together can check out a specific commit of this repository and read the submodule SHAs. Those SHAs point to the exact commits of each component that passed the Zuul gate at that point in time.

A secondary use case is historical research: comparing the submodule pointers across super-project commits reveals the pace at which each component advances and whether particular components are stable or moving quickly.

For anyone deploying OpenStack, this repository is a reference rather than an installation source. The README points to openstack.org/software for information on components and openstack.org/community for contribution guidance. The actual installation tooling, such as Kolla-Ansible or TripleO, lives in its own repositories under opendev.org.

The Apache-2.0 license applies to the repository's own content, which in practice is the README and the .gitmodules file. The individual component repositories carry their own licenses.

Limitations: No Deployment Logic, No Releases, Read-Only Mirror

The repository contains no deployment scripts, no configuration files, and no installer. Anyone who arrives here expecting to find a way to set up OpenStack will need to navigate to the actual component repositories or to deployment tools.

Because it is a mirror, pull requests and issue reporting are not the right way to contribute to OpenStack through this repository. The README directs contributors to the Gerrit-based workflow at the contributor portal rather than GitHub pull requests.

The repository also does not carry version tags in the conventional semantic versioning sense. OpenStack uses a named release cycle (such as Antelope, Bobcat, and Caracal) rather than a global version number across all components. Finding the commits that correspond to a named OpenStack release requires checking the individual component repositories and the OpenStack governance documentation at governance.openstack.org, not this super-project.

For teams who need to know OpenStack's governance structure, the README points to governance.openstack.org, which documents how the project is organized and decisions are made.

OpenShift as the Main Architectural Alternative

The most commonly compared alternative to OpenStack is OpenShift, Red Hat's Kubernetes-based container platform. The difference in approach is fundamental: OpenStack is a virtual machine-centric infrastructure-as-a-service platform, providing raw compute, network, and storage that operators provision and manage. OpenShift is a platform-as-a-service built on Kubernetes, focused on containerized workloads with managed developer workflows.

OpenStack is the right choice when the goal is to build a private cloud that behaves like AWS in terms of VM-level control, with tenants allocating instances, volumes, and networks. OpenShift is oriented toward teams who want to run containerized applications with built-in CI/CD and orchestration rather than managing VMs.

The two are not mutually exclusive; some organizations run OpenShift on top of OpenStack, using OpenStack to provide the IaaS layer that OpenShift nodes run on. Neither project belongs to the other, and both are independently maintained.

How OpenStack Is Governed and Where the Real Code Lives

OpenStack is governed by the OpenStack Foundation, which is distinct from any single vendor. The governance documentation at governance.openstack.org describes the project team guide, the technical committee, and how decisions are made. This separates OpenStack from infrastructure projects that are controlled primarily by one company.

All active development happens on Gerrit at opendev.org, not on GitHub. The GitHub presence is a mirror maintained to give the project visibility on the platform where many developers first look. Contributors who want to submit patches or file bugs should use the Gerrit workflows documented at the contributor portal.

Individual OpenStack components, such as Nova (compute), Neutron (networking), and Swift (object storage), each have their own project teams, release schedules, and governance structures. The super-project on GitHub reflects the output of all of those teams' work passing through the shared Zuul CI gate.

Editorial conclusion

This specific repository is the right starting point for anyone who needs to identify a tested combination of OpenStack component commits at a specific point in time. It is not the right place to learn how to deploy or operate OpenStack: the documentation at openstack.org and the individual component repositories at opendev.org serve those purposes. For operators who need reproducibility in their OpenStack deployments, checking out a commit from this repository gives a Zuul-verified snapshot. For developers contributing to OpenStack, the CONTRIBUTING section directs to the contributor portal at openstack.org, and the actual project repositories live on opendev.org rather than GitHub.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. openstack/openstack on GitHub
4. Project website
5. README