Hey hoping for some guidance with a bit of a design issue and possibly a bug in atmos. We try to explicitly define egress from our EC2 services using references to other security groups in the egress rule. And we like to define our security group rules in the component that defines the service. So this leads to this situation: • a database component which defines a variable which is a map of all security groups IDs that should be added as ingress rules to the db. • a client service component which has a map var for configuring it's egress rules. My temptation is to use outputs for the sg ids in both these cases even though I realize it's a circular dependency. We'll never configure with a component

dependencies

link in a situation like this. When we tried this with

!terraform.state

used for both vars in both components we're finding that

atmos describe affected

eventually fails with a stack overflow. While I realize the cycle here I'm guessing it's still a bug that this ends up in a stack overflow? This is what I was hoping we could do:

components:
  terraform:
    services/test-client:
      vars:
        egress_security_groups:
          db_x:
            security_group_id: !terraform.state services/db_x security_group_id
            port: !terraform.state services/db_x db_x_sql_port

    services/db_x:
      vars:
        client_security_groups:
          test-client: !terraform.state services/test-client security_group_id

And since we would not use

dependencies

in this case our process would be the circuit breaker. • add a new client service which defines it's sg in output • next up you could add to the db client config • finally you can do a final PR to setup the egress back on the new client service Do you have any guidance on how to better handle this?

(security groups in general are "complicated" https://cloudposse.com/blog/devops/security-and-compliance/the-difficulty-of-managing-aws-security-groups-with-terraform)

Yeah when is firewalling every easy or straightforward.

OK will do. Yes I've used your sg module in the past ☝️ In my current org I'm trying to move us away from a lot of

data

source coupling which is still coupling (just more hidden) to being explicit with outputs and remote state.