v1.2.0

In order to cope with hashicorp/terraform#32023, this release disables automatic support of Terraform Cloud remote state backends for retrieving remote state in the modules/remote-state module. To access a Terraform Cloud remote state, you must set the backend_type input to "remote" in the module input as well as in the stack YAML configuration.

We hope and plan on removing this limitation in the next release with a revised solution, but are making this available while we are working on that.

Disable automatic support for Terraform Cloud remote state backend @Nuru (#56)

what

• Disable automatic support for Terraform Cloud remote state backend
• Require Terraform >= 1.1.0 for remote-state
• Drop support for Terraform 0.13.0

why

• Workaround for hashicorp/terraform#32023 which affects remote-state
• Version 1.1.0 is first version with fix for hashicorp/terraform#27849 which affects remote-state
• Cloud Posse is generally dropping support for Terraform < 1.0, but at a minimum requiring 0.14.0 because of changes to Terraform formatting introduced in that version

references

• hashicorp/terraform#32023

v1.1.1

🚀 Enhancements

Updating utils pin version to 1.5.0 in remote-state module @danjbh (#55)

what & why?

• Bumping utils version in remote-state module to take advantage of recent updates

v1.1.0

Add `atmos_cli_config_path` and `atmos_base_path` variables to `remote-state` module @aknysh (#53)

what

• Add atmos_cli_config_path and atmos_base_path variables to remote-state module
• Update utils provider versions

why

• atmos_cli_config_path and atmos_base_path variables will be used to override the atmos CLI config path and atmos base path in the remote-state module
• We already supported the ATMOS_CLI_CONFIG_PATH and ATMOS_BASE_PATH ENV vars to specify the CLI config file (atmos.yaml) path and atmos base path to be used to get a remote state of a component from a remote repo, e.g.

module "other_repo" {
  source = "git::ssh://[email protected]/xxxx/other-repo.git"
}

locals {
  other_repo_local_path = "${path.module}/.terraform/modules/other_repo"

  env = {
    ATMOS_BASE_PATH       = local.other_repo_local_path
    ATMOS_CLI_CONFIG_PATH = "${local.other_repo_local_path}/rootfs/usr/local/etc/atmos"
  }
}

module "account_map" {
  source  = "cloudposse/stack-config/yaml//modules/remote-state"
  version = "1.0.0"

  component   = "account-map"
  env         = local.env

  context = module.always.context
}

• The problems with using the ENV vars are as follows:

  • Terraform executes a provider code in a separate process and calls it using RPC
  • But this separate process is only one per provider, so if we call the code the get the remote state of two different components from two diff repos, the same process will be called
  • When we specify the ENV vars ATMOS_BASE_PATH and ATMOS_CLI_CONFIG_PATH, the provider process gets the ENV vars set in the process space
  • Then, if we call the provider a second time from the same terraform component (e.g. to get a remote state of another component from a different repo), the initially set ENV vars ATMOS_BASE_PATH and ATMOS_CLI_CONFIG_PATH are still set in the provider process space, which prevents the provider from finding the atmos.yaml CLI config related to the current repo (since the ENV vars still point to the other/remote repo config), which in turn causes an error when searching for the component in the stack
  • Even if we unset the ENV vars in the second call to the provider, it does not help since terraform executes data sources in parallel, so one of them will get the ENV vars set, and the other call will fail during the time window when the ENV vars are still set in the same process

• We need to be able to specify atmos base path and atmos CLI config path in the utils provider w/o using ENV vars - the component processor code now supports additional parameters to specify it (and they override all other paths set by the ENV vars)

references

• cloudposse/terraform-provider-utils#205

v1.0.0

Use `namespace` in `utils_component_config` data source @aknysh (#52)

what

• Use namespace in utils_component_config data source
• Pin to the latest utils provider version

why

• For stacks config using multiple Orgs, we use namespace in stack names, and need to be able to find the remote state of the components provisioned in these stack

references

• cloudposse/terraform-provider-utils#202
• Supersedes and closes #51

v0.22.4

🚀 Enhancements

Add ENV vars to `utils` provider. Update `utils` provider versions @aknysh (#50)

what

• Add ENV vars to utils provider
• Update utils provider versions

why

• Allow controlling the execution of atmos, utils provider and terraform modules using ENV vars

module "remote_state" {
  source = "../../modules/remote-state"

  component = "test/test-component-override"
  stack     = "tenant1-ue2-dev"

  env = {
    ATMOS_CLI_CONFIG_PATH = path.module
  }

  context = module.this.context
}

• In particular, the latest atmos and utils provider versions support ATMOS_CLI_CONFIG_PATH ENV var to set the path to atmos.yaml CLI config file. This ENV var will allow using the monorepo pattern by loading a remote repo and pointing to its atmos.yaml using ATMOS_CLI_CONFIG_PATH ENV var

module "monorepo" {
  source = "git::ssh://[email protected]/ACME/infrastructure.git?ref=v0.0.1"
}

locals {
  monorepo_local_path = "${path.module}/.terraform/modules/monorepo"
}

module "iam_roles" {
  source  = "git::ssh://[email protected]/ACME/infrastructure.git//components/terraform/account-map/modules/iam-roles?ref=v0.0.1"
  
  env = {
     ATMOS_CLI_CONFIG_PATH = "${path.module}/.terraform/modules/monorepo/rootfs/usr/local/etc/atmos"
  } 
  
  depends_on = [module.monorepo]
}

references

• cloudposse/terraform-provider-utils#174

v0.22.3

🐛 Bug Fixes

[remote-state] bugfix: Handle case where defaults is incompatible type @Nuru (#49)

what

• [remote-state] bugfix: Handle case where defaults is a Terraform type incompatible with the actual remote state outputs, leading Terraform to complain:

Error: Inconsistent conditional result types

The true and false result expressions must have consistent types. The given expressions are object and object, respectively.

why

• bug fix

v0.22.2

🐛 Bug Fixes

[remote-state] Fix remote-state default output when component missing @Nuru (#48)

what

• [remote-state] Return default results when component backend is missing
• Add separate example and test for the backend module

why

• Restore intended behavior
• The example for the backend module can use atmos.yaml CLI config, but the vars, settings and env modules can't (the utils provider needs to be updated to support that, and these modules are used just in examples/complete and not by any other repos/modules)

references

• Fixes #47
• Supersedes and closes #46

v0.22.1

Update `utils` provider. Add `ignore_errors` variable to `remote-state` @aknysh (#45)

what

• Update utils provider
• Add ignore_errors variable to remote-state
• Update GitHub workflows

why

• Use latest utils provider (which uses latest code from atmos with new features and bug fixes)
• utils provider is used to read remote state of components. Sometimes we want to ignore errors if a component does not exist in a stack. If ignore_errors = false, the utils provider could throw an error: Could not find config for the component 'xxxx' in the stack 'yyy'. Note that terraform try() does not catch errors from providers, so try(module.remote_state.outputs, {}) will not work and will still crash the process. Setting ignore_errors = true solves this.

references

• cloudposse/terraform-provider-utils#105
• cloudposse/atmos#120

Update auto-readme. Update examples and tests @Nuru (#43)

what

• Update auto-readme so that
  • If the only changes to the README are whitespace, the changes are ignored
  • Automatic changes to the README do not trigger a new release of the module
• Fix error in auto-release regular expression
• Update examples and tests

why

• Reduce spurious updates
• bugfix
• Update examples and tests to bring them up to date (sync with the latest from atmos)

notes

This is to some extent a trial run before pushing automatic README updates to all Cloud Posse modules.

v0.22.0

Update `spacelift` module and example @aknysh (#42)

what

• Update spacelift module and example

why

• Make the Spacelift processor use the logical stack names (derived from the context) to generate Spacelift stack names and Spacelift folders. Support stack and component folders, tenant (and all attributes from the context), and complex imports (Globs, folders in imports). Make the Spacelift processor use atmos.yaml CLI config to be able to find all top-level stacks automatically. Maintain backwards compatibility with the old Spacelift stack processor logic (where a list of stack config files was provided).

references

• cloudposse/atmos#73
• cloudposse/terraform-provider-utils#68

v0.21.1

🚀 Enhancements

Update `remote-state` module @aknysh (#41)

what

• Update remote-state module

why

• If remote_state_backend is not declared in YAML config, the default value will be an empty map {}, causing the condition to always be true and not defaulting to backend
• The ? operator in some instances (depending on the condition) changes the types of all items of the map to all strings