DevStack local.conf Explained: Configuration Options and Examples

Every time you deploy DevStack, the file you edit most is local.conf. It is the configuration file that tells stack.sh what passwords to use, which host IP to bind to, and which OpenStack services to enable or disable. Treat it as the single source of truth for a DevStack deployment — get local.conf wrong, and the stack either misbehaves or is unreachable.

Here is the situation. You have cloned DevStack and you are about to run stack.sh, but you need to tell it how to configure itself. Without local.conf, DevStack either prompts interactively or falls back to defaults that may not match your network. You write local.conf once per deployment, review it carefully, and then run the installer. Below is how to approach it, the sections that matter, and the mistakes to avoid.

Table of Contents

What local.conf is

local.conf lives in the root of the cloned DevStack directory. It is a modified INI-format file that uses meta-section headers to group configuration. The OpenStack documentation describes it as the file where DevStack configuration is modified, and it overrides the default installation behaviors, credentials, and enabled services.

The most important section is [[local|localrc]]. Variables written under it are treated as shell variables and injected directly into the DevStack build sequence. That is why syntax matters — a typo here can change how the entire stack is built.

The localrc section to start with

Here is the minimal local.conf for a typical all-in-one deployment:

[[local|localrc]]
# Password configuration
ADMIN_PASSWORD=SecretPassword123
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD

# Host network environment
HOST_IP=192.168.1.50

# Target destination directory
DEST=/opt/stack

# Logging configuration
LOGFILE=$DEST/logs/stack.sh.log
LOGDAYS=2

What each setting does:

Setting	Purpose
`ADMIN_PASSWORD`	Password for the admin account in Keystone and Horizon
`DATABASE_PASSWORD`	Password for the MariaDB / MySQL database
`RABBIT_PASSWORD`	Password for the RabbitMQ message queue
`SERVICE_PASSWORD`	Service account password used between OpenStack components
`HOST_IP`	The physical IP of your host. Set this explicitly so DevStack does not guess the wrong network interface.
`DEST`	The directory where DevStack installs code and data. Use `/opt/stack`.
`LOGFILE` / `LOGDAYS`	Where stack.sh writes its log and how many days of logs to keep.

The reasoning for setting these explicitly rather than relying on defaults: if HOST_IP is wrong, services bind to the wrong address and Horizon becomes unreachable. If you do not set passwords, DevStack may prompt interactively, which breaks unattended or scripted installs. You can use grep and sed to search through existing configuration files for patterns you want to replicate in your own local.conf. If you are unfamiliar with how shell variables and quoting work when writing values like $ADMIN_PASSWORD, our Bash parameter expansion and quoting reference covers the rules that apply.

Enabling and disabling services

DevStack installs a default set of OpenStack services, but you often want to enable or disable specific ones. Do this in local.conf with disable_service and enable_service.

# Example: enable Neutron networking services
disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta

The judgment here: only enable services you actually need. Every additional service adds install time, memory use, and complexity. For a minimal learning stack, keep the defaults. For a focused test of networking, enable the Neutron pieces and disable the legacy nova-network (n-net).

Post-config modifications

Sometimes you need to tweak a specific OpenStack service configuration file during the post-config phase. local.conf supports INI-style blocks for this. For example, to set a Nova option:

[[post-config|$NOVA_CONF]]
[DEFAULT]
instance_usage_audit=True
instance_usage_audit_period=hour

The reasoning: $NOVA_CONF is a variable DevStack resolves to Nova’s configuration file path. Use this sparingly, because post-config hacks make the stack harder to reproduce. If you find yourself adding many of them, reconsider whether DevStack is still the right tool for what you are trying to do.

Common mistakes to avoid

Guessing HOST_IP

Always verify HOST_IP against the output of ip addr on the VM. A wrong value means services listen on the wrong interface and you cannot reach Horizon from your browser.

Forgetting the [[local|localrc]] header

Without the meta-section header, DevStack does not interpret the variables correctly. Double-check the header is present and spelled exactly as [[local|localrc]].

Using weak or inconsistent passwords

In a lab you might set all four password variables to the same value for convenience, but never use an obviously weak password like password or leave them blank. Even a disposable stack should not have trivial credentials.

Editing local.conf after running stack.sh

local.conf is read when stack.sh runs. If you change it afterward and expect the running stack to pick up the change, you will be disappointed. To apply new configuration, re-run stack.sh — or better, tear down with unstack.sh/clean.sh and start fresh.

What local.conf rewards

local.conf is the part of DevStack that rewards care. It is short — often under thirty lines — but it controls passwords, networking, services, and logging. Write it deliberately, verify HOST_IP, and treat it as something you will re-read every time you rebuild the stack. It is not a file to copy from a tutorial and forget; it is the configuration you own.