Inconsistency in ways how the remote state is pulled

[iliazlobin]

Describe the Feature

Historically, in order to pull data from deployed components terraform_remote_state data source is taken for use. But it's been noticed that code has undergone significant changes in the way this is achieved. Now, the terraform module from the registry with the following source carries out this function:

module "vpc_flow_logs_bucket" {
  source  = "cloudposse/stack-config/yaml//modules/remote-state"
  version = "0.13.0"

  stack_config_local_path = "/home/user/ws/datameer/infrastructure-atmos-novel/stacks"
  component               = "vpc-flow-logs-bucket"
  environment             = var.vpc_flow_logs_bucket_environment_name
  stage                         = var.vpc_flow_logs_bucket_stage_name

  context = module.this.context
}

We would like to have consistency in this very important aspect given the fact that it's the most reusable feature and fundamental aspect of how the modules' coupling is organized.

The inconsistency also causes misunderstanding of what should be the right way of fixing things in times when errors happen.

Expected Behavior

The remote state is used consistently throughout all the upper-level and embedded modules.

[Nuru]

Yes, early versions of our code used tfstate-context.tf and tfstate.tf to pull remote state, but that was problematic because it required users to install a custom module that located the remote state storage and retrieved the data.

Going forward, we are using source = "cloudposse/stack-config/yaml//modules/remote-state" in remote-state.tf to find the remote state based on Atmos stack configuration. This allows you to configure where the remote state is stored via a YAML file rather than requiring you to write custom Terraform code.

[Nuru]

remote-state.tf is our consistent way to access remote state. Any code not using it should be updated to use it.