Skip to main content

Inherited Components Now Use the Backend Key of Their Module

· 3 min read
Erik Osterman
Erik Osterman
Founder @ Cloud Posse

A component that inherits metadata.component from a base should behave like one that sets it directly. Until now, parts of Atmos still treated it as a component named after the instance, which caused failed lookups and missed affected components. Fixing that also changes the backend key Atmos generates for these components, so existing projects may need one step when they upgrade.

The Problem​

Take a concrete instance that gets its module from an abstract base:

components:
  terraform:
    k8s_nodes/lxd/defaults:
      metadata:
        type: abstract
        component: lxd/talos-nodes
    k8s_nodes:
      metadata:
        inherits:
          - k8s_nodes/lxd/defaults

Terraform ran in the lxd/talos-nodes directory, while atmos describe component reported k8s_nodes as the component and template lookups through atmos.Component failed. The instance was using one identity for execution and another for everything around it.

The Fix​

The inherited value is now resolved before anything else consumes it, so the directory, descriptions, lookups, and affected detection all agree. The generated backend key follows the same value, matching a component that sets metadata.component itself:

BackendBeforeNow
S3 workspace_key_prefixk8s_nodeslxd-talos-nodes
GCS prefixk8s_nodeslxd-talos-nodes
AzureRM keyk8s_nodes.terraform.tfstatelxd-talos-nodes.terraform.tfstate

Before You Upgrade​

This affects instances that inherit metadata.component, use a generated S3, GCS, or AzureRM backend, and don't set metadata.name or an explicit prefix or key. Their state remains at the old key, so Terraform starts from empty state at the new one:

Terminal
Plan: 1 to add, 0 to change, 0 to destroy.

Applying that plan creates duplicate resources, and a later destroy removes only the duplicates. Review plans for these components after upgrading, and pause any auto-approved applies until you have handled them. Edition pins have no effect on this change.

To see the key for a component, run atmos terraform generate backend on the old and new versions and compare the output.

How to Use It​

Pick one of these for each affected instance.

Keep the existing key. Give the instance a stable metadata.name, or set workspace_key_prefix (S3), prefix (GCS), or key (AzureRM) directly:

components:
  terraform:
    k8s_nodes:
      metadata:
        name: k8s_nodes
        inherits:
          - k8s_nodes/lxd/defaults

Adopt the new key. Before the next apply, copy the state of every workspace whose path changes, for example from k8s_nodes/test-k8s_nodes/terraform.tfstate to lxd-talos-nodes/test-k8s_nodes/terraform.tfstate. On S3 that means every named workspace, because the prefix doesn't apply to the default workspace. On GCS and AzureRM it includes default as well. The next plan in each workspace should report No changes.

Get Involved​

If this upgrade affects you in a way these steps don't cover, open an issue or ask in Slack.