1

I have next list:

local {
...
  step_scaling_out_policy_configuration = {
    "adjustment_type"         = "ChangeInCapacity"
    "cooldown"                = 300
    "metric_aggregation_type" = "Maximum"
    "step_adjustment"         = {
      "metric_interval_lower_bound" = 0
      "scaling_adjustment"          = 1
    }
  }
...
}

And I could transform into block using next logic:

  step_scaling_policy_configuration {
    adjustment_type          = local.step_scaling_out_policy_configuration.adjustment_type
    cooldown                 = local.step_scaling_out_policy_configuration.cooldown
    metric_aggregation_type  = local.step_scaling_out_policy_configuration.metric_aggregation_type

    step_adjustment {
      metric_interval_lower_bound = local.step_scaling_out_policy_configuration.step_adjustment.metric_interval_lower_bound
      scaling_adjustment          = local.step_scaling_out_policy_configuration.step_adjustment.scaling_adjustment
    }
  }

It's quite easy with fixed number of keys in map. But is it possible to dynamically generate such block because I don't know exactly what could be in local.step_scaling_out_policy_configuration map. Now supposing I have

local {
...
  step_scaling_out_policy_configuration = {
    "adjustment_type"         = "ChangeInCapacity"
    "cooldown"                = 300
    "metric_aggregation_type" = "Maximum"
    #######
    "some_new_key"            = "value"
    #######
    "step_adjustment"         = {
      "metric_interval_lower_bound" = 0
      "scaling_adjustment"          = 1
    }
  }
...
}

Obviously with previous logic I won't have some_new_keyparameter in step_scaling_policy_configuration block. Is it possible to add key to step_scaling_policy_configuration block dynamically based on what's inside of local.step_scaling_out_policy_configuration map?

ipeacocks
  • 2,187
  • 3
  • 32
  • 47

1 Answers1

2

You can use try() or lookup() to check if the key is present and set it to null if it is missing. In most providers null is like not setting the key. Sometimes it might make sense to set it to an explicit default or en empty string "". null works fine in most cases and uses the providers default.

Example code using try() and lookup() solutions:

step_scaling_policy_configuration {
  ....

  some_new_key   = try(local.step_scaling_out_policy_configuration.some_new_key, null)
  some_other_key = lookup(local.step_scaling_out_policy_configuration, "some_other_key", null)

  step_adjustment {
    ....
  }
}

if you also want to make step_scaling_policy_configuration and/or step_adjustment depend on the existence of value in your local map, look into dynamic-blocks from the terraform documentation.

mariux
  • 2,807
  • 12
  • 21
  • Good point, thanks. I've thought about that. But in this case you need to describe all possible keys in tf resource. – ipeacocks Sep 08 '20 at 15:57
  • @ipeacocks yes, but you normally do this once when creating a module.. and can flexibly extend it later on when new features are implemented in the resource without breaking old code. – mariux Sep 08 '20 at 19:37