Skip to content
CloudOps
Newsletter
All prompts
AI for OpenStack Difficulty: Intermediate ClaudeChatGPT

Ironic Node Cleaning & Lifecycle Debug Prompt

Diagnose Ironic bare-metal nodes stuck in cleaning, clean-wait, or maintenance — covering the state machine, clean steps, ramdisk logs, and conductor takeover so nodes return to available.

Target user
Operators troubleshooting Ironic bare-metal provisioning state
Difficulty
Intermediate
Tools
Claude, ChatGPT

The prompt

You are a senior OpenStack bare-metal engineer who has debugged Ironic node lifecycle stalls across IPMI, Redfish, and agent-based drivers.

I will provide:
- `openstack baremetal node show <node>` (provision_state, last_error, maintenance, driver, power_state)
- The node's driver and BMC type (ipmi/redfish/ilo)
- Clean-step config (automated_clean, cleaning_network, erase_devices vs metadata)
- Conductor logs and ramdisk (IPA) logs if available
- Symptoms (stuck in `cleaning`/`clean wait`/`clean failed`, node in maintenance, won't reach `available`)

Your job:

1. **State-machine orientation** — locate my node in the Ironic state machine (enroll → manageable → available → active, plus cleaning/clean-wait/clean-failed) and explain the exact transition that's blocked.

2. **Cleaning path** — trace automated cleaning: node powers on the IPA ramdisk → ramdisk runs clean steps (erase_devices, BIOS/RAID) → reports back to conductor. Identify whether the stall is BMC/power, network/PXE to the cleaning network, or a failing clean step.

3. **Ramdisk reachability** — check the cleaning network, DHCP/PXE, and conductor↔IPA callback; the most common stall is the ramdisk never calling back (`clean wait` forever).

4. **Clean-step failures** — interpret `last_error`, decide whether to skip/abort a hardware step (e.g. disk erase timing out on a bad drive), and how `erase_devices_metadata` vs full erase changes timing.

5. **Maintenance & conductor** — clear stale `maintenance`, handle a dead conductor (node ownership/takeover), and when `--reset` or moving the node to `manageable` is safe.

6. **Recovery commands** — the correct sequence: `node abort`, `node manage`, fix root cause, `node provide`, and re-verify it reaches `available`.

7. **Prevention** — config and BMC/firmware checks to stop recurrence.

Output as: (a) state-machine diagnosis pinpointing the blocked transition, (b) ranked root causes with confirming log/command for each, (c) ramdisk/PXE debug cheat sheet, (d) safe recovery command sequence, (e) prevention checklist.

Bias toward: confirming "ramdisk never called back" vs "clean step failed" before acting, and never forcing state with `--force` blindly.
Newsletter

Free: the DevOps AI Incident-Triage Cheat Sheet

Subscribe and we’ll send you the one-page cheat sheet — plus weekly AI prompts, automation ideas, and tool reviews for infrastructure engineers. One email a week. No spam, unsubscribe anytime.

  • AI Incident-Triage Cheat Sheet (PDF)
  • Access to 1,603 DevOps AI prompts
  • One practical workflow email per week