Hey I just feel like I stumbled upon a very cool configuration that will help us migrate from static traditional terraform dirs in a progressive way. In our current static terraform we only use a default workspace and set specific backend keys for each dir. Eventually we'll migrate these static root modules into components but until they are all migrated in I was worried it would be difficult to leverage the

atmos

!terraform.state

YAML function to lookup outputs in the older terraform root modules. Then I had a crazy idea. If could create a

dummy

component that essentially only contains a

context.tf

could I then setup a stack that points to the older root modules where each component inherits from

dummy

but then specifies it's backend to make

!terrafofrm.state

work. To my surprise this actually works amazingly well! Here's what one of these

dummy

instances actually looks like (bogus account id swapped in):

components:
  terraform:
    vpc/us-east-1-development:
      metadata:
        enabled: false
        terraform_workspace: "default"
        component: dummy
        name: vpc/us-east-1-development
      backend:
        s3:
          key: infra/terraform/123456789012/vpc/us-east-1-development/terraform.tfstate

Then I can use this in another real component in the same stack:

vars:
        vpc_id: !terraform.state vpc/us-east-1-development vpc_id

Thought I would share in case this helps anyone else move into

atmos

The

metadata.enabled

is very cool cause that ensures my CI/CD does not try to plan/apply this

dummy

component as well!

Yes, this is great!

Yeah this is going to make the move into

atmos

really nice for us. When I used

atmos

before you didn't even have the YAML functions yet but then we also did 90% of things with your oss components.

Yea, there's a night and day difference in atmos over the past year

How is this different than an Abstract component? (

metadata.type: abstract

)

I don't think that an abstract component could have state associated with it. This was an adapter pattern so I could pull in remote state using the yaml template function when the state was not actually part of an atmos component (it's from a static terraform dir outside of atmos control still).

OIC. I think you're right.

Eventually I hope we'll move all our static terraform into atmos (using proper workspaces) but in the meantime this pattern allows lookups from atmos to our old terraform. So I was pretty happy about that.