cloudposse/atmos v1.19.1 on GitHub

what

Add Sources of Component Variables to atmos describe component command
Update docs

why

The atmos describe component command outputs the final deep-merged component configuration in YAML format.

The output contains the following sections:

atmos_component - Atmos component name
atmos_stack - Atmos stack name
backend - Terraform backend configuration
backend_type - Terraform backend type
command - the binary to execute when provisioning the component (e.g. terraform, terraform-1, helmfile)
component - the Terraform component for which the Atmos component provides configuration
deps - a list of stack dependencies (stack config files where the component settings are defined, either inline or via imports)
env - a list of ENV variables defined for the Atmos component
inheritance - component's inheritance chain
metadata - component's metadata config
remote_state_backend - Terraform backend config for remote state
remote_state_backend_type - Terraform backend type for remote state
settings - component settings (free-form map)
sources - sources of the component's variables
vars - the final deep-merged component variables that are provided to Terraform and Helmfile when executing atmos terraform and atmos helmfile commands
workspace - Terraform workspace for the Atmos component

The sources.vars section of the output shows the final deep-merged component's variables and their inheritance chain.

Each variable descriptor has the following schema:

final_value - the final value of the variable after Atmos processes and deep-merges all values from all stack config files
name - the variable name
stack_dependencies - the variable's inheritance chain (stack config files where the values for the variable were provided). It has the following schema:
- stack_file - the stack config file where a value for the variable was provided
- stack_file_section - the section of the stack config file where the value for the variable was provided
- variable_value - the variable's value
- dependency_type - how the variable was defined (inline or import). inline means the variable was defined in one of the sections in the stack config file. import means the stack config file where the variable is defined was imported into the parent Atmos stack

For example:

atmos describe component test/test-component-override-3 -s tenant1-ue2-dev

sources:
  vars:
    enabled:
      final_value: true
      name: enabled
      stack_dependencies:
        - dependency_type: import
          stack_file: catalog/terraform/test-component
          stack_file_section: components.terraform.vars
          variable_value: true
        - dependency_type: inline
          stack_file: orgs/cp/tenant1/dev/us-east-2
          stack_file_section: terraform.vars
          variable_value: false
        - dependency_type: inline
          stack_file: orgs/cp/tenant1/dev/us-east-2
          stack_file_section: vars
          variable_value: true
    environment:
      final_value: ue2
      name: environment
      stack_dependencies:
        - dependency_type: import
          stack_file: mixins/region/us-east-2
          stack_file_section: vars
          variable_value: ue2
    namespace:
      final_value: cp
      name: namespace
      stack_dependencies:
        - dependency_type: import
          stack_file: orgs/cp/_defaults
          stack_file_section: vars
          variable_value: cp
    region:
      final_value: us-east-2
      name: region
      stack_dependencies:
        - dependency_type: import
          stack_file: mixins/region/us-east-2
          stack_file_section: vars
          variable_value: us-east-2
    service_1_map:
      final_value:
        a: 1
        b: 6
        c: 7
        d: 8
      name: service_1_map
      stack_dependencies:
        - dependency_type: import
          stack_file: catalog/terraform/services/service-1-override-2
          stack_file_section: components.terraform.vars
          variable_value:
            b: 6
            c: 7
            d: 8
        - dependency_type: import
          stack_file: catalog/terraform/services/service-1-override
          stack_file_section: components.terraform.vars
          variable_value:
            a: 1
            b: 2
            c: 3
    service_1_name:
      final_value: mixin-2
      name: service_1_name
      stack_dependencies:
        - dependency_type: import
          stack_file: catalog/terraform/mixins/test-2
          stack_file_section: components.terraform.vars
          variable_value: mixin-2
        - dependency_type: import
          stack_file: catalog/terraform/mixins/test-1
          stack_file_section: components.terraform.vars
          variable_value: mixin-1
        - dependency_type: import
          stack_file: catalog/terraform/services/service-1-override-2
          stack_file_section: components.terraform.vars
          variable_value: service-1-override-2
        - dependency_type: import
          stack_file: catalog/terraform/tenant1-ue2-dev
          stack_file_section: components.terraform.vars
          variable_value: service-1-override-2
        - dependency_type: import
          stack_file: catalog/terraform/services/service-1-override
          stack_file_section: components.terraform.vars
          variable_value: service-1-override
        - dependency_type: import
          stack_file: catalog/terraform/services/service-1
          stack_file_section: components.terraform.vars
          variable_value: service-1
    stage:
      final_value: dev
      name: stage
      stack_dependencies:
        - dependency_type: import
          stack_file: mixins/stage/dev
          stack_file_section: vars
          variable_value: dev

NOTE: The stack_dependencies inheritance chain shows the variable sources in the reverse order the sources were processed. The first item in the list was processed the last and its variable_value overrode all the previous values of the variable.

For example, the component's enabled variable has the following inheritance chain:

sources:
  vars:
    enabled:
      final_value: true
      name: enabled
      stack_dependencies:
        - dependency_type: import
          stack_file: catalog/terraform/test-component
          stack_file_section: components.terraform.vars
          variable_value: true
        - dependency_type: inline
          stack_file: orgs/cp/tenant1/dev/us-east-2
          stack_file_section: terraform.vars
          variable_value: false
        - dependency_type: inline
          stack_file: orgs/cp/tenant1/dev/us-east-2
          stack_file_section: vars
          variable_value: true

Which we can interpret as follows (reading from the last to the first item in the stack_dependencies list):

In the orgs/cp/tenant1/dev/us-east-2 stack config file (the last item in the list), the value for enabled was set to true in the global vars section (inline)
Then in the same orgs/cp/tenant1/dev/us-east-2 stack config file, the value for enabled was set to false in the terraform.vars section (inline). This value overrode the value set in the global vars section
Finally, in the catalog/terraform/test-component stack config file (which was imported into the parent Atmos stack
via import), the value for enabled was set to true in the components.terraform.vars section of
the test/test-component-override-3 Atmos component. This value overrode all the previous values arriving at the final_value: true for the variable. This final value is then set for the enabled variable of the Terraform component test/test-component when Atmos executes atmos terraform apply test/test-component-override-3 -s <stack> command