DevStack turns git branches into a runnable OpenStack cloud

stack.sh is the whole entry point, and it refuses root

DevStack is Shell rather than a packaged installer, and the top level of the repository shows how little abstraction sits between you and a running cloud. `stack.sh` starts one, `unstack.sh` is its counterpart, `clean.sh` clears material away, and `functions` and `functions-common` carry the shared shell logic, with `inc/`, `lib/`, `roles/`, `files/`, `data/`, `gate/`, `extras.d/` and `playbooks/` arranged around them. DevStack declares 5 goals, from building dev environments on Ubuntu or RockyLinux to giving OpenStack CI somewhere to run on every commit. What it adds up to is a scripted rebuild from git source trees, which is why branch names rather than downloaded archives decide what you end up running.

sudo handles privilege, a login account handles everything else

`stack.sh` needs root access for a lot of tasks but calls `sudo` for each of them, and it needs to run as a non-root account for most of its work and for all of the OpenStack services. Started as root it will not run at all. That split explains the rest of the guidance around it: the scripts install software and alter your networking configuration, the project asks you to read `stack.sh` and any other script before executing it, and it tells you to do the first run in a clean and disposable VM rather than on your own machine. DevStack does not create that account either. `tools/create-stack-user.sh` exists to set one up, or to document what DevStack expects of it, and the README says to run that helper as root while many people just use their usual login, such as the default 'ubuntu' account on a UEC image.

Branch names, not artifacts, decide which OpenStack code lands

Version choice here is a git operation, and it happens at two levels. The master branch generally points at trunk versions of the OpenStack components. For older, stable clouds you look for branches named `stable/[release]` in the same repository, check one out, and run the same script you already know:

git checkout stable/zed
./stack.sh

Narrower control works per project. Setting the appropriate `*_BRANCH` variable in the `localrc` section of `local.conf` pins a single OpenStack project to a chosen branch, and the default set of those variables lives in `stackrc`. Milestone-proposed branches are created for testing ahead of a stable cycle, and the README shows the shape of that override:

GLANCE_REPO=https://opendev.org/openstack/glance.git
GLANCE_BRANCH=milestone-proposed

Two files therefore decide the version of a cloud: the DevStack branch sitting on disk, and the `*_BRANCH` values in your own configuration file.

local.conf overrides defaults that already live in stackrc

Anything beyond the most basic setup means writing `local.conf` yourself. The repository ships `samples/local.conf` and `samples/local.sh` as starting points, and the project sends readers to `docs.openstack.org/devstack/latest/configuration.html` for the full option list. The two-file split is what makes per-project pinning practical. `stackrc` holds the shared defaults, including the branch variables, and the `localrc` section of `local.conf` overrides them, so your values win without anyone editing tracked files. Read `stackrc` when you want to know what a variable was before you overrode it. Read `local.conf` when you want to know what this particular cloud will do, because the file you wrote is the one the run honours.

The Makefile keeps a second copy of the install prefix

Reading the Makefile top to bottom shows the daily verbs of the project. The `stack` target runs `./stack.sh`, `unstack` runs `./unstack.sh`, `clean` calls `./clean.sh`, and `test` runs 4 shell scripts: `tests/test_ini_config.sh`, `tests/test_meta_config.sh`, `tests/test_ip.sh` and `tests/test_refs.sh`. The first target is a guard rather than a build, and the line it echoes is `This just saved you from a terrible mistake!`. One entry is a small lesson in configuration drift: `DEST=/opt/stack` sits under the comment `Duplicated from stackrc for now`, so the install prefix is defined twice, and changing it in `stackrc` alone leaves the Makefile pointing at the old path. The remote testing targets keep a second layer of state as well, with `GIT_REMOTE_NAME` and `GIT_REMOTE_BRANCH` both set to `ds-test` while `DS_REMOTE_URL` has to be supplied on the command line.

clean leaves downloaded images behind until realclean runs

The two cleaning targets in that Makefile remove different amounts of material. `clean` takes out the local leftovers `accrc`, `doc/build`, `test*-e` and `*.egg-info`. `realclean` depends on `clean` and then deletes the cached images under `files/`, namely `files/cirros*.tar.gz` and `files/Fedora*.qcow2`, while the `clean` target itself removes nothing from `files/`. The name `accrc` is the detail worth pausing on. The README tells users to source `openrc` for CLI credentials, and `openrc` is listed in the repository tree, yet `clean` removes a differently named credentials file that the README never mentions. 2 names, 1 documented. Anyone auditing what a run leaves on a machine has to read `clean.sh` rather than assume the README covers it.

GitHub holds a mirror while opendev.org holds the source

openstack/devstack on GitHub is a mirror. The repository description says the code is maintained at opendev.org, and the homepage points at `https://opendev.org/openstack/devstack`. The file layout follows from that upstream workflow: `.gitreview` for review, `.zuul.yaml` and `gate/` for continuous integration, `run_tests.sh` as a test entry point, and `tox.ini` holding the environments the `bashate` and `docs` targets drive through `tox -ebashate` and `tox -edocs`. `docs-build` takes a different route and sets `INSTALL_SHOCCO=True` before calling `tools/build_docs.sh`, while `docs-rst` goes through `python setup.py build_sphinx`. The repository has no GitHub releases, and the last push to the mirror was on 2026-09-24. For anyone tracking work on this project, the opendev.org history is where changes are recorded.

A first cloud in a disposable virtual machine

Write `local.conf`, pick your guest OS, then start the cloud with a single command:

./stack.sh

Run it as an ordinary login account, never as root. When it finishes, 2 endpoints answer on the host: Horizon at `http://myhost/` and Keystone at `http://myhost/identity/v3/`, where the path ends in version 3. Command line work starts from the environment file the repository ships:

. openrc
openstack server list

The run changes the network configuration of that machine, so snapshot the VM before you start and throw the snapshot away when the test is over. `unstack.sh` is the script that pairs with `stack.sh`, and the stated purpose is blunt: this exists for testing and development, not for a machine anyone depends on.

Editorial conclusion

DevStack is the right tool when the job is an OpenStack cloud that can be destroyed and rebuilt between commits, and the wrong tool for any machine a team depends on. It installs services, changes networking and expects a disposable VM, so production use is out of scope by design. Before the first run, pick the guest OS between Ubuntu and RockyLinux, create the non-root account yourself or read tools/create-stack-user.sh, and write local.conf instead of editing stackrc. Confirm which branch is checked out before ./stack.sh installs from it.

Frequently asked questions

Official sources

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