Heat Nested Stack & ResourceGroup Index Design Prompt
Design maintainable Heat templates using nested stacks, ResourceGroup, conditions, and index_var so scaling and rolling updates don't replace the wrong resources.
- Target user
- Advanced Heat template authors building reusable infrastructure
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior Heat (HOT) template architect who builds reusable, update-safe nested stacks. I will provide: - OpenStack/Heat version and the template(s): parent stack, nested template(s), and any environment files - The intended structure: what should be a ResourceGroup, what should be a nested stack, what varies per index - The pain: updates replacing resources unexpectedly, ResourceGroup not scaling cleanly, conditions misfiring, or `index_var` collisions - Any `get_attr`/`get_resource` cross-references between parent and nested stacks Your job: 1. **Structure review** — assess whether ResourceGroup vs nested-stack vs `OS::Heat::AutoScalingGroup` is the right tool for each repeated unit, and why. 2. **Index hygiene** — verify `index_var`, `count`, and per-index naming so a scale-down removes the intended member, not a renumbered one. 3. **Update semantics** — predict which properties trigger replace vs update-in-place, and refactor to avoid surprise replacements during a stack-update. 4. **Conditions & params** — check `conditions`, `OS::stack_id` usage, and parameter wiring across the nested boundary. 5. **Cross-stack outputs** — validate `get_attr` paths into ResourceGroups/nested stacks resolve to stable references. 6. **Refactor output** — a cleaned template structure with comments explaining each update-safety decision. Output as: (a) a resource-structure decision table, (b) an annotated refactored template skeleton, (c) a "what a stack-update will do" prediction list. Run `openstack stack update --dry-run` (or preview) and read the predicted changes before applying any refactor to a live stack.
Why this prompt works
Heat’s most painful surprises come from update semantics, not from authoring the initial template. A ResourceGroup that scales fine on creation can remove the wrong member on scale-down if the per-index naming isn’t stable, and a property change you think is harmless can force a replace that destroys live infrastructure mid-update. This prompt centers the analysis on those update behaviors — which properties trigger replace, what a scale-down actually removes — because that is where real clouds get damaged and where template authors have the least intuition.
The structure-decision step prevents the common mismatch of reaching for the wrong abstraction. ResourceGroup, nested stacks, and AutoScalingGroup each have different update and scaling semantics, and choosing wrong makes everything downstream fragile. By forcing an explicit decision table with reasons, the prompt produces a design you can defend rather than a template that happens to work until the first update.
The preview/dry-run guardrail is the safety net that fits how Heat actually behaves: you can predict, before applying, exactly what a stack-update will create, replace, or delete. Pairing the AI’s refactor with a mandatory preview and a throwaway-stack test means the human verifies the destructive operations before they touch production — the AI drafts the structure, the operator confirms the blast radius.