DevStack source and package pinning behavior across OpenStack releases
0 reputation · 06 Jul 2025, 03:26 UTC
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?