🚨 OpenStack Error Guide: 'Resource CREATE failed: ResourceInError' Heat stack failure

Exact Error Message

$ openstack stack create -t app.yaml my-stack
$ openstack stack show my-stack -c stack_status -c stack_status_reason
+---------------------+-------------------------------------------------------------------+
| Field               | Value                                                             |
+---------------------+-------------------------------------------------------------------+
| stack_status        | CREATE_FAILED                                                     |
| stack_status_reason | Resource CREATE failed: ResourceInError: resources.app_server:    |
|                     | Went to status ERROR due to "Message: No valid host was found.",  |
|                     | Code: 500                                                         |
+---------------------+-------------------------------------------------------------------+

In the Heat engine log:

2026-06-27 14:22:09.514 11 INFO heat.engine.resource [-] CREATE: Server "app_server" [b3...]
Stack "my-stack" [9d...]
2026-06-27 14:22:09.514 11 ERROR heat.engine.resource ResourceInError: resources.app_server:
Went to status ERROR due to "Message: No valid host was found.", Code: 500

What the Error Means

ResourceInError is Heat reporting that one of the resources it created reached a terminal ERROR state in its owning service. Heat does not fail the resource itself — it asks Nova, Cinder, Neutron, or another service to build something, polls until the resource reaches a complete or error state, and when it sees ERROR, it wraps the underlying message in ResourceInError and fails the whole stack with CREATE_FAILED.

The crucial detail is the quoted clause: Went to status ERROR due to "<underlying reason>". That underlying reason — No valid host was found, Volume ... went into error state, Build of instance aborted, Block Device Mapping is Invalid — is the actual problem. ResourceInError is just the messenger. Fixing the stack means fixing the underlying service error, not Heat.

Common Causes

• Nova could not schedule the server — No valid host was found bubbles up from the compute scheduler (capacity, filters, or flavor).
• Cinder volume went to error — a OS::Cinder::Volume resource failed because the backend rejected the create.
• Block device mapping invalid — a boot-from-volume server references a volume or image size mismatch.
• Neutron port/network not ready — a referenced network, subnet, or port does not exist or failed to bind.
• Quota exceeded mid-stack — the stack’s combined resources crossed a project quota partway through.
• Bad template reference — a get_resource/get_attr points at a resource that itself failed, cascading the error.
• Image or flavor missing — the template names an image or flavor that is absent in the target project/region.

How to Reproduce the Error

Force the most common path — an unschedulable server:

1. Write a minimal Heat template with one OS::Nova::Server requesting a flavor larger than any available host can satisfy.
2. openstack stack create -t app.yaml my-stack.

Nova’s scheduler returns No valid host was found, the server resource goes to ERROR, and Heat fails the stack with Resource CREATE failed: ResourceInError. Pointing a OS::Nova::Server at a non-existent network reproduces the Neutron variant.

Diagnostic Commands

Read-only. Always start by extracting the underlying reason, then drill into the owning service.

# The full failure reason and which resource failed
openstack stack show my-stack -c stack_status -c stack_status_reason
openstack stack resource list my-stack --filter status=CREATE_FAILED
openstack stack resource show my-stack app_server -c resource_status -c resource_status_reason

# Heat's event timeline (chronological failure trail)
openstack stack event list my-stack --nested-depth 3

Then inspect the underlying resource directly:

# If the failed resource is a server
openstack server show <physical-resource-id> -c status -c fault

# If it is a volume
openstack volume show <physical-resource-id> -c status

# Engine logs
docker logs heat_engine 2>&1 | grep -i ResourceInError | tail        # Kolla-Ansible
journalctl -u openstack-heat-engine | grep -i ResourceInError | tail # Traditional

| fault | {'code': 500, 'message': 'No valid host was found. ', 'details': '...'} |

Step-by-Step Resolution

1. Read the quoted underlying reason from stack_status_reason. This single phrase determines which service you debug next — do not start changing the template until you know it.

2. Find the physical resource that failed:

   openstack stack resource show my-stack app_server -c physical_resource_id -c resource_status_reason

3. Debug the underlying service error using its own diagnostics. For No valid host was found, check scheduler capacity and flavor; for a volume error, check the Cinder backend; for a port error, check the network exists and binds. The Heat layer is now out of the picture.

4. Fix the root cause — free capacity or pick a fitting flavor, correct the volume size/type, create the missing network or image. The change usually lives in the template inputs or the environment, not the Heat engine.

5. Recover the stack. For a fresh failed stack, delete and recreate after the fix:

   openstack stack delete my-stack --yes
   openstack stack create -t app.yaml --parameter flavor=m1.small my-stack

   For an existing stack you want to retry in place, attempt a check/update:

   openstack stack update -t app.yaml my-stack

6. Verify the resource reaches CREATE_COMPLETE:

   openstack stack resource list my-stack -c resource_name -c resource_status

Prevention and Best Practices

• Validate templates with openstack stack create --dry-run (or stack-validate) before applying, to catch missing images, flavors, and bad references early.
• Pre-check that referenced flavors, images, networks, and volume types exist in the target project and region before launching a stack.
• Size stacks against current quota — sum the cores, RAM, ports, and volumes the template will create and confirm headroom first.
• Use --nested-depth on stack event list for nested stacks so the true failing leaf resource is visible, not just the top-level wrapper.
• Route stack-failure events into an automated triage flow such as /dashboard/incident-response/ so the responder immediately sees the quoted underlying reason.

Related Errors

• Resource CREATE failed: NotFound: resources.<name>: ... — a referenced image, flavor, or network does not exist (distinct from ResourceInError).
• Resource CREATE failed: Forbidden / OverQuota — a quota or policy rejection rather than a resource going to ERROR.
• No valid host was found — the most common underlying reason here; covered standalone in our /categories/openstack/ scheduler guides.
• Resource UPDATE failed: ResourceInError — the same wrapper during a stack update instead of create.

Frequently Asked Questions

Is ResourceInError a Heat bug? No. It is Heat faithfully reporting that a downstream resource (a Nova server, a Cinder volume, etc.) reached ERROR. The fix is always in the underlying service or the template, not in Heat.

Where do I find the real cause? In the quoted clause of stack_status_reason: Went to status ERROR due to "<reason>". That reason names the actual failure. Then inspect the failed resource with its service’s show command.

Can I retry just the failed resource? Heat does not retry individual resources in a failed create by default. Run stack update to converge in place, or delete and recreate the stack after fixing the root cause.

Why did only one nested resource fail? Heat builds resources per their dependency graph. One resource can fail (e.g., capacity ran out) while its peers succeed. Use stack event list --nested-depth to find the exact leaf.

Does this differ between Kolla-Ansible and package installs? The error and resolution are identical. Only log access differs: docker logs heat_engine versus journalctl -u openstack-heat-engine.