DevStack source and package pinning behavior across OpenStack releases

Question

Goal: make repeated DevStack deployments converge on identical OpenStack service code and package versions without ad hoc local.conf overrides.
DevStack defaults to checking out OpenStack services from Git master and installing distribution packages without version pinning through stack.sh. OpenStack does not publish a compatibility matrix that guarantees identical source revisions or package versions across releases. GIT_BASE and package pinning are available, but they are not centrally validated, and repeated stack.sh executions on the same host may leave state that affects later runs. Confirming drift would require comparing service Git revisions and package versions across repeated deployments.
Assuming DevStack runs on a supported Linux distribution with default stack.sh behavior, is source and package reproducibility a supported expectation or an operator-maintained assumption?

Can pinning GIT_BASE and distribution package versions guarantee identical service revisions across repeated deployments on the same base image?
What approach should define a repeatable DevStack baseline when OpenStack publishes no release-level compatibility matrix for Git sources and packages?
Is stack.sh re-execution expected to preserve previously checked out Git branches and installed package versions?

Tasadduq Burney · Answer

Reproducibility in DevStack Deployments
Source and package reproducibility in DevStack is an operator-maintained assumption, not a supported guarantee. By default, stack.sh is optimized for development velocity, pulling the latest commits from master and installing the newest available distribution packages. Without explicit pinning, repeated deployments will inevitably drift as upstream repositories evolve.

Analysis of Pinning and Convergence
Pinning GIT_BASE and STACK_RELEASE in local.conf provides a baseline, but it does not guarantee identical service revisions across repeated runs on the same host. This is because stack.sh does not perform a destructive reset of the environment; if /opt/stack contains existing data, the script may perform a git fetch or skip certain installation steps, potentially leaving stale artifacts.

Furthermore, stack.sh re-execution is not fully idempotent regarding system packages. While it attempts to update dependencies, it generally does not downgrade packages or remove orphaned dependencies left by a previous version. This can lead to "state leakage" where the underlying OS environment differs between a fresh image deployment and a re-executed stack.

Establishing a Repeatable Baseline
Since no official compatibility matrix exists for Git sources versus distribution packages, operators must define their own immutable baseline. The most reliable approach involves:

Commit-Level Pinning: Use specific Git commit SHAs rather than branch names in local.conf to prevent drift within a release branch.
  Environment Isolation: Use a fresh base image for every deployment. If reusing a host, execute ./unstack.sh and ./clean.sh (or manually purge /opt/stack) to ensure no previous state persists.
  Dependency Locking: Define specific versions for Python dependencies via PIP_INDEX_URL or requirements files where possible.

Verification Steps
To confirm whether drift has occurred between deployments, use the following scoped commands:
# Compare Git revisions across deployments
git -C /opt/stack/nova rev-parse HEAD

# Identify package version changes
dpkg -l | grep openstack # For Debian/Ubuntu
rpm -qa | grep openstack # For RHEL/CentOS

Assumptions: This guidance assumes the use of a supported Linux distribution and the standard stack.sh workflow. We assume the operator has root or sudo access to manage /opt/stack.

DevStack source and package pinning behavior across OpenStack releases

1 answer

Reproducibility in DevStack Deployments

Analysis of Pinning and Convergence

Establishing a Repeatable Baseline

Verification Steps

Your perspective belongs here.

0 question comments