1.6.0

Atmos 1.15.0: Bump atmos to 1.15.0. Update `atmos.yaml`. Update example and tests @aknysh (#229)

what

• Bump atmos to 1.15.0
• Update atmos.yaml
• Update example and tests

why

• Update atmos "deps" calculation. In some cases, when more than one different YAML stack config files imported the same import (b/c some components in both derived from the same base component), then all of those stack config files were added to the component's "deps" list (resulting in Spacelift stacks having unrelated dependency labels which would cause unnecessary stack triggering)
• Keep up to date
• Keep the examples and tests the same as in atmos repo

references

• https://github.com/cloudposse/atmos/releases/tag/v1.15.0

1.5.0

ATMOS-1.10.0: Bump GitHub actions. Bump `atmos` version @aknysh (#207)

what

• Bump GitHub actions
• Bump atmos version

why

• Remove all global vars from Go code - this fixes remote state for Terraform utils provider

  • Terraform executes a provider data source 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, the same process will be called
  • In the previous implementation, we used the global Go variable Config which was used by all functions to get the CLI configuration to use it in calculations of component and stack paths
  • When we tried to get the remote state of two different components from two diff repos with two diff atmos.yaml CLI config files, Terraform executed the two calls concurrently. The first call processed atmos.yaml and updated the Config global var with the component and stack paths. Then the second call also processed a different atmos.yaml (from another repo) and overrode the global Config var with values related to the second repo
  • One of the calls randomly failed with the error "Searched all paths, but could not find the component xxx in the stack yyy"
  • Removing all globals from the Go code (including the Config var) allows executing any part of the code concurrently without storing any state in global vars. The CLI config is now processed on all calls to the atmos code and is used as parameter to all Go functions that require it

references

• cloudposse/atmos#210

🚀 Enhancements

ATMOS 1.10.1: Fix `atmos` CLI config processing. Improve `logs.verbose` @aknysh (#209)

what

• Fix atmos CLI config processing
• Improve logs.verbose

why

• Fix issues with CLI config processing introduced in cloudposse/atmos#210
• In Go, a struct is passed by value to a function (the whole struct is copied), so if the function modifies any struct fields, the changes are not visible from outside of the functions
• The function processEnvVars was accepting the CLI config struct by value, checking the ENV var ATMOS_BASE_PATH and modifying the BasePath field - this modification was lost when the function returned resulting in the error from the utils provider "failed to find a match for the import ..." because the atmos base path was not set correctly (note that ATMOS_BASE_PATH ENV var is critical for the utils provider to work, and it's set by geodesic or by Spacelift scripts)
• Changing the function to accept a pointer to the struct fixed the issue (the modified fields are visible to the calling code)

references

• cloudposse/atmos#211

1.4.0

ATMOS-1.10.0: Bump GitHub actions. Bump `atmos` version @aknysh (#207)

what

• Bump GitHub actions
• Bump atmos version

why

• Remove all global vars from Go code - this fixes remote state for Terraform utils provider

  • Terraform executes a provider data source 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, the same process will be called
  • In the previous implementation, we used the global Go variable Config which was used by all functions to get the CLI configuration to use it in calculations of component and stack paths
  • When we tried to get the remote state of two different components from two diff repos with two diff atmos.yaml CLI config files, Terraform executed the two calls concurrently. The first call processed atmos.yaml and updated the Config global var with the component and stack paths. Then the second call also processed a different atmos.yaml (from another repo) and overrode the global Config var with values related to the second repo
  • One of the calls randomly failed with the error "Searched all paths, but could not find the component xxx in the stack yyy"
  • Removing all globals from the Go code (including the Config var) allows executing any part of the code concurrently without storing any state in global vars. The CLI config is now processed on all calls to the atmos code and is used as parameter to all Go functions that require it

references

• cloudposse/atmos#210

1.4.1

what && why

• Re-releasing 1.3.0 as 1.4.1 while fixing some remote state issues in 1.4.0

1.3.0

Update `utils_component_config` data source. Bump `atmos` version @aknysh (#205)

what

• Update utils_component_config data source - add atmos_cli_config_path and atmos_base_path inputs
• Bump atmos version
• Update tests

why

• The atmos component processor's code is used by the provider to get the component's remote state
• 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://git@github.com/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/atmos#209

1.2.0

Bump `atmos` to the latest version. Update tests @aknysh (#202)

what

• Bump atmos to the latest version
• Update tests
• Use namespace context variable in the code that is used to return remote-state for a component in a stack

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/atmos#205

1.1.0

Bump `atmos` to the latest version @aknysh (#200)

what

• Bump atmos to the latest version

why

• Use many fixes and improvements in the atmos code

1.0.0

ATMOS-1.4.26: Update atmos and Go versions. Update tests @aknysh (#189)

what

• Update atmos to 1.4.26 and Go to 1.19
• Update tests

why

• Keep up to date
• When searching for the specified component in the specified stack (e.g. atmos describe component <component> -s <stack>), if any of the stack config files throws error (which also means that we can't find the component in that stack), print the error to the console and continue searching for the component in the other stack config files. This will allow having partial stack configs even if a partial stack config file does not provide all the required context variables (namespace, tenant, environment, stage) for all components in it (but specifies the context for some components, which we are interested in)
• Print the above misconfiguration errors to the console in logs verbose mode (export ATMOS_LOGS_VERBOSE=true)
• An example of partial stacks definition: examples/complete/stacks/orgs/cp/tenant1/dev/us-east-2-extras.yaml defines a new component new-vpc in the stack tenent1-ue2-dev; note that the same stack tenent1-ue2-dev is defined in examples/complete/stacks/orgs/cp/tenant1/dev/us-east-2.yaml but for different components

references

• https://github.com/cloudposse/atmos/releases/tag/v1.4.26

0.17.28

🚀 Enhancements

Bump `atmos` version. Update tests @aknysh (#184)

what

• Bump atmos version
• Update tests

why

• When a component defines inherited YAML base components in metadata.inherits and the stack imported the YAML file(s) where the inherited YAML components are defined, add the imported YAML files to the deps labels
• Before this fix, only the base terraform component was used in the deps calculation. All imported YAML files where the base YAML components were defined were not included in the deps labels (and the YAML files were missed from the Spacelift dependencies)

For example:

components:
  terraform:
    "test/test-component-override-3":
       metadata:
        component: "test/test-component"
        inherits:
          - "test/test-component-override"
          - "test/test-component-override-2"
          - "mixin/test-1"
          - "mixin/test-2"

In the above config, test/test-component-override-3" inherits test/test-component-override-2 YAML component.
Part of the config for test/test-component-override-2 YAML component is defined in service-1-override-2.yaml file:

components:
  terraform:
    "test/test-component-override-2":
      vars:
        service_1_name: "service-1-override-2"

the service-1-override-2.yaml file was not included in the deps labels because the code only checked for the base terraform component test/test-component in all imports.

After this fix, the code checks all imported files for the base terraform component and ALL base YAML components.

references

• cloudposse/atmos#177

v0

Bump `atmos` version. Update tests (#184)