d/ssm_parameter: Return a default value if parameter cannot be found in AWS (optional)

[DanielRis]

I tried to make it comparable with the behavior of d/consul_keys (https://www.terraform.io/docs/providers/consul/d/keys.html) but with an option to enable/disable this behavior to avoid any compatibility issues

make testacc TEST=./aws TESTARGS='-run=TestAccAWSSsmParameterDataSource'
TF_ACC=1 go test ./aws -v -run=TestAccAWSSsmParameterDataSource -timeout 120m
=== RUN   TestAccAWSSsmParameterDataSource_basic
--- PASS: TestAccAWSSsmParameterDataSource_basic (85.00s)
=== RUN   TestAccAWSSsmParameterDataSource_defaultValue
--- PASS: TestAccAWSSsmParameterDataSource_defaultValue (37.30s)
=== RUN   TestAccAWSSsmParameterDataSource_fullPath
--- PASS: TestAccAWSSsmParameterDataSource_fullPath (53.61s)
PASS
ok      github.com/terraform-providers/terraform-provider-aws/aws       178.397s

Use case description

I only want to build a AWS resource if a parameter was configured by operations or terraform.

[AndHei]

@radeksimko this is super useful! please merge!

[StefanScherer]

@DanielRis Have you noticed the merge conflicts in several files?

[antonbabenko]

I think with_default is not needed. Don't provide default if you don't need to get a default value back.

[DanielRis]

Hi, I'm unsure how this can be implemented without breaking the actual behavior of failing if a SSM parameter cannot be found in SSM. Thats the reason why i created this "with_default" parameter.

If I skip "with_default" and set the Default value of "default" to be an empty string, I currently have no idea how to catch that in my code without returning a default value every time the parameter cannot be found. Any idea?

[DanielRis]

Never mind, I figured it out by my self.

[tbondarchuk]

@antonbabenko Hi, any news on getting this merged?

[jakowicz]

It would be super useful if this could get merged, please.

[ixalon]

Hi @DanielRis - great PR, we could really do with this! Any chance you could please fix the conflict?

[antonbabenko]

@bflad Could you tell what is missing here other than fixing conflicting file?

We can't wait for the next Terraform Gardering event to get this merged, can we? :)

[DanielRis]

I updated the PR to reflect that latest change that was implemented into this Data Resource. The lookup method was changed from GetParameters to GetParameter which caused the merge conflicts.

TF_ACC=1 go test ./aws -v -run=TestAccAWSSsmParameterDataSource -timeout 120m === RUN TestAccAWSSsmParameterDataSource_basic --- PASS: TestAccAWSSsmParameterDataSource_basic (20.08s) === RUN TestAccAWSSsmParameterDataSource_defaultValue --- PASS: TestAccAWSSsmParameterDataSource_defaultValue (10.68s) === RUN TestAccAWSSsmParameterDataSource_fullPath --- PASS: TestAccAWSSsmParameterDataSource_fullPath (12.14s) PASS ok github.com/DanielRis/terraform-provider-aws/aws 42.918s

[DanielRis]

I did some additional tests and I still have not found a good way to determine if a property has been set in a configuration.

data "aws_ssm_parameter" "foo" {
  name  = "foo"
  default = "bar"
}

works fine.

data "aws_ssm_parameter" "foo" {
  name  = "foo"
  default = ""
}

does not.

Is there any good way to check if a property is set in the configuration, independent of the value it has? I thought GetOkExist will do the job but this does not work for empty string values.

[bflad]

Hi Folks 👋 It would be helpful to understand some of the expected use cases for this functionality.

Outside of the consul_keys data source, the general Terraform design pattern for a data source requires that its referenced API resource (an SSM parameter in this case), actually exists or returns an error. Allowing this data source to be able to purposefully workaround that behavior (and also generate failing API calls) might not be the best way to handle this situation. It could also be confusing for operators that this data source works differently compared to others.

None of this is to say that we won't accept a change like this; its just a different class of problem and it would be nice to know some of the reasoning behind why the behavior change should be allowed. 😄

[gdlx]

Hi @bflad, here is my use case:

We're using blue/green deployment and the active environment name is currently stored in Consul.
As we're only using Consul for the key/value store, we'd like to migrate to SSM parameters.
Everything works fine on an existing (already initialized) platform, but the lack of SSM parameter default value prevent us from initializing a new one:

The resource aws_ssm_parameter can store a value but it depends on the value returned by the data aws_ssm_parameter...which falls into error when the param isn't set.

The consul_keys we're (still) using has a default option, which allows us to return a value when the key is not set yet. This way, a new (test/dev) platform can be initialized seamlessly. In the current state of aws_ssm_parameter we'd have to initialize it manually, which is not acceptable.

You'll find some other cases here: hashicorp/terraform#16380

@AndHei @aliusmiles @jakowicz @ixalon : Can you add your use cases to help merging this PR ?

Thanks !

[sharmaansh21]

@gdlx I am also facing the same issue :-(

[gdlx]

@sharmaanshul2102 Can you please explain your use case as requested by @bflad ? This will help merging or fixing the PR.

Thanks !

[sharmaansh21]

resource "aws_ssm_parameter" "test" {
  name        = "test"
  type        = "String"
  value       = "${var.test_version}"
  description = "Stores the latest version value of the test service."
  tags        = "${merge(local.common_tags, map("Name", "test"))}"
  overwrite   = true

  lifecycle {
    ignore_changes = ["value"]
  }
}

data "aws_ssm_parameter" "test" {
  name = "test"
}

It tries to read data and fails because aws_ssm_parameter doesn't exist in first run :-(

[tbondarchuk]

We are using SSM Parameters to store config variables in order to:

1. Allow external configuration: update SSM parameter in AWS console then run Jenkins job to deploy environment

2. Store environment specific variables: instance_type_ssm_path = "/${var.environment}/instance_type", with /dev/instance_type=t2.micro and /prod/instance_type=c5.large

Having default value for data "aws_ssm_parameter" allow us to set some common default values directly in terraform code without creating a lot of SSM parameters, and then create parameters only if needed.

[nywilken]

Hey folks thanks for shedding a little light on the need. Unfortunately, given that the provided usage cases are specific to solving a particular build/deploy process we are unable to accept this change, as it is not a use case that is valid to the provider.

Data sources are expected to require existing infrastructure. Changing the behaviour of this one data source would make it inconsistent with the other data sources in the provider, and in most other providers (minus the Consul provider). In general, Terraform prefers the use of explicit configuration that represents the true state of the reference infrastructure over conditionally defined defaults.

If you still feel like this is something worth discussing I recommend starting a discussion on our community forum https://discuss.hashicorp.com/c/terraform-providers as a next step.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!